Publishing download links in the check details instead of posting a comment

Hi, we just built a workflow to build a preview version in a pull-request, and push this build to our download server: https://github.com/deltachat/deltachat-desktop/blob/master/.github/workflows/build-preview.yml

Part of the workflow is that we want to provide the download links to the contributors directly. Right now we do this by posting a comment to the PR, but it’s very noisy to have a comment for every commit. Instead we’d like to display the download links in the checks overview below, e.g. where it says “Details”.

Is there a way to do this conveniently? I couldn’t find anything in the documentation, neither could I find an Action or Job which does it already, there is only the one for posting comments.

You can post it to GitHubs API yourself.

We have som project where we do something along this (shell script):

GITHUB_API_URL="https://api.github.com/repos/${PROJECT_USERNAME}/${PROJECT_REPONAME}/statuses/${SHA1}"

STATE=success

STATUS_DATA="{\"state\": \"${STATE}\", \"description\": \"Report\", \"context\": \"My status\", \"target_url\": \"${ARTIFACT_URL}\"}"

curl --fail --silent -X POST --user ":${GITHUB_TOKEN}" "${GITHUB_API_URL}" --data "${STATUS_DATA}"

(ok, we do that from CircleCI but I think you should be able to do it from an action as well.

1 Like

cool, will try it out!

1 Like

Hm, I’m playing around with it, but the API doesn’t seem to do anything. Neither does it give me a proper error message. Where would the message pop up?

Do I need to use a user with write access to the repository, or is it okay to use the Github actions bot for this? Or is there something else I did wrong?

https://github.com/deltachat/deltachat-desktop/pull/1116/files#diff-e897be051354af89d81ad484418359d5R74

The request itself looks fine to me in the logs: https://github.com/deltachat/deltachat-desktop/pull/1116/checks?check_run_id=291090229

Weird. I think somethings wrong with SHA, but cannot figure out why.

Your action posts the status to the SHA c239d9ac7d5b5a47d2fc28892c55cdd226facd2c but I can’t find that SHA in repos / in the PR. From the PR it looks like the SHA should be ae82c8b4a7b9f74672bf5881b0095141f1aac700.

1 Like

Hm, this seems to be the merge commit which would be generated when the PR would be merged after this commit: https://github.com/deltachat/deltachat-desktop/tree/c239d9ac7d5b5a47d2fc28892c55cdd226facd2c

I read something in this direction in some thread. I guess I need that commit ID so the build job can be referenced correctly?

Could it be github.ref instaed of github.sha?

I had a debug dump of the github context somewhere but can’t find it …

Nah… It should be github.sha  … 

I made a test over at https://github.com/arnested/playground/pull/4 and github.sha  corresponds to the commit in PR … weird

1 Like

Posting a status worked for me in: https://github.com/arnested/playground/pull/5

Still no clue on what’s different in your example…

1 Like

Ah, the difference is that you are using a push event, not a pull-request event. push events don’t create a merge commit, but use just their own commit’s SHA. PR events create a merge commit and use that SHA.

The best solution would probably be if the API would answer to the merge commit’s SHA. Do you know where I could open an issue for that?

I got it! I could get the SHA from the PR event: https://github.com/deltachat/deltachat-desktop/pull/1116/files

Thanks so much for taking your time to debug this with me! I learned a lot.

1 Like

Cool. I didn’t notice yours was triggered on a pull_request event.

I dived a bit more into it. It appears you can the right SHA in a pull request from ${{ github.event.after }} (can also be used on push events).${{ github.event.head_commit.id }}also looks like a possibility.

I made a new PR for testing this: https://github.com/arnested/playground/pull/6

There is two workflows: one triggering on push and one on pull_request. Both dumps the the context for debugging and both post a status.

Uh, great. I will refactor my code I guess, that is way more beautiful.

1 Like

Note for later reference; all three solutions have the problem that they can’t get the commit sha for the first commit in a PR. I tried all of them:

If someone finds a solution in the future, let me know :wink: