v2.0.0

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