Add schedule triggers to workflows whenever possible #220
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 repository contains several GitHub Actions workflows, both hosted in this repository as reusable assets for use in other projects, or to facilitate the development and maintenance of the `arduino/tooling-project-assets` repo itself. The workflows are typically configured to run whenever any relevant file in the repository is changed. However, the results of the workflow run are also dependent on the external environment it runs in, which include: - The software running on the GitHub hosted GitHub Actions runner machines - The GitHub Actions actions used by the workflow - The dependencies that are installed by the workflow directly or via the GitHub Actions actions it uses The workflows often do not fully pin to a specific version of given external tool. This was done in the interest on reducing the maintenance burden of keeping the systems up to date. However, it also means that a new release can cause the workflow runs to start failing (which might happen through an enhancement to that resource resolving a false negative, or a defect causing a false negative). When the repository file path trigger is used by itself, this sort of external breakage is only revealed when an unrelated change triggers the workflow. That can be distracting even to a dedicated member of the project development team, as well as confusing and discouraging to any contributor. This type of change can be caught by adding a `schedule` event trigger that causes the workflow to run periodically in addition to the other on-demand triggers. This allows the problem to be identified and resolved at the maintainer's convenience, separate from the unrelated development work.
per1234
added
type: enhancement
umbynos
approved these changes
Apr 20, 2022
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.
This repository contains several GitHub Actions workflows, both hosted in this repository as reusable assets for use in other projects, or to facilitate the development and maintenance of the
arduino/tooling-project-assetsrepo itself.The workflows are typically configured to run whenever any relevant file in the repository is changed. However, the results of the workflow run are also dependent on the external environment it runs in, which include:
The workflows often do not fully pin to a specific version of given external tool. This was done in the interest on reducing the maintenance burden of keeping the systems up to date. However, it also means that a new release can cause the workflow runs to start failing (which might happen through an enhancement to that resource resolving a false negative, or a defect causing a false negative).
When the repository file path trigger is used by itself, this sort of external breakage is only revealed when an unrelated change triggers the workflow. That can be distracting even to a dedicated member of the project development team, as well as confusing and discouraging to any contributor.
This type of change can be caught by adding a
scheduleevent trigger that causes the workflow to run periodically in addition to the other on-demand triggers. This allows the problem to be identified and resolved at the maintainer's convenience, separate from the unrelated development work.I have spread out the times of the newly added
scheduletriggers. The previous approach of copy/pasting the same optimal schedule configuration to all the workflows results in somewhat of an unintentional "DDoS" attempt by Arduino on the GitHub Actions infrastructure every Tuesday.