Sync GitHub Actions workflow validation CI workflow with template #219
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
Codecov Report
@@ Coverage Diff @@
## main #219 +/- ##
=======================================
Coverage 87.97% 87.97%
=======================================
Files 43 43
Lines 4176 4176
=======================================
Hits 3674 3674
Misses 391 391
Partials 111 111
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 2, 2021
The `WORKFLOW_SCHEMA_PATH` taskfile variable is only used in the `workflow:validate` task, and is certain to only ever be used there. Declaring it at the global scope only makes the workflow more difficult to understand and maintain.
This brings the task into compliance with the taskfile style guide: https://taskfile.dev/#/styleguide?id=dont-wrap-vars-in-spaces-when-templating
This facilitates the addition of a comment indicating the repository location of the schema file in case an error is discovered. As for the `WORKFLOWS_DATA_PATH` variable, I'm not sure why I did that (this is being imported from the template workflow which was developed as an independent project 6 months ago).
This will prevent breakage in the event the path contains spaces.
This makes it easier to understand the structure of long commands.
The output from the schema download process is not of interests and makes it more difficult to find the important schema validation output in the event of a failure.
Support for the JSON schema "format" keyword was moved to a separate package in ajv v7.0.0 (ajv-cli v4.0.0). If this package is not installed and specified as a module via the ajv-cli command, validation against any schema that uses "format" fails, even when the instance document is completely valid. Even though none of the JSON schemas currently in use by the templates and CI system have a "format" keyword, there's no reason one couldn't be added at any moment, so it's safest to just add support now. The change to ajv was done for security purposes when used with untrusted data, which is not a concern here.
The templates and the repository's CI system use the `ajv-cli` JSON schema validator to check the data format of various files. The default behavior of `ajv-cli` is to bail out on the first error. I think it is slightly more convenient to get all the errors at once to allow fixing all of them in one go rather than having to repeatedly run the validation before discovering all of them. This behavior is provided by adding the `--all-errors` flag to the `ajv-cli`' commands.
This is the name that was chosen for the standard template for GitHub Actions workflow validation, to be used on all Arduino tooling projects.
This will make it easier for the maintainers to sync fixes and improvements in either direction between the upstream "template" tasks and their installation in this repository.
By default, Task displays the commands it is running. With a simple task, this is reasonable for the sake of transparency of what is being done. However, with more complex tasks, it clutters up the output with information that is largely irrelevant to the task user. This is avoided by the addition of the `--silent` flag. Note that this does not suppress the output from the commands the task runs, but only the output from Task itself.
…ML file extension 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 conventions established in the standardized template workflow. Even though it was never realized, the original idea was for the scope of this workflow to be for linting of the repository's configuration file, paralleling the established "Check Config File Formatting" workflow. However, that approach leads to inefficient workflow trigger path filters. The better approach is to scope workflows to a file type. So it is more appropriate to scope the workflow to any checks specific to GitHub Actions workflows, and the workflow name should reflect that purpose.
At the time it was written, there was some lack of support for the use of day name abreviations in the crontab definition for the `schedule` trigger of GitHub Actions workflows (perhaps it was the JSON schema?). Since that time, the issue was resolved. The crontab is easier to understand with the day name in place of day number.
The `workflow_dispatch` event allows triggering the workflow via the GitHub web interface. This makes it easy to trigger an immediate workflow run after some relevant external change. The `repository_dispatch` event allows triggering workflows via the GitHub API. This might be useful for triggering an immediate check in multiple relevant repositories after an external change, or some automated process. Although we don't have any specific need for this event at the moment, the event has no impact on the workflow, so there is no reason against having it. It is the sort of thing that can end up being useful if it is already in consistently in place, but not worth setting up on demand, since the effort to set it up is greater than the effort to trigger all the workflows manually.
This is the template workflow filename, which is intended to serve as a unique identifier, and thus must be a bit more verbose.
The badges provide a prominent indication of the repository's CI status at a glance. This may help to bring potential issues to the attention of the maintainers.
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 minor improvements and standardizations have been made in the upstream "template" workflow, and those are introduced to this repository via this pull request.