Skip to content

Refactor variables in release workflows #766

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 3 commits into from
Oct 14, 2024

Conversation

per1234
Copy link
Contributor

@per1234 per1234 commented Oct 14, 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.

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.
…lows

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 per1234 added type: enhancement Proposed improvement topic: infrastructure Related to project infrastructure labels Oct 14, 2024
@per1234 per1234 self-assigned this Oct 14, 2024
@per1234 per1234 merged commit c79c71c into arduino:main Oct 14, 2024
17 checks passed
@per1234 per1234 deleted the update-release-workflows branch October 14, 2024 14:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: infrastructure Related to project infrastructure type: enhancement Proposed improvement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant