Skip to content

Releases: gruntwork-io/patcher-action

v2.3.0

17 Dec 01:51
4d93d93
Compare
Choose a tag to compare

What's Changed

breaking

boring

Full Changelog: v2.2.0...v2.3.0

v2.2.0

26 Nov 21:16
9fb6e2f
Compare
Choose a tag to compare

What's Changed

  • add ability to use a read PAT for report and update, separately from publish PAT by @ceschae in #51

Full Changelog: v2...v2.2.0

v2

26 Nov 21:18
9fb6e2f
Compare
Choose a tag to compare

This is a floating release tracking the latest v2.y.z release.

v2.1.1

18 Nov 22:40
b36bf56
Compare
Choose a tag to compare

What's Changed

  • add description and default for 'update_token' input by @ceschae in #50

Full Changelog: v2.1.0...v2.1.1

v2.1.0

15 Nov 00:24
b1d692e
Compare
Choose a tag to compare

What's Changed

  • Add the ability to provide a separate auth token vs. patcher update token by @ceschae in #49
    • in additon to github_token, you can specify update_token! the latter will specifically be used for writing PRs to your repo as a result of patcher update, the former will be used only to validate that you are a customer of Gruntwork and can use Patcher.

Full Changelog: v2...v2.1.0

v2.0.2

09 Oct 17:35
d8e117a
Compare
Choose a tag to compare

What's Changed

interesting stuff

chores

Full Changelog: v2.0.1...v2.0.2

v2.0.1

04 Oct 20:03
a1c7414
Compare
Choose a tag to compare

What's Changed

  • use patcher version 0.9.1 by @ceschae in #45
    • bug: check correct field when parsing github error response for already existing PR for patcher update
    • dependabot chores
  • use patcher version 0.9.3 by @ceschae in #46
    • bring patcher's terragrunt import up to version 0.66.2
    • don't add changes to spec files to created PRs during patcher update
  • Bump micromatch from 4.0.5 to 4.0.8 by @dependabot in #47

New Contributors

Full Changelog: v2.0.0...v2.0.1

v2.0.0

10 Jul 15:57
4ed18da
Compare
Choose a tag to compare

Promotion Workflows 2.0

The Patcher Action and Promotion Workflows now have better options for controlling the granularity of opened pull requests. Additionally, we have built several new features that were requested directly into the Patcher engine. This approach makes the logic required in your GitHub Action workflows much simpler and easier to maintain.

The major new features include:

  • The ability to selectively include or exclude directories when using the report command. For example, you could selectively include the dev-account1 and dev-account2 directories to ensure a "dev" environment upgrade applies to both accounts.
  • The ability to generate an upgrade specification that ensures the included dependencies are updated to the same version across all environments.
  • Options for configuring the pull request branches and titles.
  • A dry-run mode for simulating all Patcher operations. This is useful for test jobs to validate your workflows.
  • New example workflows.

Please refer to the README.md files and the examples for a more comprehensive overview of the changes.

Migration Guide

Changes to Report outputs

The report command previously had an output named dependencies. This has been renamed (and the contents have changed) and is now called spec. The spec output is actually a json string, one of whose top level keys is Dependencies.

Changing the matrix

Previously common usage of patcher would matrix over the dependencies output from report as follows:

      matrix:
        dependency: ${{ fromJson(needs.patcher-report.outputs.dependencies) }}

This should be updated to

      matrix:
        dependency: ${{ fromJson(needs.patcher-report.outputs.spec).Dependencies }}

If you're using the full promotion workflow pattern then you'll want to specify for higher environments to only update the dependency from the repository_dispatch event as follows:

     matrix:
        dependency: ${{ github.event.client_payload.dependency && fromJson(format('[{{"ID"{0} "{1}"}}]', ':', github.event.client_payload.dependency)) || fromJson(needs.patcher-report.outputs.spec).Dependencies }}

Changing the call to update

The update command now requires the spec file, so you'll need to add a step to create the file from the prior steps output to be passed in to patcher-action. The update call will also need a unique value for pull_request_branch and pull_request_title

      - name: Create the spec file
        shell: bash
        run: |
          echo '${{ needs.patcher-report.outputs.spec }}' > patcher-spec.json

      - uses: gruntwork-io/patcher-action@v2
        with:
          patcher_command: update
          dependency: ${{ matrix.dependency.ID }}
          spec_file: patcher-spec.json
          pull_request_branch: "patcher-dev-updates-${{ matrix.depenency.ID }}"
          pull_request_title: "[Patcher] [dev] Update ${{ matrix.dependency.ID }}"
          [...snip]

Under the hood

  • We have directly moved most of the business logic into the Patcher engine. This makes it easier to iterate and gives us more control over the upgrade.
  • We have dropped the yarn test target. The Jest tests provided very limited value, and it makes much more sense to expand the GHA workflow test coverage instead.

Full Changelog: v0.2.2...v2.0.0

v1.2.2

20 Jun 03:39
6200fe3
Compare
Choose a tag to compare

What's Changed

  • Bump Patcher to v0.8.4 in #37
  • Bump Docs and Example Dependencies in #38

Full Changelog: v1.2.1...v1.2.2

v1.2.1

13 Jun 04:19
6200fe3
Compare
Choose a tag to compare

What's Changed

  • Bump Patcher to v0.8.2 in #36

Full Changelog: v1.2.0...v1.2.1