Add support for third-party PPA repositories via add-repository parameter

[Copilot]

This PR implements support for adding third-party PPA repositories before package installation, addressing issue #95. Users can now specify custom repositories using the new add-repository parameter.

Problem

Previously, the action only supported packages from the default Ubuntu repositories. Users who needed packages from third-party PPAs (like the Chromium browser example in the issue) had to manually add repositories in separate steps, losing the benefits of the action's caching mechanism.

Solution

Added a new add-repository input parameter that accepts a space-delimited list of repositories to add via apt-add-repository before installing packages. The implementation:

1. Adds repositories before package installation: Executes apt-add-repository -y for each specified repository
2. Maintains cache isolation: Repository parameter is included in cache key generation so different repository combinations get separate caches
3. Includes input validation: Basic validation prevents potentially harmful repository strings
4. Preserves backward compatibility: Existing workflows continue to work unchanged

Usage Examples

Install Chromium browser from PPA (the original motivating use case):

- uses: awalsh128/cache-apt-pkgs-action@latest
  with:
    packages: chromium-browser
    add-repository: ppa:canonical-chromium-builds/stage
    version: 1.0

Add multiple repositories:

- uses: awalsh128/cache-apt-pkgs-action@latest
  with:
    packages: package1 package2
    add-repository: ppa:user/repo1 ppa:user/repo2
    version: 1.0

Implementation Details

• Parameter flow: action.yml → pre_cache_action.sh → post_cache_action.sh → install_and_cache_pkgs.sh
• Cache key integration: Repository parameter is hashed into cache keys to ensure different repos get different caches
• Repository formats supported: PPA format (ppa:user/repo), HTTP/HTTPS URLs, standard repository names like multiverse
• Validation: Character validation prevents injection attacks while allowing legitimate repository formats

Testing

• All existing Go tests continue to pass
• Added validation tests for invalid repository formats
• Integration tests verify complete workflow with PPA parameter
• Backward compatibility tests confirm no breaking changes
• Multiple repository format tests ensure broad compatibility

The implementation is minimal and surgical, adding exactly the requested functionality without modifying existing behavior.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Suggestion: Add support for third-party PPA</issue_title>
<issue_description>It would be cool to be able to specify third-party PPAs as package sources in addition to the default sources.

Use case: installing (and caching) the chromium package (not the official snap one, some plain .deb)

This use-case requires:

• sudo add-apt-repository ppa:<some ramdom ppa repo>
• sudo apt update
• sudo apt install chromium-browser

I guess that simply providing an additional "with" parameter add-repository: <repository> would be enough
and the action would then issue the relevant pre-flight commands cf above prior to the apt install</issue_description>

Comments on the Issue (you are @copilot in this section)

@awalsh128 This is an interesting case. It would be relatively simple to add and may be more intuitive. WDYT? @awalsh128 @fambon I started work on this and was curious what you thought about this. I could support just PPA or other repos in general; it is just more verbose.

For example:

    apt-add-repository 'deb http://myserver/path/to/repo stable myrepo'
    apt-add-repository 'http://myserver/path/to/repo myrepo'
    apt-add-repository 'https://packages.medibuntu.org free non-free'
    apt-add-repository http://extras.ubuntu.com/ubuntu
    apt-add-repository ppa:user/repository
    apt-add-repository ppa:user/distro/repository
    apt-add-repository multiverse

Would it make sense to support more than just PPA?</comment_new>
<comment_new>@awalsh128
Support is always welcome. 💯

Happy to look at any PRs. Make sure to PR from dev branch and add a corresponding test in https://github.com/awalsh128/cache-apt-pkgs-action-ci. We can then add the staging and prod tests as we graduate through those branches.

Master is broken right now too, so that will need to get fixed before we pull from staging.</comment_new>
<comment_new>@awalsh128
Hi all. here's a plan. Let's add the test to awalsh128/cache-apt-pkgs-action-ci and then pull in the change against the dev branch here. Once it passes we can then pull it in.</comment_new>

Fixes #74

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.