Fix git ls-remote command when running sg-bridge

[vkmc]

Fix git ls-remote command in the integration suite

The syntax should be refs/heads/GITHUB_REF

[csibbitt]

Can you describe the problem that this fixes? I have a guess based on working through it, but would like to be sure.

My understanding (subject to correction!) based on reading the github docs[1] is:

• This expression "${GITHUB_REF#refs/heads/}" (which you're removing) is meant to produce the source branch name (like "feature-branch-1") by removing "refs/heads/" from the beginning of the fully qualified version.
• GITHUB_HEAD_REF is just the bare source branch name (like "feature-branch-1"), so should(?) be equivalent to the expression above.
• I believe the expression above may have been used in preference because GITHUB_HEAD_REF is only available in a PR, not other types of workflow.
• This new expression "refs/heads/${GITHUB_HEAD_REF}" (which you're adding) seems to produce the fully qualified branch name from the bare name and in my mind should be equivalent to GITHUB_REF.

So AFAICT this change does two things:

• Switch from using bare branch names to fully qualified names in several places. Is this necessary?

  $ git ls-remote --exit-code --heads https://github.com/infrawatch/sg-bridge.git "$(echo "refs/heads/stable-1.5")"
  1029feb2e638b434c210a98ab30c7f3f0f3ed683        refs/heads/stable-1.5
  
  $ git ls-remote --exit-code --heads https://github.com/infrawatch/sg-bridge.git "$(echo "stable-1.5")"
  1029feb2e638b434c210a98ab30c7f3f0f3ed683        refs/heads/stable-1.5
  

• Breaks this workflow when it's triggered by a push, rather than a pull request (I don't know if we depend on this anywhere, but we do execute it[2])?

Is the problem that ${GITHUB_REF#refs/heads/} is not working as expected because on a PR GITHUB_REF is "refs/pull/<pr_number>/merge" instead of "refs/heads/<branch_name>"? I could imagine this bug if this was developed/tested locally and never re-checked in an actual PR.

If that's the problem you're trying to solve, and you'd like to preserve the push workflow, then the following might work: ${GITHUB_HEAD_REF:-${GITHUB_REF#refs/heads/}}

This will default to using the bare branch name in GITHUB_HEAD_REF when it's available in a PR, and will fall back to parsing it out of the GITHUB_REF when operating on a branch in a push workflow, where "refs/heads" will be correct.

[1] https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#default-environment-variables
[2] https://github.com/infrawatch/sg-core/pull/140/files#diff-82454b2fc887e9985b9348b8f3bca03d2f839645a4c3ba1f3f850014d7da5c8bL16

[vkmc]

While working on other patches, I noticed that the action of looking for an existing branch with the same name in the sg-core repository was not really being honored.

Digging into it, I got to the Github documentation here https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#default-environment-variables, which states the following

GITHUB_REF: The fully-formed ref of the branch or tag that triggered the workflow run. For workflows triggered by push, this is the branch or tag ref that was pushed. For workflows triggered by pull_request, this is the pull request merge branch. For workflows triggered by release, this is the release tag created. For other triggers, this is the branch or tag ref that triggered the workflow run. This is only set if a branch or tag is available for the event type. The ref given is fully-formed, meaning that for branches the format is refs/heads/<branch_name>, for pull requests it is refs/pull/<pr_number>/merge, and for tags it is refs/tags/<tag_name>. For example, refs/heads/feature-branch-1.

For how our CI work, we trigger this action on PRs. So the resulting value for this variable would be refs/pull/<pr_number>/merge. So we never actually pick up if there is a branch with the same name. I wanted to fix that by constructing the path.

Maybe I misunderstood the actual use case of this action?

[csibbitt]

Maybe I misunderstood the actual use case of this action?

Reading over your explanation I don't think you've misunderstood at all! I was trying to work out what was broken and why without any details, and it seems my guesses were correct. My feedback is that the solution appears like it will break the push workflow. I have suggested an alternative solution that I think is more straightforward to read and doesn't break that workflow.

I'm happy to approve this if you're sure the push workflow is not necessary.

[vkmc]

Thanks for the review and sorry for the lack of context in my pull request. Next time I will provide more details for reviewers to work with.

I agree that this proposed patch breaks the push workflow and that is, indeed, an unintended change. I was not sure how to properly fix the issue I was seeing.

I will submit your suggested fix instead.

Thanks Chris!

[softwarefactory-project-zuul]

Build failed (check pipeline). Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.

https://softwarefactory-project.io/zuul/t/rdoproject.org/buildset/63ac85237f88451696d388e611f8fb4c

❌ stf-crc-ocp_414-local_build RETRY_LIMIT in 16m 53s
✔️ stf-crc-ocp_416-local_build SUCCESS in 35m 49s
✔️ stf-crc-ocp_414-local_build-index_deploy SUCCESS in 46m 11s
✔️ stf-crc-ocp_416-local_build-index_deploy SUCCESS in 41m 34s
✔️ stf-crc-ocp_414-nightly_bundles-index_deploy SUCCESS in 32m 53s
❌ stf-crc-ocp_416-nightly_bundles-index_deploy POST_FAILURE in 28m 04s

[vkmc]

recheck