mirror of
https://github.com/certbot/certbot.git
synced 2026-07-28 00:35:28 +02:00
9339d23aa1
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>
.. This file contains a series of comments that are used to include sections of this README in other files. Do not modify these comments unless you know what you are doing. tag:intro-begin |build-status| .. |build-status| image:: https://img.shields.io/azure-devops/build/certbot/ba534f81-a483-4b9b-9b4e-a60bec8fee72/5/main :target: https://dev.azure.com/certbot/certbot/_build?definitionId=5 :alt: Azure Pipelines CI status .. image:: https://raw.githubusercontent.com/EFForg/design/master/logos/certbot/eff-certbot-lockup.png :width: 200 :alt: EFF Certbot Logo Certbot is part of EFF’s effort to encrypt the entire Internet. Secure communication over the Web relies on HTTPS, which requires the use of a digital certificate that lets browsers verify the identity of web servers (e.g., is that really google.com?). Web servers obtain their certificates from trusted third parties called certificate authorities (CAs). Certbot is an easy-to-use client that fetches a certificate from Let’s Encrypt—an open certificate authority launched by the EFF, Mozilla, and others—and deploys it to a web server. Anyone who has gone through the trouble of setting up a secure website knows what a hassle getting and maintaining a certificate is. Certbot and Let’s Encrypt can automate away the pain and let you turn on and manage HTTPS with simple commands. Using Certbot and Let's Encrypt is free. .. _installation: Getting Started --------------- The best way to get started is to use our `interactive guide <https://certbot.eff.org>`_. It generates instructions based on your configuration settings. In most cases, you’ll need `root or administrator access <https://certbot.eff.org/faq/#does-certbot-require-root-administrator-privileges>`_ to your web server to run Certbot. Certbot is meant to be run directly on your web server on the command line, not on your personal computer. If you’re using a hosted service and don’t have direct access to your web server, you might not be able to use Certbot. Check with your hosting provider for documentation about uploading certificates or using certificates issued by Let’s Encrypt. Contributing ------------ If you'd like to contribute to this project please read `Developer Guide <https://certbot.eff.org/docs/contributing.html>`_. This project is governed by `EFF's Public Projects Code of Conduct <https://www.eff.org/pages/eppcode>`_. Links ===== .. Do not modify this comment unless you know what you're doing. tag:links-begin Documentation: https://certbot.eff.org/docs Software project: https://github.com/certbot/certbot Changelog: https://github.com/certbot/certbot/blob/main/certbot/CHANGELOG.md For Contributors: https://certbot.eff.org/docs/contributing.html For Users: https://certbot.eff.org/docs/using.html Main Website: https://certbot.eff.org Let's Encrypt Website: https://letsencrypt.org Community: https://community.letsencrypt.org ACME spec: `RFC 8555 <https://tools.ietf.org/html/rfc8555>`_ ACME working area in github (archived): https://github.com/ietf-wg-acme/acme .. Do not modify this comment unless you know what you're doing. tag:links-end .. Do not modify this comment unless you know what you're doing. tag:intro-end .. Do not modify this comment unless you know what you're doing. tag:features-begin Current Features ===================== * Supports multiple web servers: - Apache 2.4+ - nginx/0.8.48+ - webroot (adds files to webroot directories in order to prove control of domains and obtain certificates) - standalone (runs its own simple webserver to prove you control a domain) - other server software via `third party plugins <https://certbot.eff.org/docs/using.html#third-party-plugins>`_ * The private key is generated locally on your system. * Can talk to the Let's Encrypt CA or optionally to other ACME compliant services. * Can get domain-validated (DV) certificates. * Can revoke certificates. * Supports ECDSA (default) and RSA certificate private keys. * Can optionally install a http -> https redirect, so your site effectively runs https only. * Fully automated. * Configuration changes are logged and can be reverted. .. Do not modify this comment unless you know what you're doing. tag:features-end Thanks ------ We appreciate the donation of credits to help us test and develop Certbot from: .. image:: https://opensource.nyc3.cdn.digitaloceanspaces.com/attribution/assets/SVG/DO_Logo_horizontal_blue.svg :width: 201 :alt: DigitalOcean Logo :target: https://www.digitalocean.com/