Zally issue creation sometimes omits commits

[ePaul]

We observed that some of the merges in this repository don't create a Zally issue, when they should have done so.

Examples:

• fix: fix internal link (#579) #579 (build), Usage of proprietary headers defined by Fashion Platform GW components #598 (build)

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.

[ePaul]

Other missed (and relevant) PRs:

• feat: allow compound keys in identifiers (#557) #564 (compound key identifiers),
  → manually created as feat: allow compound keys in identifiers (#557) zally#1182
• Added naming convention for enums #560 (naming conventions for enums)
  → manually included in clarify the UPPER_SNAKE_CASE rule for enums (#527) zally#1183

[ePaul]

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

[ePaul]

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 finds Merge pull request #591 from zalando/gh-589-fix-link, but not Added 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 chapters changed.
  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.

[tkrop]

Lets assume that #628 was finally fixing the issue.