Move non-build tasks to dedicated GitHub Actions workflows #2569
Conversation
This file contains hidden or 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
…ript code The "build" workflow builds the application for all supported targets, generates workflow artifacts from which the builds can be downloaded by users and beta testers, and publishes nightly and production releases. As if that wasn't enough, the workflow was also configured to perform the unrelated operation of linting the project's TypeScript and JavaScript code. This monolithic approach is harmful for multiple reasons: * Makes it difficult to interpret a failed workflow run * Unnecessarily adds a significant amount of extra content to the already extensive logs produced by the build process * Makes the build workflow more difficult to maintain * Increases the length of a build workflow run * Increases the impact of a spurious failure * Increases the turnaround time for contributors and maintainers to get feedback from the CI system The linting operation is hereby moved to a dedicated workflow, consistent with standard practices for Arduino Tooling projects.
…ript code The "build" workflow builds the application for all supported targets, generates workflow artifacts from which the builds can be downloaded by users and beta testers, and publishes nightly and production releases. As if that wasn't enough, the workflow was also configured to perform the unrelated operation of running the project's test suites. This monolithic approach is harmful for multiple reasons: * Makes it difficult to interpret a failed workflow run * Unnecessarily adds a significant amount of extra content to the already extensive logs produced by the build process * Makes the build workflow more difficult to maintain * Increases the length of a build workflow run * Increases the impact of a spurious failure * Increases the turnaround time for contributors and maintainers to get feedback from the CI system The test run operation is hereby moved to a dedicated workflow, consistent with standard practices for Arduino Tooling projects.
…guration The "build" workflow builds the application for all supported targets, generates workflow artifacts from which the builds can be downloaded by users and beta testers, and publishes nightly and production releases. As if that wasn't enough, the workflow was also configured to check the sync of the Yarn lockfile. This monolithic approach is harmful for multiple reasons: * Makes it difficult to interpret a failed workflow run * Makes the build workflow more difficult to maintain * Increases the turnaround time for contributors and maintainers to get feedback from the CI system The sync check operation is hereby moved to a dedicated workflow, consistent with standard practices for Arduino Tooling projects.
per1234
added
type: enhancement
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Motivation
The "build" workflow builds the application for all supported targets, generates workflow artifacts from which the builds can be downloaded by users and beta testers, and publishes nightly and production releases.
As if that wasn't enough, additional operations unrelated to building the application were jammed into the workflow:
This monolithic approach is harmful for multiple reasons:
Change description
Move the non-build operations to dedicated workflows. Aligning the project infrastructure more closely to standard practices for Arduino Tooling projects.
Reviewer checklist