Manual Release Process
Updates and releases to this actions monorepo¶
In order to push changes to the actions, so that any downstream workflows can use the changes or when any of the actions or workflows need to be updated. The current process for this actions
repo is:
- Set up your workstation with this repo and to sign commits and tags
- Ensure you have a local copy of this
actions
repo cloned to your workstation - Follow GitHub's signing tags docs to ensure you can sign tags from your workstation
- Create a development branch and make the proper code changes
- You should use the
dev-*
naming convention (example:dev-unique_branch_name_here
) - Update the specific action or workflow, as needed
- You should use the
- Determine the next version for this
actions
repo- Check with
@rwaight
to determine the version level change - The changes should be either
patch
,minor
, ormajor
- Make note of the next version, as it will be used later in the release process
- Check with
- Open a pull request from your development branch into
base: main
- Be sure to include the proper
version:
label
- Be sure to include the proper
- Have your pull request reviewed, then merge the changes into
main
- Make a note of the commit that was merged into main (example: "merged commit
8675309
intomain
") - The value listed for commit is the first seven (7) characters of the commit hash
- Update your local clone of this
actions
repo with the changes frommain
- If you have your development branch open, issue
git stash
to save the local changes - Fetch the remote branches with
git fetch --all
- Switch to the
main
branch withgit checkout main
- Use
git pull origin main
to ensure your local clone is updated from origin - Verify your local clone has the latest commit to
main
- Use one of the following commands to get the list of recent commits:
git log --pretty=format:"%h - %an, %ar : %s" --since=3.days
git log --pretty=oneline
git log --pretty=format:"%h - %an, %ar : %s" --since=2.weeks
git log --pretty=format:"%h - %an, %ar : %s" --since=1.week
- Look for the commit that was merged into main
- Alternatively, pipe the output from the
git log
command intogrep
and add the commit- Example:
git log --pretty=oneline | grep 8675309
- Example:
- Use
echo
to remind yourself of the commit that will be used for the newgit tag
, example:echo "the commit linked to v1.1.1 is 8675309"
- Create a signed
git tag
and verify the signed tag - Follow GitHub's signing tags docs to ensure you can sign tags from your workstation
- You will use the
-a
,-m
, and-s
options when creating and signing the tag - Use
git tag
and the-s
option to create the tag for the next version, example:git tag -a v1.1.1 -m "Code updated to v1.1.1" -s 8675309
- You will use the
-v
option to verify the signed tag - Sign the tag with
git tag -v v1.1.1
- Confirm you see a
gpg: Good signature
response from issuing thegit tag -v
command - Push the signed and verified tag to this repo (origin)
- Be cerain that you have signed and verified the tag before proceeding
- Push the signed and verified tag with
git push -f origin v1.1.1
- Ask
@rwaight
why this is not part of a GitHub workflow (or a composite action) in this repo... because it should be
Notes about reducing time spent on the release process¶
There are a few things to consider when attempting to reduce the time spent on the release process.
- Keeping a changelog or other documentation for the changes made, without having to look through PRs
- Keeping the major and minor tags updated when a new version is released
- Using automation but now allowing automation to push to protected branches