Refresh NOTICE and fail a stale one during review - #12
Merged
Conversation
The 0.1.1 server release stopped at its own gate: web/package-lock.json had moved nanoid to 3.3.18 and postcss to 8.5.23, while the committed NOTICE still named 3.3.16 and 8.5.22. The generated file is regenerated here from the lockfile that is actually committed. The drift reached main because npm-licenses regenerated NOTICE over the top of the committed one and only inspected the result, so a pull request that moved a dependency looked clean while the release workflows, which compare the two, would refuse to publish. The job now runs the same comparison the release does and fails when they disagree, which moves the failure to the pull request that causes it. The generated file is written to a temporary path so the committed one is still what gets inspected and uploaded.
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 0.1.1 server and client releases both stopped at the same gate:
web/package-lock.jsonhad movednanoidto 3.3.18 andpostcssto 8.5.23, while the committedNOTICEstill named 3.3.16 and 8.5.22. Both release workflows refuse to publish a stale file, so neither could get past it.NOTICEis regenerated here from the lockfile that is actually committed. The only content change is those two version numbers.Why it reached main
npm-licensesregeneratedNOTICEover the top of the committed one and then only inspected the result, so a pull request that moved a dependency always looked clean while the release workflows, which compare the two, would refuse to publish. Staleness was invisible until release.That job now runs the same comparison the release does and fails when they disagree, writing the generated file to a temporary path so the committed one is still what gets inspected and uploaded. A dependency bump now fails on the pull request that causes it. This matters for the dependabot pull requests currently open, several of which touch the lockfile.
Release state
Both failed runs stopped before publishing anything: no
server-v0.1.1orclient-v0.1.1tag, no release, no draft. All four client build legs passed, including both macOS targets and the native-keyring gate. Re-running after this merges is safe.