Sync "Check Go" CI workflow with template #65
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
This is the template workflow filename, which is intended to serve as a unique identifier within a collection that might include multiple related variants, and thus must be a bit more verbose.
GitHub has changed the URL of this documentation page. Even though the old one redirects to the new one, it's best not to rely on that. And anyway, the new URL is nicer.
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.
This is the naming convention established in the standardized template workflow. The tool name is "Task", with "taskfile" being its configuration file, so the previous step name was inaccurate.
The "templates" for testing, linting, and formatting Go code work from a list of packages of the Go module which is output from a `go list` command. Previously, it was only possible to get the packages of the module in the root of the repository. Projects may contain multiple Go modules in subfolders of the repository. In order to support checks on these modules, it's necessary to configure the commands to run from their path. This is passed to the task via the `GO_MODULE_PATH` environment variable. If this variable is not defined, the default root module path is used as default, preserving the previous task behavior. The workflows use a job matrix to allow easy configuration for any number of module paths and a dedicated parallel job for each module. Because it may not be desirable to combine the code coverage data for all modules, a Codecov flag value can be defined for each matrix job in the "Test Go" workflow. This workflow produces a two dimensional "operating system * module" job matrix, running the tests for each module using all operating systems. Even though this project has, and is likely to alway have, only the one module in the common location in the root of the repo, and so was perfectly well served by the previous infrastructure, these assets are intended to be applicable to any project, and so must be more extendable. The new approach works just as well as before for this project.
It can sometimes be easy to forget to run a `go mod tidy` to sync up the modules dependencies in the manifest and lock files. This often results in a confusing diff for the next contributor making a change that should not result in any change to those files. The better approach is to check the tidy state on every change to a relevant file so the module can be kept in a clean state.
This taskfile variable is used to inject data into the build process. It is not used in this project, but the "template" `go:build` task still uses this variable in its command. Even though it makes no functional difference, I think the workflow is less confusing with an empty definition of the variable to make it clear that this was intended, rather than being an accidentally lost declaration.
This will make it easier for the maintainers to sync fixes and improvements in either direction between the upstream "template" assets and their installation in this repository.
per1234
added
type: enhancement
Codecov Report
@@ Coverage Diff @@
## main #65 +/- ##
=======================================
Coverage ? 28.62%
=======================================
Files ? 1
Lines ? 269
Branches ? 0
=======================================
Hits ? 77
Misses ? 188
Partials ? 4
Flags with carried forward coverage won't be shown. Click here to find out more. Continue to review full report at Codecov.
|
umbynos
approved these changes
Aug 13, 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 GitHub Actions workflows:
https://github.com/arduino/tooling-project-assets
These workflows will be used in the repositories of all Arduino tooling projects.
Some improvements and standardizations have been made in the upstream "template" workflow, and those are introduced to this repository via this pull request.