Add schedule triggers to workflows whenever possible #772
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 to facilitate the development and maintenance.
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
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.