Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix computing effective branch name from GITHUB_REF on GHA #4

Draft
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

amotl
Copy link
Contributor

@amotl amotl commented Dec 19, 2021

Hi again,

while working on #2 and #3, I discovered that the github_action_env routine did not compute the branch attribute from the GITHUB_REF environment variable properly, when the effective branch name contained slashes.

661ed32 fixes it and adds another test test_github_parse_branch_from_ref, which exercises GITHUB_REF with those combinations:

  • refs/heads/feature-branch-1
  • refs/heads/author/feature-branch-1
  • refs/heads/realm/author/feature-branch-1

With kind regards,
Andreas.

amotl added 12 commits December 18, 2021 13:59
Now, `jenkins_env` and `github_action_env` will only be tested through
`get_ci_info`. That is the main adapter function anyway.
This is just a minor fix for the test suite to adjust path semantics for
Windows, which uses backslashes as directory separators instead of slashes.
Actually, the `test_upload_files_success` test should have revealed it.
However, we discovered that when mocking the `NamedTemporaryFile`
object, we created an instance instead of propagating a factory.

That is wrong, because it expands the scope of the temporary file to
the whole test case, and not the scope of the `test_upload_files`
function only.
Apparently, mocking `urllib.urlopen()` will not trigger the flaw within
a test case on Windows.

So, let's use a different strategy by mocking the socket object instead.
In this manner, the whole machinery of `urllib` and `http.client` will
still be active, hopefully revealing the incompatibility with Windows.
Windows places an exclusive lock on files opened for writing. So,
opening the temporary tarfile twice (once by `NamedTemporaryFile` and
another time by `tarfile.open(fd.name)` makes things croak with
`PermissionError: [Errno 13] Permission denied`.

Instead, let's reuse the file handle already opened by
`NamedTemporaryFile`.
There was a flaw when running directly on a branch (no PR) on GHA, and
the branch contained slashes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant