0.6.3

Fixed syntax error in update-action-to-use-docker-image-to-run-action

It turns out our CI linting would show green for code that had failed linting. That is a bad setup. In the process, the last release had a syntax error in it.

We've fixed that.

[0.6.3] - 2023-08-29

Fixed

• Fixed syntax error in update-action-to-use-docker-image-to-run-action (PR #64)

0.6.2

Update to work with newer versions of git

Newer versions of git have added a check to see if the user running a command is the same as the user who owns the repository. If they don't match, the command fails. Adding the repository directory to a "safe list" addresses the issue.

We've updated accordingly.

Add support for GHCR.io

We've added support for an additional registry to our two commands that were registry specific.

update-action-to-use-docker-image-to-run-action now takes an environment variable REGISTRY to indicate which registry to use.

update-version-in-README now support changing docker urls for both the default (none) and for urls targeting ghcr.io.

See the README for updated usage instructions for update-action-to-use-docker-image-to-run-action. You don't need to make any changes for related to the update-version-in-README change.

[0.6.2] - 2023-08-29

Fixed

• Update to work with newer versions of git (PR #57)

Added

• Add support for GHCR.io (PR #61)

0.6.1

Add support for ponyc's specialized build requirements

We build ponyc in CirrusCI, not GitHub actions. We do this because we often need to build LLVM from source and GitHub doesn't provide execution environments that are powerful enough. This results in a change where we can't use a stock release-bot trigger-release-announcement command.

When the ponyc workflow goes to trigger release announcements, the tag used to build isn't available so the version needs to be provided via the CUSTOM_VERSION environment variable that is added in this change.

This functionality should have been included in 0.6.0 but was missed.

[0.6.1] - 2021-07-14

Added

• Add support for ponyc's specialized build requirements (PR #51)

0.6.0

Create images on release

Permanant, unchanging images for this action are now available in DockerHub and will be updated on each release. See our examples for more details on how to use.

Replace "step" input parameter with overriding of entrypoint

Previously, when configuring the release-bot, you would indicate which step should be run like:

        with:
          step: start-a-release
          git_user_name: "Ponylang Main Bot"
          git_user_email: "[email protected]"

step as an input option has been removed and replaced by entrypoint. entrypoint is an existing option that GitHub actions supports for changing the script to run from within an action.

Previously, the steps where:

• start-a-release
• trigger-release-announcement
• announce-a-release

Those steps have been replaced with the following corresponding entrypoints:

• start-a-release.bash
• trigger-release-announcement.bash
• announce-a-release.bash

The aforementioned configuration from above would now be:

        with:
          entrypoint: start-a-release.bash
          git_user_name: "Ponylang Main Bot"
          git_user_email: "[email protected]"

Switch supported actions/checkout from v1 to v2

We've switched from supporting actions/checkout@v1 to actions/checkout@v2.

The are a few changes to configuration of release-bot that come along with this change. You should check out the examples in the README.md to see the latest on how to configure.

Highlights of changes:

• Use actions/checkout@v2
• action/checkout requires the setting token and ref values.
• Most workflows no longer require a release token being passed to the action, only to actions/checkout.
• Workflows no longer take a default branch. The default branch is now handled by actions/checkout@v2.

Split "start-a-release" into multiple different commands

Previously, release-bot-action had a command start-a-release that did multiple things. It:

• Updated the version in VERSION
• It ran the changelog-tool release command to version CHANGELOG.md
• It updated the version in corral.json if corral.json existed

AND...

It kicked off the next stage of the release process by pushing back a new tag for the actual release itself like 1.0.0.

This was all well and good but as part of the release process, not all projects needs corral.json updated. Many projects don't have a corral.json to update. Others have other files they need updated as part of pre-release process. Our emacs mode for example have version information that needs to be updated in .el files in order to get MELPA to pick up a new version.

Rather than shove more and more functionality into a single script, start-a-release has been broken apart into multiple commands that can be called from steps in a GitHub actions workflow to compose functionality together on a per-project basis.

Those new commands covered in detail in our updated prepare-for-a-release example in README.md. The new step commands are:

• add-unreleased-section-to-changelog.bash
• trigger-artefact-creation.bash
• update-changelog-for-release.bash
• update-version-corral-json.bash
• update-version-in-VERSION.bash

Other commands will be forthcoming.

Add README version updater command

A new "readme version updater" command is now available for use as a pre-tagging step. The command is based on the readme-version-updater-action.

Add command to update the runner in action.yml files

The best way to run a released GitHub action is to use a prebuilt docker
image. This saves time with building the image and guarantees that each
run will be using exactly the same action code.

This is best accomplished by settings runs.image to the image in question
in action.yml.

However, this does have a drawback of not being able to use arbitrary commits
to run with as that commit will be grabbed BUT... the image in its action.yml
will be used. This is problematic for testing actions.

The two commands included in this commit address both issues.

update-action-to-use-docker-image-to-run-action.py

Updates runs.image to a docker image with the version we are releasing.
As part of the release process for an action, it should then also make
sure to push a prebuilt image to DockerHub for the action in question.

This command should be run in the pre-tagging job.

update-action-to-use-dockerfile-to-run-action.py

Switches back to using Dockerfile for how to run the action.

This command should be run in the post-tagging job.

Add preartefact-changelog-check.bash command

The preartefact-changelog-check.bash command validates that the changelog contains an entry for X.Y.Z where X.Y.Z is the release that is underway.

The command can be used to protect against misconfiguration of workflows and more importantly, a user inadvertently pushing a X.Y.Z tag to start a release rather than the correct release-X.Y.Z.

Split "announce-a-release" into multiple different commands

Previously, release-bot-action had a command announce-a-release that did multiple things. It:

• Published release notes to GitHub
• Announced the release in the #announce stream of the Pony Zulip
• Added a note about the release to LWIP
• Deleted the announce-X.Y.Z tag used to trigger the command
• Rotated the release notes

In keeping with our project to break release-bot-action into a series of fine-grained commands, announce-a-release has been broken apart into multiple commands that can be called from steps in a GitHub actions workflow to compose functionality together on a per-project basis.

Those new commands covered in detail in our updated announce-a-release example in README.md. The new step commands are:

• add-announcement-to-last-week-in-pony.bash
• delete-announcement-tag.bash
• publish-release-notes-to-github.bash
• rotate-release-notes.bash
• send-announcement-to-pony-zulip.bash

Replaced all .bash commands with equivalent .py commands

As part of an internal cleanup, all commands written in bash have been rewritten to python and in the process, each was renamed. Full list of changes is below:

• add-announcement-to-last-week-in-pony.bash => add-announcement-to-last-week-in-pony.py
• add-unreleased-section-to-changelog.bash => add-unreleased-section-to-changelog.py
• delete-announcement-tag.bash => delete-announcement-tag.py
• pre-artefact-changelog-check.bash => pre-artefact-changelog-check.py
• publish-release-notes-to-github.bash => publish-release-notes-to-github.py
• rotate-release-notes.bash => rotate-release-notes.py
• send-announcement-to-pony-zulip.bash => send-announcement-to-pony-zulip.py
• trigger-artefact-creation.bash => trigger-artefact-creation.py
• trigger-release-announcement.bash => trigger-release-announcement.py
• update-changelog-for-release.bash => update-changelog-for-release.py
• update-version-in-corral-json.bash => update-version-in-corral-json.py
• update-version-in-VERSION.bash => update-version-in-VERSION.py

As part of this change, the input values to send-announcement-to-pony-zulip.py have changed from those to send-announcement-to-pony-zulip.bash. Whereas previously, a single environment variable called ZULIP_TOKEN was expected, we now need two ZULIP_API_KEY and ZULIP_EMAIL.

Remove file extension from commands

Previously all the release-bot-commands included a file extension like '.py'. We've removed all file extensions to allow for us to change the implementation language in the future without it being a breaking change.

Where a command might previously have been foo.py it is now simply foo.

[0.6.0] - 2021-07-14

Added

• Create images on release (PR #31)
• Add command to update the version in a README (PR #37)
• Add command to update the runner in action.yml files (PR #38)
• Add preartefact-changelog-check.bash command (PR #42)

Changed

• Replace "step" input parameter with overriding of entrypoint (PR #33)
• Switch supported actions/checkout from v1 to v2 (PR #34)
• Split "start-a-release" into multiple different commands (PR #35)
• Split "announce-a-release" into multiple different commands (PR #44)
• Rewrite all bash commands in Python (PR #46)
• Remove file extension from commands (PR #47)

0.5.0

Use annotated tags for releases

The release-bot-action will now use annotated rather than lightweight git tags when tagging releases.

To learn more about the differences in tag types, please see the documentation.

[0.5.0] - 2021-03-09

Changed

• Use annotated tags for releases (PR #30)

0.4.0

Allow for setting the default branch

GitHub is in the process of changing the default branch for all newly created repositories from master to main. When that happens, this action will stop working for any new repos as it has master hardcoded as the default branch.

With this change, release-bot-action now takes an optional input parameter default_branch that can be used to change what the default branch of the repo is.

The default branch is the branch that we push back changelog, release note, and other changes. The default is set to main to be forward compatible with what will become standard on GitHub. Because main was chosen as the default, this is a breaking change.

All repositories still using master as the default branch will need to set the default_branch value to master to continue working when they upgrade to a version of release-bot-action containing this commit.

Update version in corral.json on release

Prior to this release, the verison field in corral.json wasn't being updated on release.

[0.4.0] - 2021-02-07

Fixed

• Update version in corral.json on release (PR #28)

Changed

• Allow for setting the default branch (PR #24)

0.3.3

Fix broken trigger-release-announcement step

Version 0.3.2 incorrectly implemented overriding the version to trigger an announcement for. It fails in ways large and small.

[0.3.3] - 2020-08-30

Fixed

• Fix broken trigger-release-announcement step (PR #25)

0.3.2

Allow for overriding how trigger release announcement step gets version information

Adds an optional environment variable VERSION that can be set to an explicit value when using the trigger-release-announcement step instead of getting the version from GITHUB_REF.

The VERSION environment variable allows for a wider variety of ways to trigger the step. Prior to this change, the step would not work if it wasn't triggered by pushing a tag. With this change, you can now use it other workflows.

ponyc will use it to be triggered once assets are uploaded to Cloudsmith doing something slightly more complicated than the following simplified example:

name: Handle external events

on: repository_dispatch

jobs:
  trigger-release-announcement:
    if: |
      github.event.action == 'cloudsmith-package-synchronised' &&
      github.event.client_payload.data.repository == 'releases' &&
      github.event.client_payload.data.name == 'ponyc-x86-64-unknown-linux-musl.tar.gz'

    name: Trigger release announcement
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v1
      - name: Trigger
        uses: ponylang/[email protected]
        with:
          step: trigger-release-announcement
          git_user_name: "Ponylang Main Bot"
          git_user_email: "[email protected]"
        env:
          RELEASE_TOKEN: ${{ secrets.RELEASE_TOKEN }}
          VERSION: ${{ github.event.client_payload.data.version }}

[0.3.2] - 2020-08-30

Added

• Allow for overriding how trigger release announcement step gets version information (PR #23)

0.3.1

[0.3.1] - 2020-08-22

Fixed

• Fix bash-ism in formatting for GitHub release notes (PR #19)

0.3.0

[0.3.0] - 2020-08-13

Changed

• Make ASSET_NAME hardcoded (PR #11)
• Remove empty line in Last Week in Pony announcement (PR #12)