Skip to content

Sync "Check Certificates" CI workflow with template #212

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
merged 12 commits into from
Jul 27, 2021
Merged

Sync "Check Certificates" CI workflow with template #212

merged 12 commits into from
Jul 27, 2021

Conversation

per1234
Copy link
Contributor

@per1234 per1234 commented Jul 27, 2021

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.


This changes the name of the repository secret that contains the Slack webhook and I have already added the new secret.

per1234 added 12 commits July 26, 2021 21:45
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.
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 documetation, 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.
…w file itself

Because it is checking the contents of the repository secrets, the only push that can affect the outcome of the workflow
are those that change the wrokflow itself. For this reason, it is more efficient to add a path filter so the workflow
only runs on the relevant pushes.
It facilitates review to run a workflow when pull request is submitted proposing changes to it. Because this workflow
requires access to secrets which are not available when a pull request is submitted from a fork, the workflow was not
previously configured to support this. However, it is most likely that pull requests for changes to this particular
workflow will come from people who have write permissions in the repository, and who often submit PRs from branches in
the repository itself. In this case, the workflow does have access to the secrets.
This 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.
When no name is provided for a matrix job, the workflow job is named according to the contents of
`jobs[].<job_id>.strategy.matrix[]`. That can result in some fairly cryptic job names when the matrix contains a complex
data structure as is the case here. We already have a string to uniquely identify each certificate to humans, which is
exactly what the `jobs[].<job_id>.name` property does for jobs, so it will be an improvement to name the jobs according
to that identifier.
Although machines don't care which order the keys occur in, since the `jobs[].<job_id>.steps[].env` key declares the
environment variables used in the step, it is most intuitive for it to be placed before the `run` or `uses` key.
The "Check Certificates" workflow is configured to send a notification via Slack if a problem is found with a certificate.
TThis is currently posted to the `team_tooling` channel, but that is not necessarily always going to be the case, and for
every deployment of the workflow. So a less specific secret name is more universally applicable to serve all applications
of this "template" workflow.
It seems that the Prettier formatting style has become more strict regarding blank lines at some time since the release
of the outdated Prettier version currently used by Arduino Lint's `config:format` task. This brings it into compliance
with the current Prettier YAML style.
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.
@per1234 per1234 added type: enhancement Proposed improvement topic: infrastructure Related to project infrastructure labels Jul 27, 2021
@per1234 per1234 merged commit 06d44af into arduino:main Jul 27, 2021
@per1234 per1234 deleted the update-check-certificate branch July 27, 2021 08:45
@per1234 per1234 self-assigned this Nov 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic: infrastructure Related to project infrastructure type: enhancement Proposed improvement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants