The dependency watch lost the first drift it found - #161
Merged
Conversation
The weekly watch found its first real drift on 2026-08-31 and lost it. It creates its tracking issue with --label security, this repo has no such label, and gh refuses the whole creation rather than dropping the label. So the step that carries the finding is the step that died, and the run went red with nothing filed. Every earlier run was green because there was nothing to report, so the create path had never run. The watch also ignored SECURITY_ACCEPTED_CVES, which the build gate honours. It read the three moderate OpenSSL advisories already accepted there as new, which is what made it fire that week alongside the genuine baseline drift. Against the pinned 3.6.3 the checker exits 1 without the list and 0 with it. Creating the label from the workflow keeps it working if the label is removed again. Signed-off-by: Xavier Roche <xroche@gmail.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
The first version of this fix created the label from the workflow, one line above the filing. That runs under set -euo pipefail, so any failure of the label call still took the report down, which is the bug this branch exists to remove. A stubbed gh returning 502 on the label call reproduces it: the step exits 1 and files nothing. Labelling after the issue exists cannot lose it. The same stub, failing every label call, now files the report and exits 0. --label on gh issue create is what could not stay, because gh drops the whole creation when the label is missing rather than the label alone. The label itself is created once out of band. No other workflow here provisions repo configuration at runtime. Signed-off-by: Xavier Roche <xroche@gmail.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
Signed-off-by: Xavier Roche <xroche@gmail.com> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
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
1 participant
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.
The weekly watch found real drift on 2026-08-31 and lost it. It filed its tracking issue with
--label security, and this repo had nosecuritylabel.ghdrops the whole creation when a label is missing, not just the label. Earlier runs were green because there was nothing to report, so that path had never run.No label failure can take the report down now. A stubbed
ghthat fails every label call files the report and exits 0, where the old shape exits 1 with nothing filed. Thesecuritylabel now exists, created by hand because no workflow here provisions it.The watch also ignored
SECURITY_ACCEPTED_CVES, which the build gate honours, so it counted the three moderate OpenSSL advisories already accepted there. Against the pinned 3.6.3 the checker exits 1 without that list and 0 with it.The genuine finding in the lost report was the drift itself, OpenSSL 3.6.3 here against 3.6.4 upstream.
This workflow runs only on
scheduleandworkflow_dispatch, so the PR build never exercises it. A dispatch would file the drift issue for real, so I have not run one.