Sync project assets with "templates" #77
Merged
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
Since this project does not use the trunk-based development strategy at the moment, this change does not provide any benefit outside of facilitating syncs with the upstream "template" project assets. It will not have any significant effect, since it only results in the additional full workflow run being triggered on the creation of a branch with the release style of name format. Explanation of the reason for the change as it applies to these files being intended to be generally applicable to any project: The trunk-based development strategy is used by some tooling projects (e.g., Arduino CLI). Their release branches may contain a subset of the history of the default branch. The status of the GitHub Actions workflows should be evaluated before making a release. However, this is not so simple as checking the status of the commit at the tip of the release branch. The reason is that, for the sake of efficiency, the workflows are configured to run only when the processes are relevant to the trigger event (e.g., no need to run unit tests for a change to the readme). In the case of the default branch, you can simply set the workflow runs filter to that branch and then check the result of the latest run of each workflow of interest. However, that was not possible to do with the release branch since it might be that the workflow was never run in that branch. The status of the latest run of the workflow in the default branch might not match the status for the release branch if the release branch does not contain the full history. For this reason, it will be helpful to trigger all relevant workflows on the creation of a release branch. This will ensure that each of those workflows will always have at least one run in the release branch. Subsequent commits pushed to the branch can run based on their usual trigger filters and the status of the latest run of each workflow in the branch will provide an accurate indication of the state of that branch. Branches are created for purposes other than releases, most notably feature branches to stage work for a pull request. Because the collection of workflows in a Tooling project are often very comprehensive, it would not be convenient or efficient to run them on the creation of every feature branch. Unfortunately, GitHub Actions does not support filters on the `create` event of branch creation like it does for the `push` and `pull_request` events. There is support for a `branches` filter of the `push` event, but that filter is an AND to the `paths` filter and this application requires an OR. For this reason, the workflows must be triggered by the creation of any branch. The unwanted job runs are prevented by adding a `run-determination` job with the branch filter handled by Bash commands. The other jobs of the workflow use this `run-determination` job as a dependency, only running when it indicates they should via a job output. Because this minimal `run-determination` job runs very quickly, it is roughly equivalent to the workflow having been skipped entirely for non-release branch creations. This approach has been in use for some time already in the versioned "Deploy Website" workflows.
There are two file extensions in common use for YAML files: `.yaml` and `.yml`. Although this project uses `.yml` exclusively for YAML files, this is a standardized workflow which might be applied to projects that have established the use of the other extension. It will be most flexible if it supports both.
The `ignore-words-list` and `skip` settings of the codespell configuration file may required project-specific adjustments to fix false positives or avoid positives from externally maintained files. The other settings are universal. It will be convenient to have the settings the user might need to adjust at the place of highest visibility in the configuration file.
Even though the project does not have any such flags at the moment, this is the established format of the "template" project assets, so adding it will facilitate syncs with the upstream assets.
Since this is a tool created for use in a single installation, which uses Linux, it is not necessary to run the tests on the runners for each operating system as is the case with a tool intended for general use. Howevever, this workflow is a standardized project asset used by all projects. Aligning with the standardized form facilitates syncs of fixes and improvements to and from the upstream asset.
This will improve the readability of a long and complex command without having any effect on its function.
This will record the project's test coverage data on Codecov. A readme badge will display the % coverage and link to the project's data.
No functional change, and neither is necessarily superior, but this is how it is in the "template", and so it must be here as well.
This procedure was not directly related to the test running procedure, so there was no good reason for it to be located in the "Test Go" CI workflow.
The semver tool is used to identify pre-release tag versions and configure the GitHub release accordingly. Previously, the download, installation and use of the tool was all done in a single workflow step. Splitting these processes into three steps makes the identification of the cause of an error easier and also the related logs to facilitate the investigation.
This will make it easier for the maintainers to sync fixes and improvements in either direction between the upstream "template" workflow and its installation in this repository.
No functional change, and neither is necessarily superior, but this is how it is in the "template", and so it must be here as well. `tests` seems to be slightly more common, but there are prominent Python projects using either.
This avoids the use of Windows "short paths" (e.g., C:\\Users\\RUNNER~1\\AppData\\Local) which may cause spurious test results.
No functional change, and neither is necessarily superior, but this is how it is in the "template", and so it must be here as well.
per1234
added
type: enhancement
Codecov Report
@@ Coverage Diff @@
## main #77 +/- ##
=======================================
Coverage ? 40.79%
=======================================
Files ? 26
Lines ? 1478
Branches ? 0
=======================================
Hits ? 603
Misses ? 818
Partials ? 57
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report at Codecov.
|
silvanocerza
approved these changes
Aug 27, 2021
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.
We have assembled a collection of reusable project assets:
https://github.com/arduino/tooling-project-assets
These will be used in the repositories of all Arduino tooling projects.
Some minor improvements and standardizations have been made in the upstream "template" assets. This is the last of a series of pull requests that bring this repository into full sync with the state of the art from the standardized assets: