github / branch-deploy

Enabling Branch Deployments through IssueOps with GitHub Actions - If you find this project useful, give it a star! ⭐️
https://github.com/marketplace/actions/branch-deploy
MIT License
384 stars 45 forks source link

How to prevent the action marking the whole workflow as successful before it finishes? #288

Closed alexbuznik-stark closed 2 months ago

alexbuznik-stark commented 2 months ago

Details

Hi.

I have a reusable workflow that deploys the branch to a testing environment. It is being called by another workflow which uses branch-deploy.

The problem is that workflow is marked as successful (and a respecting comment is added by github bot) before the actual deployment pipeline finishes

name: "Branch deploy by comment"

# The workflow to execute on is comments that are newly created
on:
  issue_comment:
    types: [created]

# Permissions needed for reacting and adding comments for IssueOps commands
permissions:
  pull-requests: write
  deployments: write
  contents: write
  checks: read
  statuses: read

jobs:
  parse-comment:
    if: ${{ github.event.issue.pull_request }}
    runs-on: ubuntu-latest
    outputs:
      environment: ${{ steps.parse-output.outputs.environment }}
      ref: ${{ steps.parse-output.outputs.ref }}
    steps:
      - uses: github/branch-deploy@v9.4.0
        id: parse-output
        with:
          trigger: ".deploy"
          environment: "sb1"
          environment_targets: sb1,sb2,sb3,sb4,sb5,sb6,sb7,sb8,sb9,sb10

  # <--- The workflow is marked as success **here**

  deploy-to-sandbox:
    needs: parse-comment
    uses: ./.github/workflows/build-and-deploy-sandbox.yml@main
    if: ${{ needs.parse-comment.outputs.ref }} != 0
    with:
      deployment_target: "Deploy to sandbox ${{ needs.parse-comment.outputs.environment }}"
      ref: ${{ needs.parse-comment.outputs.ref }}

  finalize:
    runs-on: ubuntu-latest
    needs: [deploy-to-sandbox, parse-comment]
    if: always()
    steps:
      - name: Deployment complete
        run: echo "Deployment to sandbox ${{ needs.parse-comment.outputs.environment }} complete."

  # <--- I want the workflow to be marked as success **here**
GrantBirki commented 2 months ago

👋 Hey @alexbuznik-stark! Thanks for opening this question and its a good one to ask. I do have the answers for which you seek.

See this example workflow below:

jobs:
  demo: # <--- here we define a STEP and put ALL branch-deploy logic beneath it
    if: ${{ github.event.issue.pull_request }} # only run on pull request comments
    runs-on: ubuntu-latest
    steps:
      # Execute IssueOps branch deployment logic, hooray!
      # This will be used to "gate" all future steps below and conditionally trigger steps/deployments
      - uses: github/branch-deploy@vX.X.X
        id: branch-deploy
        with:
          trigger: ".deploy"

      # Run your deployment logic for your project here - examples seen below

      # Checkout your projects repository based on the ref provided by the branch-deploy step
      - uses: actions/checkout@v4
        with:
          ref: ${{ steps.branch-deploy.outputs.ref }}

      # Do some fake "noop" deployment logic here
      # conditionally run a noop deployment
      - name: fake noop deploy
        if: ${{ steps.branch-deploy.outputs.continue == 'true' && steps.branch-deploy.outputs.noop == 'true' }}
        run: echo "I am doing a fake noop deploy"

      # Do some fake "regular" deployment logic here
      # conditionally run a regular deployment
      - name: fake regular deploy
        if: ${{ steps.branch-deploy.outputs.continue == 'true' && steps.branch-deploy.outputs.noop != 'true' }}
        run: echo "I am doing a fake regular deploy"

In this example workflow, the demo "step" contains all the logic for the branch-deploy workflow. Out-of-the-box, the branch-deploy workflow contains a post run step that runs after the calling "step" in the workflow completes. This post logic finds the deployment which was started and completes it with either a successful state, or failure state (a little green or red rocket on your PR 🚀).

Well... having a workflow automatically complete after the step finishes is going to be what most people want and is great for convenience. However, it does not work for everyone's use case as you have figured out for yourself.

Fear not! I have run into this issue myself and it is documented and you can work around it. You can set the skip_completing input to "true" and this will skip the logic where branch-deploy marks your deployment as a success/failure after the step completes. You will need to manually set your deployment status but there are plenty of examples for doing so.

Examples:


Read more here

alexbuznik-stark commented 2 months ago

Hey @GrantBirki Thank you, it's exactly what I needed.

I'm marking a deployment complete like this. Is there a cleaner/easier way?

  finalize:
    runs-on: ubuntu-latest
    needs: [parse-comment, deploy-to-sandbox]
    if: ${{ needs.deploy-to-sandbox.result == 'success' }}
    steps:
      - name: Deployment complete
        run: |
          gh api \
            --method POST \
            -H "Accept: application/vnd.github+json" \
            -H "X-GitHub-Api-Version: 2022-11-28" \
            /repos/alexbuznik-stark/test-monday/deployments/$DEPLOYMENT_ID/statuses \
            -f environment=$ENVIRONMENT -f "state=success" -f "description=Deployment finished successfully."
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          DEPLOYMENT_ID: ${{ needs.parse-comment.outputs.deployment_id }}
          ENVIRONMENT: ${{ needs.parse-comment.outputs.environment }}
GrantBirki commented 2 months ago

@alexbuznik-stark I do something like this which I think is a bit cleaner and uses variables to make things slightly more dynamic. Either way though, its still not super clean and could probably benefit from being another Action workflow (custom) that is like this:

- uses: <org>/complete-deployment@vX.X.X
  id: complete-deployment
    with:
      token: ${{ secrets.GITHUB_TOKEN }}
      deployment_id: <value>
      environment: <value>
...

But of course, this does not exist today and would need to be created. It would help to cleanup the workflows though if someone were to just bundle all that logic into a simple and clean Action.