Automated releases

[functionzz]

As discussed in #2402, we want to be able to have an automated release structure so contributors and non-contributors can better keep track of our work. This is not to function as fully fledged release notes - rather it is a way of tracking work deployed onto the production Pontoon instance on a daily basis. See this comment for more information.

[functionzz]

@eemeli, for the SBOM step, since workflows cannot trigger workflows, I can't use release_actions.yml's auto created release to trigger sobm.yml. An option I can do is create a Github App to create the release event, but I believe that needs me to ask for secret creation from the org, if you could confirm this. Also, if there is another way that doesn't require extra perms, I'm open to ideas.

[flodolo]

since workflows cannot trigger workflows

That's not really true. You need to run the workflow with a PAT, and that's a secret in the repository, not the org.

[flodolo]

This is already behind the latest version

[flodolo]

Can we run this a bit earlier?

• All engineers are EU based, this is between dates.
• This changes with time zones (1 or 2 hours difference).

I think we could safely run this at 20 or 21 UTC.

[eemeli]

I actually recommended 23:00 UTC explicitly, as it's a time that'll most certainly associate the calver date with the day when the deployment actually happened.

The idea is that this'll be looking backwards to find and tag the last prod release made on that day, and that if necessary, we'll amend the release notes on the following day.

[flodolo]

Suggested change

	COMMIT_EXISTS=$(git tag --points-at "$SHA" | grep '^v202' || true)
	COMMIT_EXISTS=$(git tag --points-at "$SHA" | grep -E '^v[0-9]{4}\.[0-9]{2}\.[0-9]{2}$' || true)

Maybe avoid planned obsolesce?

[eemeli]

This too is doing a thing I asked for in #2402 (comment)

I'm fine either way; if we're still using this in three years, we can also update the condition then and keep it simple for now.

The variable name here is wrong though; it should be TAG_EXISTS.

[eemeli]

@eemeli, for the SBOM step, [...] if there is another way that doesn't require extra perms, I'm open to ideas.

The change you already have for the action ought to be sufficient. See for example the corresponding moz-l10n action, and the SBOM it added to the latest release.

[functionzz]

The change you already have for the action ought to be sufficient. See for example the corresponding moz-l10n action, and the SBOM it added to the latest release.

Rather, I am referring to a different issue regarding running the sbom workflow immediately conditioned on a release. We cannot use GITHUB_TOKENS, I was thinking using PAT tokens instead but the created release will be automatically authored by Matjaz for example.