-
-
Notifications
You must be signed in to change notification settings - Fork 12
Sync Prettier formatting check CI workflow with template #218
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
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
Codecov Report
@@ Coverage Diff @@
## main #218 +/- ##
=======================================
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 `config:check-formatting` and `docs:check-formatting` tasks have no value to the developer, since they will be better off to just run the formatting task. This means that the only use for this task is the CI. I think this can be better achieved by configuring the CI to format the code and then check for a diff. This ensures that there is no possibility for a mismatch between the formatting check and the formatting task.
The Prettier formatting tool supports a long list of languages. Previously, it was being arbitrarily limited to JSON, YAML, and Markdown files. It will be more useful to allow it to format files of any language it supports.
…filter The workflow should run whenever this file is modified.
…w recursive `.prettierrc` is the Prettier formatting tool's configuration file. Prettier uses the configuration file closes to the file being formatted, meaning a project can have multiple configuration files. The workflow should run whenever any configuration file is edited.
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.
These are the naming conventions established in the standardized template workflow.
… trigger event reference The workings of the `workflow_dispatch` and `repository_dispatch` events is not obvious from the name. For this reason, a comment was added to explain their working. But this information is explained well enough in GitHub's documentation, so the workflow will be less cluttered by simply providing a reference link interested parties can easily follow to get all the information on the events used by the workflow.
…her YAML 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 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.
Prettier formatting is now being applied to all supported files rather than only Markdown and YAML files as previously. Some files were not compliant.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
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 to the "template" workflow, and these are introduced via this pull request.