github/branch-deploy

commitStatus: null

GrantBirki opened this issue · 9 comments

Please note, this is not an issue that I opened, this issue is one that I copied over from a GitHub discussion by @JoaoMJoia

Hello guys,
I'm using your job in my workflow.
After I created a PR and all the CI checks passed and I got an approval I tried to run the deploy command but I kept receiving this message

`### ⚠️ Cannot proceed with deployment

  • reviewDecision: APPROVED
  • commitStatus: null

This is usually caused by missing PR approvals or CI checks failing`

I look at the branch-deploy job and I found this message on the setup

`environment: ./terraform/test/elastic/
.deploy test command used on current branch - setting ref to PD-12605
Could not retrieve PR commit status: TypeError: Cannot read properties of null (reading 'state') - Handled: OK
Skipping commit status check and proceeding...
Error: ### ⚠️ Cannot proceed with deployment

  • reviewDecision: APPROVED
  • commitStatus: null

This is usually caused by missing PR approvals or CI checks failing`

May you guys have any idea why this happened ?

My job config

  • name: Setup branch-deploy
    id: branch-deploy
    uses: github/branch-deploy@v4.3.0
    with:
    trigger: ".deploy ${{ env.TF_ENVIRONMENT_FOLDER }}"
    noop_trigger: "plan"
    environment: ${{ matrix.directory }}
    stable_branch: "main"

Originally posted by @JoaoMJoia in https://github.com/github/branch-deploy/discussions/109

@JoaoMJoia Have you verified that the permissions block in your workflow contains at least the following?

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

The following message in your logs:

Could not retrieve PR commit status: TypeError: Cannot read properties of null (reading 'state') - Handled: OK

is actually not of any concern (usually). If your repository does not have any CI checks defined, the result will always be null and when that is the case, the code will "handle" this exception (as stated in the log line) and assume that now CI checks are defined so they are not evaluated as blocking conditions. If you do indeed have CI checks defined, then I would be worried why this message is coming back as null. My first thought would be that the perhaps the permissions in your workflow are not setup properly and that the Action cannot read the check so it is coming back as null. My above comment touches on this to ensure that the correct permissions are set.

checks: read # allows Actions to read information about CI checks

If your permissions are indeed correct, it would be useful if you could re-run your CI job and check the little "debug logging" box in Actions which allows for verbose logs of the branch-deploy workflow. You can check your logs before pasting them here to ensure they don't contain any sensitive information. If they look safe to post publicly, myself or another user can investigate your logs. Thanks!

Hello @GrantBirki. I have checked and I have the permissions defined.
I'm going to test again the workflow to see if it happens again or not.

7e53efb#r108630999

This causes issues where there are no CI checks and the reviewDecision === 'APPROVED' -- there is no condition block that allows the deployment to proceed under these circumstances. You always end up in the last else block.

In other words, it is no longer possible to use branch-deploy in repositories where there are no status checks. We add a validation that a successful deployment to an environment passes, but do not have any CI checks.

@dmccaffery Would you be able to try using the latest "pre-release" of this Action and see if it resolves your problem?

Thanks!

v5.2.1

I was able to confirm this works on a repo with no status checks enabled and an approved pull request

GrantBirki/actions-sandbox#41

I'll go ahead and close out this issue as this appears to be fixed now. @dmccaffery please feel free to reopen this issue if there are any problems or if you have further questions.

I was facing this issue as well, when this plugin was newly out, I initially thought I was using it wrongly, hence ignored it and to get this plugin to work - our devs had to push in a empty commit , trigger the CI and get a small green tick and all would be good...but anyway I am glad this was fixed and I am now using the v5.2.1