ponylang / release-bot-action Goto Github PK

https://github.com/ponylang/release-notes-bot-action

• README should be updated to note optional release-notes-bot support.
• Update release notes creation to include release notes from .release-notes/next-release.md if it exists at the start of the release notes
• If release notes exist, after posting, as part of the post release cleanup, the next-release.md file should be renamed to VERSION.md. Where VERSION is something like 0.3.1
• A new, empty next-release.md should be created

Point of discussion, rather than being optional, should release-notes-bot support be a requirement.

Looking at our usage of ASSET_NAME with trigger-a-release announcement is pretty much fixed across all repos. We are currently announcing using the repo name. Like corral, crypto, release-bot-action etc.

Except that it is a value we have to change in the workflow.

Given this, we should switch to using GITHUB_REPOSITORY for the value and not taking an ASSET_NAME.

This means that we can copy the workflow defintion without having to change it.

Additionally when we make so others can use, Announcement will be something like

ponylang/corral

So there's no namespacing issue and its very clear what is what.

Using alpine as a base for python work that needs the python crypto package is a pain in the ass as we need to build it from source and that now requires rust. It's much easier to use a recent ubuntu and get the precompiled wheels installed.

When we make this change, we can unpin the PyGithub version from where it currently is.

At the moment, the trigger release announcement step gets the version from GITHUB_REF. For this to work, the step has to be triggered by a tag being pushed.

This is good for most use-cases, but not all. For example, ponyc build assets for release on cirrus-ci not github actions. This means that we want to trigger a release announcement once we've been notified assets have been uploaded to cloudsmith.

This will not work with trigger release announcement as it can't get the version from GITHUB_REF as it isn't available there.

To handle this, getting the version from GITHUB_REF should be the default, however if an optional environment variable "VERSION" is provided, it will be used as the version instead of parsing it out of GITHUB_REF.

The update for this should probably include some documentation on how and when it might be used related to triggering not based on a tag. However, it could be bypassed for now as it isn't the standard usage.

If corral.json exists for the released project and if it has the version field on the info object, it should be incremented as well.

This was missed as an issue up until now because we haven't as a community been using the info object in corral.json.

So we can more easily do our "retry on failure" logic.

It would suck to have a dep change underneath us without testing. That is unlikely but possible with right now.

The change is easy, the "no testing prior to release" is harder.

This requires #49 to be done first.

Things as part of 0.6.0 that I (still) need to do

• move git email etc info to required ENV for scripts that need
• switch all bash to python
• don't have .py or .bash on end of names so we can swap out implementation language later (hello pony)
• replace entrypoint.sh with python equiv
• make sure all scripts have GITHUB_REPOSITORY, GITHUB_REF, and GITHUB_WORKSPACE missing error messages
• update own release process to match new and put on main
• add document that has each command and requirements
• review README and cleanup
• update @main in README to @0.5.0 so it will get updated on release

And after release

• update self release process from main to 0.6.0
• deprecate readme-version-updater-action repo
• #49

We could use it, I'm sure.

This will probably involve some updates to the scripts as well.

We've had a couple occassions where committers have not read the release instructions and instead of pushing a tag like release-0.1.0 they push 0.1.0. This will result in the release process failing because not all steps were done (start-a-release) was skipped.

The release step should start by checking to make sure the CHANGELOG.md has the correct versions entries in it and if not, it should...

delete the pushed tag and exit with a big old error message.

The workflow release.yml is referencing action actions/checkout using references v1. However this reference is missing the commit a6747255bd19d7a757dbdda8c654a9f84db19839 which may contain fix to the some vulnerability.
The vulnerability fix that is missing by actions version could be related to:
(1) CVE fix
(2) upgrade of vulnerable dependency
(3) fix to secret leak and others.
Please consider to update the reference to the action.

At the moment, the release-bot can't be used for non ponylang projects.

The git information that is configured in entrypoint.sh is very pony project specific. We need to make that configurable via ENVIRONMENT variables.

The README has multiple examples that refer to the [email protected]

As part of release, they should be updated.

This would be in release.yml as a prerequistite for trigger-release-announcement step being run.

The workflow pr.yml is referencing action actions/checkout using references v1. However this reference is missing the commit a6747255bd19d7a757dbdda8c654a9f84db19839 which may contain fix to the some vulnerability.
The vulnerability fix that is missing by actions version could be related to:
(1) CVE fix
(2) upgrade of vulnerable dependency
(3) fix to secret leak and others.
Please consider to update the reference to the action.

Because we explictly try to checkout a branch, this will cause a default v2 setup to fail.

We should upgrade to only working with checkout@v2 and have everything work as needed.
That will apparently require some code changes.