Repository navigation
ci: scan for advisories on a schedule, not only when somebody opens a pull request - #9
Merged
Merged
Conversation
… pull request `composer audit --locked` already ran on every pull request. What was missing is the schedule, and the difference is the whole of it: an advisory is published when it is published, not when somebody next happens to touch the repository. A library nobody has needed to change for a month was a month behind on knowing. Its own workflow rather than a `schedule:` on ci.yml, which would run the whole matrix weekly to answer a question needing none of it - and a red run would then mean any of several things. This one fails for exactly one reason. GitHub emails the repository owner when a scheduled workflow fails, so that is the alerting mechanism and nothing else needs configuring. workflow_dispatch is there so it can be run by hand while investigating. Actions are pinned to commits rather than tags. **`ci.yml` in this repository still uses moving tags (`actions/checkout@v4`, `shivammathur/setup-php@v2`) — worth correcting separately, and a new file should not add to it.** This package commits no composer.lock, being a library, so `composer install` resolves fresh and writes one for `--locked` to read. That is the right behaviour here: it checks the newest versions the constraints admit rather than a snapshot from whenever a file was last committed.
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
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.
composer audit --lockedalready ran on every pull request. The schedule was what was missing — an advisory is published when it is published, not when somebody next happens to touch the repository. A library nobody has needed to change for a month was a month behind on knowing.Its own workflow rather than a
schedule:onci.yml, which would run the whole matrix weekly to answer a question needing none of it — and a red weekly run would then mean any of several things. This one fails for exactly one reason.GitHub emails the repository owner when a scheduled workflow fails; that is the alerting mechanism and nothing else needs configuring.
workflow_dispatchis there so it can be run by hand while investigating rather than waiting for Monday.Actions are pinned to commits rather than tags.
ci.ymlin this repository still uses moving tags (actions/checkout@v4,shivammathur/setup-php@v2) — worth correcting separately, and a new file should not add to it.This package commits no
composer.lock— being a library, a consumer's lockfile decides. Socomposer installresolves fresh and writes one for--lockedto read, which is the right behaviour here: it checks the newest versions the constraints admit rather than a snapshot from whenever a file was last committed.One of four; the same file is going to the other three repositories.