Feat 532: APT installation support with validation and documentation

[Leay15]

This pull request closes #532
It introduces comprehensive support for APT (Debian/Ubuntu) packaging and repository management for the project, including CI/CD workflow changes, documentation updates, and improvements to the CLI's self-management commands. The changes automate building, validating, and publishing Debian packages and repositories, and ensure that users installing via APT receive appropriate update and uninstall guidance.

APT packaging and repository automation:

• Added new jobs to .github/workflows/check.yml to build, validate, and test Debian packages and signed APT repositories for both x86_64 and aarch64 architectures, including smoke tests in KVM environments.

• Extended .github/workflows/release.yml to package, sign, and publish APT repositories to GitHub Pages as part of the release process, with a preparatory job to coordinate release context and ensure correct source SHA and tag usage.

Documentation improvements:

• Updated README.md to provide clear instructions for installing the CLI via the new APT repository, including keyring setup and repository configuration for Debian/Ubuntu users.

CLI enhancements for APT awareness:

• Modified crates/cli/lib/commands/self_cmd.rs so that if the CLI is installed via APT, microsandbox self update and microsandbox self uninstall will print appropriate notices instead of performing direct actions, to prevent conflicts with package-managed installations.

These changes ensure robust, automated packaging and updates for Debian-based systems. Also let open the possibility for support another Linux Arch.

Tested on:
Pop!_OS 24.04 LTS
Podman instead Docker

[toksdotdev]

hey @Leay15. happy to see you contributing :) ok, gonna take a look at this over the weekend.

[Leay15]

Thank you @toksdotdev!

I put this points here for discussing it:

• The 'REVISION' value is not defined yet, I put some hardcoded value for being able to test it (I'm thinking about taking commit sha but I prefer to discuss it with you :) )
• The gpg signs is not closed yet, I'm not quite sure if will be given by CI vars or by Env file

Happy to hear all the comments about 😄

[toksdotdev]

@Leay15 so sorry for not reviewing earlier. your PR is still very useful. ok if i re-opened?

i just haven't gotten back yet to adding support for more modes of distribution due to other incoming requests. the homebrew PR which i created (#536) also was delayed.

[Leay15]

@toksdotdev Sure, no problem.

I was planning to rework it to better reflect how things are now. If you prefer, I can do it on this same branch and rebase the changes with force push. :)

[toksdotdev]

cool cool. yeah, that'd be great. force pushing to this same branch works 💯

[Leay15]

@toksdotdev there’s a topic we need to discuss.

We should define how the APT keyring is handled going forward, since there are two valid approaches with different trade-offs:

Option 1: Script/manual-managed keyring in /etc/apt/keyrings
This treats the keyring as part of the system’s local configuration (admin-managed). It fits well with the current flow where users add the repo via instructions or helper scripts, does not interfere with apt install microsandbox, and keeps a clear separation between admin-managed and package-managed files.

The downside is that if we later introduce a dedicated keyring package, we’ll need to define how to migrate or reconcile this setup.

Option 2: Package-managed keyring in /usr/share/keyrings
This treats the keyring as part of the distributed Debian content (package-managed), ideally via a package like microsandbox-archive-keyring. It makes ownership by dpkg explicit and simplifies future key rotation and versioning through packages.

The downside is that, until such a package exists, installing it via manual scripts in /usr/share/keyrings is conceptually less clean and slightly blurs the line between bootstrap configuration and package-managed files.

Question:
Which approach should we standardize on moving forward?