Skip to content

[skip changelog] Restore globbing of nightly build artifact filename #1781

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

Merged
merged 1 commit into from
Jun 23, 2022
Merged

[skip changelog] Restore globbing of nightly build artifact filename #1781

merged 1 commit into from
Jun 23, 2022

Conversation

per1234
Copy link
Contributor

@per1234 per1234 commented Jun 23, 2022

Please check if the PR fulfills these requirements

  • The PR has no duplicates (please search among the Pull Requests
    before creating one)
  • The PR follows
    our contributing guidelines
  • [N/A] Tests for the changes have been added (for bug fixes / features)
  • [N/A] Docs have been added / updated (for bug fixes / features)
  • [N/A] UPGRADING.md has been updated with a migration guide (for breaking changes)

What kind of change does this PR introduce?

Bug fix

What is the current behavior?

During a refactoring of the "Publish Nightly Build" workflow (f96ce4b), globbing of the macOS build artifact filename in the repackaging step was accidentally lost, causing the glob pattern to be treated instead as a string and the updated package saved to a file named by that string instead of to the original filename.

This resulted in the workflow failing with errors like:

https://github.com/arduino/arduino-cli/actions/runs/2546192732

Artifact path is not valid: /arduino-cli_nightly-*macOS_64bit.tar.gz. Contains the following character: Asterisk *

What is the new behavior?

The previous basename command was providing the globbing. After the refactoring, basename is no longer needed, so an alternative way to achieve globbing is needed. It seems the preferred approach is use of an array. Since the globbing will only expand to a single filename, the array can be referenced as before by the rest of the step, since it will resolve to the first element in the array (equivalent to $PACKAGE_FILENAME[0]).

Does this PR introduce a breaking change, and is titled accordingly?

No breaking change

Other information

Demonstration run of the updated workflow in my fork here: https://github.com/per1234/arduino-cli/actions/runs/2547150008

During a refactoring of the "Publish Nightly Build" workflow, globbing of the macOS build artifact filename in the
repackaging step was accidentally lost, causing the glob pattern to be treated instead as a string and the updated
package saved to a file named by that string instead of to the original filename.

This resulted in the workflow failing with errors like:

Artifact path is not valid: /arduino-cli_nightly-*macOS_64bit.tar.gz. Contains the following character: Asterisk *

The previous `basename` command was providing the globbing. After the refactoring, `basename` is no longer needed, so an
alternative way to achieve globbing is needed. It seems the preferred approach is use of an array. Since the globbing
will only expand to a single filename, the array can be referenced as before by the rest of the step, since it will
resolve to the first element in the array (equivalent to `$PACKAGE_FILENAME[0]`).
@per1234 per1234 added os: macos Specific to macOS operating system topic: infrastructure Related to project infrastructure type: imperfection Perceived defect in any part of project labels Jun 23, 2022
@per1234 per1234 requested a review from umbynos June 23, 2022 06:40
@per1234 per1234 self-assigned this Jun 23, 2022
@per1234 per1234 merged commit 4a4b784 into arduino:master Jun 23, 2022
@per1234 per1234 deleted the fix-nightly branch June 23, 2022 07:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
os: macos Specific to macOS operating system topic: infrastructure Related to project infrastructure type: imperfection Perceived defect in any part of project
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants