Option to ignore locks, for secondary operations against environments

[hashtagchris]

Details

Thanks for the awesome action. npm already uses branch-deploy for deploying code changes and schema migrations.

We're looking at using branch-deploy to trigger data transitions (backfills) as well, which may need to run for days. We typically run .lock --global ahead of deploying code changes, but that blocks all executions of github/branch-deploy, regardless of trigger. I'm wondering if there's a way we can have code changes and transitions deploying independently.

Is there a way our transition workflow could ignore the global lock? Or could there be multiple types of locks, such that there's a global deployment lock, but also a global transition lock?

- name: branch-deploy
  uses: github/branch-deploy@10.0.0
  with:
    trigger: .transition
    lock_type: transition

🤔 I see there's also a github/command action which likely ignores locks, but we'll need some way of referring to an environment.

[GrantBirki]

Thanks for the awesome action. npm already uses branch-deploy for deploying code changes and schema migrations

Of course! I remember many moons ago helping @tiagonbotelho get branch-deploy wired up for deploying npm's infrastructure and then later meeting up with him in London... good times! Anyways, glad to see its still serving you well.

The github/command is suited for more general IssueOps tasks, where the branch-deploy Action is truly designed with shipping things to production in mind. Whether that be code, deploying Terraform infrastructure, spawning stuff in k8s, etc. You can certainly leverage/coerce branch-deploy to do other things though like a transition.

github/command does not take locks or environments into account so if you find that they are really getting in your way, maybe it is time to take a look at github/command instead. That being said, github/command is certainly less "battle-tested" and does not come with as many guard rails as github/branch-deploy does.

Alternatively, you might be able to just put all your .transition logic behind an Actions workflow that gets fired on a workflow_dispatch event.

[hashtagchris]

Thanks! Good call out about the guard rails.

If it helps anyone else, I've had some early success scaffolding transitions with github/command.

Example invocation: .transition | production

name: 'IssueOps - Database Transitions'

on:
  issue_comment:
    types: [created]

permissions:
  pull-requests: write
  checks: read
  contents: read

jobs:
  apply-transition:
    # save on Actions Compute and energy usage
    # see https://github.com/github/branch-deploy?tab=readme-ov-file#saving-on-actions-compute
    if: ${{ github.event.issue.pull_request && startsWith(github.event.comment.body, '.transition') }}
    runs-on: ubuntu-latest
    steps:
      - uses: github/command@v2.0.0
        id: command
        with:
          command: ".transition"

      - name: Resolve arguments
        id: resolve-args
        if: ${{ steps.command.outputs.continue == 'true' }}
        run: |
          echo "ChatOp parameters: ${{ steps.command.outputs.params }}"
          echo "Normalizing target environment"
          if [[ "${{ steps.command.outputs.params }}" == "sandbox" ]]; then
            echo "ENVIRONMENT=sandbox" >> $GITHUB_OUTPUT
          elif [[ "${{ steps.command.outputs.params }}" == "staging" ]]; then
            echo "ENVIRONMENT=sandbox" >> $GITHUB_OUTPUT
          elif [[ "${{ steps.command.outputs.params }}" == "production" ]]; then
            echo "ENVIRONMENT=production" >> $GITHUB_OUTPUT
          else
            echo "Invalid environment specified"
            exit 1
          fi

      - name: run transition in sandbox
        if: ${{ steps.resolve-args.outputs.environment == 'sandbox' }}
        run: |
          echo "Running transition in sandbox"

      - name: run transition in production
        if: ${{ steps.resolve-args.outputs.environment == 'production' }}
        run: |
          echo "Running transition in production"