2 Commits

Include renames

Author	SHA1	Message	Date
3 people	9339d23aa1	Migrate extended/full/test-* tests from azure pipelines to github actions (#10631) ... Related to https://github.com/certbot/certbot/issues/10581 Following up on #10622, this PR converts the `full-test-suite` [pipeline](https://dev.azure.com/certbot/certbot/_build?definitionId=4) from Azure to Github Actions. Nightly test changes for context not included in this PR are available [here](https://github.com/certbot/certbot/compare/test-convert-full-pipeline...convert-all-pipelines). Since this branch is named `test-convert-full-pipeline`, these tests will show up in the checks section of this PR. The major changes I made here are splitting the docker and snaps tests for a better github actions UX, and removing the intermediate "stage" file, since stages are not a concept in GHA. This means that we get the nice dropdowns for the different categories on the left bar of the [test run page](https://github.com/certbot/certbot/actions/runs/25139155528/job/73684692548) so it's easier to see each type of test. The very slight drawback is that the four jobs listed in `.github/workflows/full_test_suite.yml` do need to be duplicated in `nightly.yml`, but that's a reasonable tradeoff to me. Also, we now test our certbot and dns plugin snaps on all architectures for the first time (using `dpkg --add-architecture` to run armhf tests on an arm64 machine), which is very nice and in my opinion worth the very slightly extra time and code. In this PR, we build arm64 and amd64 snaps directly on github's runners. armhf snaps are built using launchpad as before. This makes the workflow file a little long. There are perhaps some micro-optimizations for code deduplication I could make, like creating an action to install dependencies based on the architecture, but I don't think it's super worth it, especially since the dependencies vary enough that we'd still need some code (for example, even between installing deps for certbot and dns runs, we'd still need to additionally install `nginx-light`). A very slight potential time improvement we could make here would be to optionally depend on the different architectures before running their respective tests. I'm not sure if this can be done without writing different jobs, and since once those jobs start they run in parallel, it didn't really seem worth looking into for me. I am of course open to alternate points of view here and in general. Another potential change to bring the two build strategies more in line would be to stop using the python script to send off all the launchpad builds, and instead put each in a separate, matrixed job like the github jobs. We could even continue retrying the builds within each job. This would mean that if one dns plugin build happens to fail three times, all the builds wouldn't have to be retried. While I think that's not the worst idea, I personally think that belongs in a separate PR, as this PR is already quite long. Speaking of the PR length, I can undo the changes made here to build arm64 and amd64 snaps on github actions, to have a simpler conversion-only PR to review. Some of the choices I made here, particularly around UX, were based on the fact that the jobs would look like this, so it might not be as clear why I made those choices, but if it's easier to review it's no problem to put it back. I could also remove the code that tests the other snaps since it's new, but I figured it'd be nice to show that they are in fact being built correctly, since otherwise the built snaps wouldn't be consumed anywhere. --------- Co-authored-by: Brad Warren <bmw@users.noreply.github.com>	2026-05-08 18:03:26 -07:00
4 people	9ec4105ff3	Migrate PR tests from azure pipelines to github actions (#10622) ... Related to https://github.com/certbot/certbot/issues/10581 This is the first step of migrating to github actions. Nightly and full tests have been converted on branch `convert-all-pipelines`; you can see additional changes to do those for context [here](https://github.com/certbot/certbot/compare/convert-pr-tests...convert-all-pipelines). Some notes: - All github workflows must be flat in the `.github/workflows/` directory. - Github actions doesn't have a concept of "stages." Instead, it generates a dependency graph, which is kind of nice. You can see an example of a more complicated one [here](https://github.com/certbot/certbot/actions/runs/24580625688). - I don't know why the actions in the left bar (under Actions tab --> All workflows) are using the path instead of the listed name. I suspect it has something to do with not being run on main. Once it's merged, if the name doesn't change, we can delete previous runs and that will clear the entry on the left. - "permissions" is for the fine-grained github PAT. contents: read is needed for the "checkout" action, which basically everything uses. it's still best practice to define per-workflow. it can also be defined per-job, but per-workflow seemed nicer to me. [This](https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#permissions) is the best permissions explanation I've found; [some actions](https://github.com/actions/checkout) mention what permissions they need. - For definitions of the keywords to `on`, see [here](https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows). - Some of the potential inputs in tox steps are not used in this PR because we're not running the AWS tests. It seemed messier to take them out here and put them back later when the extended tests need them, but I can do that on request. We currently have a `main` [protection rule](https://github.com/certbot/certbot/settings/branch_protection_rules/5466) set that Azure pipelines PR test suite must pass before merging. Obviously I don't want to turn that off before this PR is reviewed. In github actions, it can only require a specific job to pass, though you can have multiple. To address this, I've created a job that requires all other jobs to pass, and that can be set at the required job. We probably do not want to list every individual job, as that includes every job generated by a matrix strategy. To find it in the protection rules page, start typing "PR test suite success" and it will show up. --------- Co-authored-by: Brad Warren <bmw@users.noreply.github.com> Co-authored-by: Will Greenberg <willg@eff.org>	2026-04-28 12:34:42 -07:00