coreos / actions-lib Goto Github PK

I recently had a look at how the "require file change"-composite action is set up and noticed that it uses bare curl statements to retrieve the PR information it needs.

Is there a particular reason that the gh-cli isn't used for this? It is (to my knowledge) preinstalled on all GH provided runners and should make interacting with the API easier/more robust?

For example the diffinfo retrieval could be rewritten similar to:

diffinfo=$(gh pr view --repo "${{ github.event.pull_request.html_url }}" \
            --json 'files' \
            --jq '.files[] | select(.path == "${{ inputs.path }}")')

Instead of using:

diffinfo=$(curl --no-progress-meter \
            -H "Accept: application/vnd.github+json" \
            -H "Authorization: token ${{ inputs.token || github.token }}" \
            "https://api.github.com/repos/${{ github.repository }}/compare/${{ github.event.pull_request.base.sha }}...${{ github.event.pull_request.head.sha }}" |
            jq '.files[] | select(.filename == "${{ inputs.path }}")')

The label-retrieval would look similarly like this:

label=$(gh pr view --repo "${{ github.event.pull_request.html_url }}" \
         --json 'labels' \
         --jq '.labels[] | select(.name == "${{ inputs.override-label }}")')

Additionally, by setting GH_TOKEN with a value of ${{ inputs.token || github.token }} via the action environment authentication is fully handled.

Using a skip-notes label is convenient, but humans are creatures of habit and it doesn't take long before reviewers get used to seeing the skip-notes label and scan right past it.

One way to counter this is instead of a label, PR submitters that want to skip release notes have to either provide e.g. a footer in the initial PR description (such as skip-notes: <reason>) or alternatively as a stand-alone comment. This will increase the likelihood that reviewers read the reason and they may then decide to discuss it.

GitHub renders at most 10 annotations in the PR diff view and the workflow run summary page. An unlimited number of warnings is shown in the check-diff job log, but the log is less ergonomic, so usually it's not used when a reviewer is examining the diff. Thus it's possible that a reviewer might miss some changes.

Clearly indicate that some warnings have been elided, perhaps by emitting at most 9 warnings plus a notice to check the log.

We should investigate using:

• https://github.com/redhat-actions/buildah-build
• https://github.com/redhat-actions/push-to-registry

to replace our custom build and push action.