Zally issue creation sometimes omits commits
ePaul opened this issue · 4 comments
We observed that some of the merges in this repository don't create a Zally issue, when they should have done so.
Examples:
Analysis:
It looks like the result of https://api.github.com/repos/zalando/restful-api-guidelines/pulls/598/files (and similar) didn't return useful results (possibly an error?), which resulted in a error of jq, and then the rest of the script thought that nothing changed, and decided not to create a Zally issue.
GitHub's commit information API lags a bit behind the actual commits. So when it doesn't return anything, we might need to wait a bit and retry, when this happened.
Other missed (and relevant) PRs:
- #564 (compound key identifiers),
→ manually created as zalando/zally#1182 - #560 (naming conventions for enums)
→ manually included in zalando/zally#1183
Potential (partial) solution:
- wait a moment before fetching the files for a merged PR.
- (if feasible) in the error case, wait a bit and try again
- in case of doubt, create an issue
We invested a bit more time to figure out what happened.
- The travis-deploy.sh script is trying to figure out which PR belongs to the merge commit. It is using jq's
capture("#(?<n>[0-9]+) ")to find the PR number from the merge commit. This findsMerge pull request #591 from zalando/gh-589-fix-link, but notAdded naming convention for enums (#560). If it fails, no issue is created. - After that, the script is trying to look at the files for the PR, to check whether a file in
chapterschanged.
This sometimes fails, because the Github API doesn't return any data yet – in this case, no issue is created.
To make it more robust, we would need to:
- fix the regexp
- add a loop for the second request too
- as a fallback, if we didn't get anything, still create an issue.