apyrgio
commented
3 weeks ago In order to solve this issue, we propose to add CI tests in the apt-tools-prod / yum-tools-prod repos, that do the exact same checks as our build-deb, install-deb, and build-install-rpm jobs in our ci.yml.
The important difference will be that they will operate on the Debian / Fedora packages that we are adding in the PRs. More specifically they will:
- Checkout the Dangerzone repo.
- Move the Dangerzone .deb/.rpm packages to the correct directories.
- Use
env.py buildto build an environment where we will install these packages and run Dangerzone.- Do not use the
--download-pyside6flag, use the local .rpm instead.
- Do not use the
- Test that a conversion runs with the Dangerzone CLI, and that the GUI imports work.
If we enforce passing these checks before merging the PRs, we will be much more confident in our subsequent releases.
almet
Dangerzone has two Git repos which act as mirrors for the Debian and Fedora repos:
Whenever we're doing a Dangerzone release, we add the final .deb and .rpm packages to these repos. Once the CI tests pass (currently a signature check), they become available for installation by our users.
The above procedure does not cover how the developers check that the packages are actually working. As part of our release procedure we have some safeguards:
build-deb,install-deb, andbuild-install-rpmjobs in ourci.ymlGitHub actions workflow.Also, while not strictly enforced, we tend to check the produced .rpm/.deb packages in some selected Fedora / Debian systems.
Even with those safeguards, things can go wrong. More specifically, in the previous release we managed to produce Fedora packages with incorrect permissions (see https://github.com/freedomofpress/dangerzone/issues/727). This faulty package was masked by the fact that PySide6 was segfaulting in Fedora, but still, in principle we can make the same mistake again.