mirror of
https://github.com/certbot/certbot.git
synced 2026-06-15 03:30:46 -04:00
cb02885928
Related to https://github.com/certbot/certbot/issues/10581 Following up on https://github.com/certbot/certbot/pull/10631, https://github.com/certbot/certbot/pull/10622, and https://github.com/certbot/certbot/pull/10634, this PR converts the release [pipeline](https://dev.azure.com/certbot/certbot/_build?definitionId=3) from Azure to Github Actions. While this is the last migration PR, I don't think we should close the issue, as we're still using launchpad for armhf builds. I plan to continue investigating that and at minimum write up my findings. To test [notifications](https://opensource.eff.org/eff-open-source/pl/nfgh6obi8tfqikn4ydp7dshakr) and creating a [github release](https://github.com/ohemorange/Things-that-are-gr9/releases/tag/v1.0.19), I ran workflows that no-oped most the other jobs [in a test repo](https://github.com/ohemorange/Things-that-are-gr9/actions/runs/25938082721) (I've made minor changes to names and comments since then, but no code changes). Everything else is basically the same as nightly, with different tags. For the docker deployment, `${{ github.ref_name }}` is the tag name, so `v1.2.3`. Why not parametrize the tests a bit more, by putting an `env` at the top with `dockerTag: ${{ github.ref_name }}` and `snapReleaseChannel: beta`? Because the `env` context is [not available](https://docs.github.com/en/actions/reference/workflows-and-actions/contexts#context-availability) to `with`; only `github, needs, strategy, matrix, inputs, vars`. We could use `vars`, by creating `docker_tag_release` or whatever in the [variable section](https://github.com/certbot/certbot/settings/variables/actions) of the repo settings by using the web interface, but that seems worse to me than having it in the file but twice. You will note that the contents of `release.yml` are very similar to `nightly.yml`. While it would be nice to factor that out and reuse the code, github actions would then flatten everything in the grouped code together, making the results much harder to check. You can see what that flattening would look like [here](https://github.com/ohemorange/Things-that-are-gr9/actions/runs/25941524972) (if we put them all in one workflow). Currently, it will look something like [this](https://github.com/certbot/certbot/actions/runs/25688414262), which is much more readable. We could split it into "stages" like we had in azure pipelines (probably 1. standard and extended tests (and changelog?), 2. snap package and deploy (depend on tests), 3. docker package and deploy (depend on tests), 4. github release (depend on snap package and deploy), 5-6. notify (depend on github release)), but in addition to a minor slowdown (currently github release only depends on snap and docker package, not deploy, just so we're trying to do all the deployments simultaneously and not partially in case of build failures), it would still be only like three fewer jobs, since we'd still want all the info passing and dependency relationships. While it would be nice from a UX perspective to group the two notification jobs together, you can't do that cleanly using the built-in `if` key, and I don't think it's worth switching to a messier github api-based version just to group them. For mattermost notifications, we currently get the person to tag by running `AUTHOR_NAME="$(git log -1 --pretty=format:'%an')"` and mapping that to mattermost username. We could instead use `github.actor` to get the github handle, and map that instead. I didn't bother since we already have working, tested code, but can if a reviewer thinks it's worth it. --------- Co-authored-by: Will Greenberg <willg@eff.org> Co-authored-by: Brad Warren <bmw@users.noreply.github.com>
66 lines
2 KiB
Python
Executable file
66 lines
2 KiB
Python
Executable file
#!/usr/bin/env python
|
|
"""
|
|
Script to generate a message notifying the person doing the release
|
|
of the result of the workflow run.
|
|
|
|
Run:
|
|
|
|
python tools/release_message.py GITHUB_AUTHOR_NAME SUCCESS
|
|
|
|
where SUCCESS is True or False
|
|
"""
|
|
import os
|
|
import random
|
|
import sys
|
|
|
|
server_url = os.environ['GITHUB_SERVER_URL']
|
|
repo_name = os.environ['GITHUB_REPOSITORY']
|
|
run_id = os.environ['GITHUB_RUN_ID']
|
|
|
|
def get_greeting():
|
|
fun_greetings = [
|
|
'Hey',
|
|
'Paging',
|
|
'Hi',
|
|
'Pinging',
|
|
]
|
|
return random.choice(fun_greetings)
|
|
|
|
def get_message(success: bool):
|
|
fun_success_messages = [
|
|
'the certbot release is ready to come out of the oven!',
|
|
"it's release-finishing go time!",
|
|
'all certbot release systems are set for launch!',
|
|
]
|
|
|
|
if success:
|
|
message = random.choice(fun_success_messages)
|
|
else:
|
|
message = "the release pipeline has failed."
|
|
return message
|
|
|
|
def get_content(requested_for: str, success: bool):
|
|
build_url = f'{server_url}/{repo_name}/actions/runs/{run_id}'
|
|
|
|
# We use github author here because it's what we have access to. If the name sometimes
|
|
# changes, add any name it might be. Check the git log.
|
|
# This is a map of team member github author names to opensource mattermost username
|
|
usernames_map = {
|
|
'Will Greenberg': 'willg',
|
|
'Erica Portnoy': 'erica',
|
|
'Brad Warren': 'brad',
|
|
'ohemorange': 'erica',
|
|
}
|
|
|
|
if requested_for in usernames_map:
|
|
text_body = f'{get_greeting()} @{usernames_map[requested_for]}, {get_message(success)}\n{build_url}'
|
|
else:
|
|
text_body = (f"{get_greeting()} {requested_for}, {get_message(success)}\nIf you'd like to get @ mentioned for "
|
|
"releases you do in the future, please modify tools/release_message.py with your "
|
|
f"git author name.\n{build_url}")
|
|
return text_body
|
|
|
|
random.seed()
|
|
requested_for: str = sys.argv[1].rstrip()
|
|
success: bool = (sys.argv[2].rstrip().lower() == 'true')
|
|
print(get_content(requested_for, success))
|