Refactor variables in release workflows #251
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
per1234
added
type: enhancement
alessio-perugini
approved these changes
Oct 11, 2024
GitHub Actions workflows are used to automatically generate beta tester and production builds of the project. A separate build is generated for each of the target host types. This is done using a job matrix, which creates a parallel run of the workflow job for each target. The matrix defines variables that provide the data that is specific to each job. The variable names used previously did not clearly communicate their nature: - The variable for the task name was named "os" - The variables for the build filename components used the term "artifact", which is ambiguous in this context where the term is otherwise used to refer to the completely unrelated workflow artifacts These variable names made it very difficult for anyone not intimately familiar with the workings of the workflow to understand its code.
Multiple commands in the release workflow include the path of the folder that contains the build output. Previously, the complex folder name was specified redundantly in each instance. The readability and maintainability of the workflow is improved by using an environment variable to define the folder name in a single place, then referencing that environment variable in each of the individual commands that use the path.
…flow The package filename is referenced in multiple places in the release workflow. In order to avoid code duplication, it is defined once as an environment variable, then that variable referenced in each of the instances where the filename is needed. Previously, this was done by first defining and referencing a shell environment variable at the point of the first usage, then defining a workflow environment variable and referencing that in the second usage. The maintainability and readability of the workflow is improved by using a single workflow environment variable, defined in the step dedicated to defining such variables, then referencing it consistently in all usages.
per1234
force-pushed
the
variable-names
branch
from
f3501ee
to
ee03454
Compare
|
The failure of the Prettier formatting check is unrelated to the changes made here. It was fixed separately by #255. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
GitHub Actions workflows are used to automatically generate beta tester and production builds of the project.
While starting the work to update the workflow code for compatibility with the breaking change introduced in the latest versions of the actions/upload-artifact action (#233), I found that it was quite difficult to follow the workflow code due to the way some variables were defined. The refactoring proposed here is intended to improve the maintainability and readability of the workflows:
Use more meaningful variable names
A separate build is generated for each of the target host types. This is done using a job matrix, which creates a parallel run of the workflow job for each target. The matrix defines variables that provide the data that is specific to each job.
The variable names used previously did not clearly communicate their nature:
These variable names made it very difficult for anyone not intimately familiar with the workings of the workflow to understand its code.
Use workflow environment variables to reduce code duplication
Multiple commands in the notarization step of the "Release" workflow include the path of the folder that contains the build output, and the filename of the package.
Previously, there was some code duplication and inconsistency in how these were referenced.
This is improved on through the consistent use of workflow environment variables.
Reviewer notes
In order to validate the changes proposed here, I made a dummy release in my fork using a certificate from my own personal Apple Developer Program account for the notarization:
https://github.com/per1234/arduino-fwuploader/actions/runs/11286313009
https://github.com/per1234/arduino-fwuploader/releases/tag/0.0.0-rc.10