mirror of
https://github.com/certbot/certbot.git
synced 2026-04-06 09:35:02 -04:00
0eb8af20a5
Fixes https://github.com/certbot/certbot/issues/10599 This approach creates a new azure stage Notify and posts to the mattermost webhook directly from within azure. The python script uses the azure rest api to get the status of the Deploy stage specifically. This will be failed if it failed, or skipped if a previous stage failed, or abandoned if it timed out. We may want to remove the existing azure build failure notification when this is merged. It can be deleted from [here](https://dev.azure.com/certbot/certbot/_settings/serviceHooks) (it's the one that says "Build release, status Failed"), although personally I think it's fine to keep it. History of alternate general approaches I investigated: 1. give azure a custom file to say a message that depends on the requestedBy field. impossible. no custom messages at all, much less dependant ones. 2. hook azure build completed webhook trigger directly to github respository_dispatch event. impossible. azure will send data in a [specific format](https://learn.microsoft.com/en-us/azure/devops/service-hooks/events?view=azure-devops#build.complete), which is not the format [github requires](https://docs.github.com/en/rest/repos/repos?apiVersion=2026-03-10#create-a-repository-dispatch-event). 3. option 2, but put a custom server somewhere to translate them. or to grab azure and send directly to mattermost. this is a horrible idea; no one wants to be managing a production server with secrets on it. 4. a mattermost bot is just a special user account. the sender still has to format the data so mm can read it. 5. block on migrating from azure to github actions. drawback: this will likely take a while, and also we're not definitely doing it. see https://github.com/certbot/certbot/issues/10581 6. smaller than 5; wrap release in a github action that calls azure inside of it. and then if we end up migrating more, it should be pretty smooth to move things inside of actions. drawback: this will probably not integrate as smoothly, given we use the azure integration. I did not investigate further. 7. there doesn't seem to be any sort of github actions event about builds passing on a certain branch that we can check 8. just message mattermost directly from within the pipeline as a final stage --> where I landed. There's further discussion in the comments about others ways we tried to structure the pipeline and get information from azure that's not super necessary to read to review this PR. Relevant links: https://learn.microsoft.com/en-us/azure/devops/service-hooks/events?view=azure-devops#build.complete https://learn.microsoft.com/en-us/azure/devops/service-hooks/services/webhooks?view=azure-devops#resource-details-to-send https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=yaml#agent-variables https://learn.microsoft.com/en-us/azure/devops/pipelines/process/conditions?view=azure-devops&tabs=yaml#job-status-functions https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows https://docs.github.com/en/rest/repos/repos?apiVersion=2026-03-10#create-a-repository-dispatch-event https://docs.github.com/en/webhooks/webhook-events-and-payloads#repository_dispatch Results of tests with the latest code are here: https://dev.azure.com/certbot/certbot/_build/results?buildId=10309&view=results https://dev.azure.com/certbot/certbot/_build/results?buildId=10310&view=results https://dev.azure.com/certbot/certbot/_build/results?buildId=10311&view=results Plus the mattermost messages did get sent. --------- Co-authored-by: Brad Warren <bmw@users.noreply.github.com> |
||
|---|---|---|
| .. | ||
| docker | ||
| pinning | ||
| snap | ||
| _release.sh | ||
| extract_changelog.py | ||
| finish_release.py | ||
| notify_mattermost.py | ||
| oldest_constraints.txt | ||
| pip_install.py | ||
| pipstrap.py | ||
| release.sh | ||
| requirements.txt | ||
| retry.sh | ||
| sphinx-quickstart.sh | ||
| venv.py | ||