Error on getting status

[BravoNatalie]

I'm having an issue with the getting status.

[BravoNatalie]

This behavior happens if the PR does not have any checkers, so to get through this issue I added the mergeable property into the stateQuery.

const stateQuery = `query($owner: String!, $repo: String!, $pull_number: Int!) {
                                  repository(owner: $owner, name: $repo) {
                                    pullRequest(number:$pull_number) {
                                      mergeable
                                      commits(last: 1) {
                                        nodes {
                                          commit {
                                            statusCheckRollup {
                                              state
                                            }
                                          }
                                        }
                                      }
                                    }
                                  }
                                }`
const vars = {
  owner: context.repo.owner,
  repo: context.repo.repo,
  pull_number: pull['number']
};

const result = await github.graphql(stateQuery, vars);
const [{ commit }] = result.repository.pullRequest.commits.nodes;

if(commit.statusCheckRollup != null){
  const state = commit.statusCheckRollup.state
  console.log('Validating status: ' + state);
  if(state != 'SUCCESS') {
    console.log('Discarding ' + branch + ' with status ' + state);
    statusOK = false;
  }
} else {
  const mergeable = result.repository.pullRequest.mergeable
  console.log('PR does not have statusCheckRollup, but mergeability is: ' + mergeable);
  if(mergeable !== 'MERGEABLE'){
    console.log('Discarding ' + branch + ' with mergeability: ' + mergeable);
    statusOK = false;
  }
}

[martingjaldbaek]

Hi @BravoNatalie - thanks for the PR!

And sorry this took some time to look at - first off, life happened. But secondly I also wasn't sure if this was strictly an improvement, or if there was a risk of causing problems/confusion, so I've been mulling this over. Here are the issues I've been considering:

1) There is already the option of setting "mustBeGreen" to false, as a way to work with PRs that don't get checks run on them

• (Judging by the number of likes on this PR, I think I might need to highlight that more in the documentation, or have "mustBeGreen" default to false, to help those that don't have time to figure out what all the parameters mean) 2) Adding a second alternative interpretation of "mustBeGreen" - that it automatically falls back to - runs the risk of having mis-configurations of checks go unnoticed. I'm wondering if instead of a boolean for mustBeGreen, we should have an enum - e.g. "requirements" that could be either "None", "Green" or "Mergeable", so the user can explicitly opt into the behavior they want? 3) PRs with UNKNOWN/not-yet-defined mergeability will be left out of the combined PR. In my tests, if I had recently made any change to the base branch, then all PRs had status UNKNOWN and were left out. If I view any specific PR on GitHub, this nudges GitHub to update its mergeability status again, and it gets included in subsequent runs of the workflow.
• I feel like this is quite a "gotcha" that users probably won't expect. Part of the point of this workflow is to avoid manual process. Is there a way we can nudge GitHub to update the mergeability status, and wait for that to complete, during the workflow? If not, we should at least consider listing the PRs that are left out of the Combined PR due to unkown mergeability, like we currently do with those left out due to merge conflicts. 4) The are some unrelated linter changes in the PR. After mulling it over, I'm ok with using double-quoted strings, so whatever

Overall, if it wasn't for 3) I would have merged this already. But I do worry that having the workflow be able to silently fail for non-obvious reasons is a bit of a foot-gun for users. Any thoughts?

[bruteforks]

maybe specifying what permissions need to be applied could help. I'm getting this same error after trying to fix this error: "[HttpError]: Resource not accessible by integration"