You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm opening a new issue to avoid the comments being buried within the various alpha deployment pull requests.
I didn't success to make it run. What I checked so far
All relevant organization and repo settings seem to be the same between ecamp and bacluc-test-org
The API response within the workflow and the response when hitting the API manually is in many cases different
I was able to reproduce this on bacluc-test-org. In many cases, querying the API manually got me "pending" while the workflow said "blocked"
However, on bacluc-test-org the final run after all tests passed always succeeds
Caching
Cached responses could theoretically be a cause. There are discussion and solutions about this on octokit repo (which is utilized by actions/github-script). I don't think server/API cache is the issue, though. The comments property which counts the number of comments on the pull request was consistently increasing. octokit/octokit.js#890 (comment) pascalgn/automerge-action#122 (comment)
Other hypotheses:
The user that queries the API always receives blocked for some reason.
The workflow temporarily sets the pull request to blocked
A bug in GitHub API on an undocumented API property
1. The user that queries the API always receives blocked for some reason.
I would have guessed, the API call is being done by the user who triggers the workflow which is the user who leaves the comment in the pull request. Didn't debug further.
2. The workflow temporarily sets the pull request to blocked
I tried to query the API manually while the workflow is running. Couldn't confirm this so far, unless the change in status is happening for a very short time.
I'm opening a new issue to avoid the comments being buried within the various alpha deployment pull requests.
I didn't success to make it run. What I checked so far
Caching
Cached responses could theoretically be a cause. There are discussion and solutions about this on octokit repo (which is utilized by actions/github-script). I don't think server/API cache is the issue, though. The comments property which counts the number of comments on the pull request was consistently increasing.
octokit/octokit.js#890 (comment)
pascalgn/automerge-action#122 (comment)
Other hypotheses:
1. The user that queries the API always receives blocked for some reason.
I would have guessed, the API call is being done by the user who triggers the workflow which is the user who leaves the comment in the pull request. Didn't debug further.
2. The workflow temporarily sets the pull request to blocked
I tried to query the API manually while the workflow is running. Couldn't confirm this so far, unless the change in status is happening for a very short time.
3. A bug in GitHub API on an undocumented API property
This hypothesis would be supported by the fact that other users are struggling with mergeable_state:
pascalgn/automerge-action#122
pascalgn/automerge-action#103
Expensify/App#9625
The text was updated successfully, but these errors were encountered: