Repository navigation
chore: bump actions/upload-artifact from 4 to 7 - #42
Merged
skyoo2003 merged 1 commit intoApr 27, 2026
Merged
Conversation
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 4 to 7. - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](actions/upload-artifact@v4...v7) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
github-actions
Bot
added
ci
skyoo2003
deleted the
dependabot/github_actions/actions/upload-artifact-7
branch
April 27, 2026 22:52
skyoo2003
added a commit
that referenced
this pull request
Aug 9, 2026
The hand-edit check enumerated bullet markers — '^[-+] ' — and its comment claimed it rejected "any other bullet form". It rejected two of them. An ordered item, an indented item and a pasted paragraph all passed, and the entry check that follows only inspects '* ' lines, so those lines shipped into a GitHub release with nothing about them verified: * Real entry ([#42](.../issues/42)) 1. Hand-written item with no issue link <- old check: pass Inverted it. A batched file holds only what .changie.yaml renders: the version heading, one kind heading per section, and one '* ...' entry per fragment. Allowing those three shapes and rejecting the rest covers every form a human might reach for, including the ones nobody thought to list. Verified against authentic output — `changie batch` (v1.25.0, current config, all 27 unreleased fragments) and changes/v0.2.0.md both pass; '1. text', ' - text', '- text' and a bare paragraph each fail with the offending line numbered. The empty-notes and missing-file gates still fire on changes/v0.1.0.md and an absent path.
skyoo2003
added a commit
that referenced
this pull request
Aug 9, 2026
* ci: enforce the checks a v1.0 tag depends on The release procedure was documented end to end but unenforced, and four defects were live on main. The fidelity manifest could drift silently. internal/generated is committed but derived, and nothing verified the committed output still matched its sources. The Go tests guard the manifest's shape — floors, registered services, the CRUD registry — but none of them notice an operation a provider gained and the manifest never did; absence from a 7,475-entry map is invisible. A codegen-drift job now regenerates and diffs. Its first catch was this repo: the manifest's own doc comment was a release behind its template. Eight changelog fragments carried an empty Issue field, which changie renders as ([#](https://github.com/skyoo2003/devcloud/issues/)) and batches without complaint. They would have shipped as dead links in the v1.0 release notes. The fragments are fixed and the release workflow now rejects a batched file containing one. One fragment sat in .changes/unreleased/ rather than changes/unreleased/, so it was excluded from every release since it was written. Moved; the batch goes from 25 entries to 26. A tag push published without waiting for tests. CI does trigger on tags, but the two workflows race, so a red commit could still ship binaries, container images and a Homebrew formula. The release job now needs a test job. Also ships the docs tree inside the release archive, so docs are versioned by tag: the docs/ beside a binary describe that binary. * docs(changelog): fragment for the release-hardening change * fix(ci): close the holes the release gate left open Six follow-ups from review, each verified against the tree. The drift check did not gate publishing. release.yml waited only on the Go tests, which are exactly the checks that cannot see a stale fidelity manifest — the reason the drift job exists. A tag could publish generated code that misstates what the release serves. The release job now needs a codegen-drift job of its own rather than trusting that CI won the race. The drift check missed untracked output. `git diff --exit-code` ignores a newly generated package, so adding a service model and forgetting to commit its generated directory passed. cmd/codegen/main.go:18-20 already documents this trap and smithy-sync.yml:44-46 already avoids it; both drift checks now use `git status --porcelain`, as that one does. codegen exited 0 after skipping a model. An unreadable or malformed model printed to stderr and continued, so generation could be incomplete while the drift check saw no changed files and called it clean. It now exits non-zero, and does so before writing the CRUD registry and fidelity manifest — those describe the whole fleet, and building them from a partial set would state in generated code that a service's operations do not exist. The issue-number guard only caught the empty case. `Issue: "abc"`, `"0"` and `"-1"` all render links that go nowhere and all batched cleanly. The check now requires every entry to end in a positive integer rather than enumerating the malformed spellings. Manual dispatch tested the wrong commit. actions/checkout defaults to the ref the run was launched from, not the tag input, so the gate vouched for a branch while GoReleaser was asked for a tag. Both jobs now check out the resolved tag. The gate ran on amd64 only while GoReleaser publishes arm64 artifacts. The test job now mirrors ci.yml's architecture matrix. * fix(ci): gate the release on the compatibility suite compat.yml triggers on branch pushes and pull requests only, so on a tag it does not race the release the way CI does — it never runs at all. The boto3 suite is the guardrail this project leans on hardest, and it had no bearing on what a tag published; docs/release.md listed it as a manual pre-flight step, which is the judgment call the release gate exists to remove. The pre-flight checklist now says which boxes the workflow re-runs and which only a human catches, and quotes the drift check the way CI actually runs it (git status --porcelain, not git diff --exit-code). * fix(ci): regenerate from a clean tree so retired outputs surface Regenerating in place only overwrites the filenames the generator still emits. internal/codegen/generator.go has no deletion path — no os.Remove, no RemoveAll — so an output it stops emitting stays on disk, tracked and unchanged, and `git status --porcelain` reports nothing. The drift check then passes on generated code that no longer matches its generator, which is the case the check exists to catch. The repo has hit this before: cmd/codegen/ main.go:16-22 exists because stubs deleted in #91 and #96 kept coming back. Both drift jobs now clear internal/generated before regenerating, so a retired or renamed output shows up as a deletion. Every tracked file under that tree carries a generated marker, so nothing hand-written is at risk, and scripts/generate-imports.sh writes to cmd/devcloud/imports.go, outside it. Verified by committing a file the generator does not emit: in-place regeneration left porcelain empty, clean-tree regeneration reported ` D internal/generated/zz_obsolete_gen.go`. A clean-tree run against the current tree reproduces it byte for byte, so the stricter check starts green. * fix(release): ship what the archived docs link to, and clear the tree locally Adding docs/ to the archive exposed how little of it resolved: measured against a real snapshot archive, README.md and the docs tree reach seven top-level files by relative path that were not shipped. Adding them takes the archive from 26 of 28 relative links broken — the state before docs/ was included at all — to 17 of 134, and every one of those points into source or CI config, which a binary archive has no business carrying. Verified by extracting dist/devcloud_..._linux_amd64.tar.gz and resolving each link against the extracted tree: 117 of 134 work. Archive size 3.2M. The pre-flight checklist also still told developers to regenerate in place, which is the exact check the previous commit taught CI not to trust. It now mirrors the clean-tree sequence. * fix(ci): fail release notes that contain no changie entries The issue-link check filtered the '* ' entries and complained about the ones that did not carry a valid link. With no '* ' entries at all the filter matched nothing, `|| true` turned the empty result into success, and the gate passed having checked nothing. changes/v0.1.0.md is exactly that shape — hand-written prose with 25 '- ' bullets and no issue links — so a manual dispatch for that tag would have replaced its release with notes this gate never inspected. Now a notes file must contain at least one changie entry, and any other bullet form is rejected outright: those are hand edits, which is what the link check cannot vouch for and what docs/release.md already forbids. Verified against the real files and synthetic cases: v0.1.0.md and a headers- only file now fail on "no changie entries", a file mixing a changie entry with a hand-written bullet fails on the bullet, a malformed issue link still fails, and v0.2.0.md plus the current unreleased batch still pass. * fix(ci): reject every line a release notes file did not get from changie The hand-edit check enumerated bullet markers — '^[-+] ' — and its comment claimed it rejected "any other bullet form". It rejected two of them. An ordered item, an indented item and a pasted paragraph all passed, and the entry check that follows only inspects '* ' lines, so those lines shipped into a GitHub release with nothing about them verified: * Real entry ([#42](.../issues/42)) 1. Hand-written item with no issue link <- old check: pass Inverted it. A batched file holds only what .changie.yaml renders: the version heading, one kind heading per section, and one '* ...' entry per fragment. Allowing those three shapes and rejecting the rest covers every form a human might reach for, including the ones nobody thought to list. Verified against authentic output — `changie batch` (v1.25.0, current config, all 27 unreleased fragments) and changes/v0.2.0.md both pass; '1. text', ' - text', '- text' and a bare paragraph each fail with the offending line numbered. The empty-notes and missing-file gates still fire on changes/v0.1.0.md and an absent path. * fix(ci): pin every release job to one commit, not to a mutable tag All four jobs resolved `github.event.inputs.tag || github.ref` on their own. A tag is a mutable pointer: force-update it, or delete and recreate it, while the run is in flight — which is what a maintainer does on spotting that the wrong commit got tagged — and the gates check out one commit while the release job checks out another. "The gates passed" then says nothing about the artefacts GoReleaser publishes. A new `resolve` job checks out the ref once, records `git rev-parse HEAD`, and every job downstream takes `ref: ${{ needs.resolve.outputs.sha }}`. It carries the tag name and the dry-run flag too, so the `resolve_tag` step inside `release` and the ref expression repeated four times both collapse into it. github.sha alone would not do: it is immutable, but on workflow_dispatch it is the branch the run was launched from, not the tag that was typed in. The release checkout also needs `fetch-tags: true`, and that is not redundant with `fetch-depth: 0`. actions/checkout always fetches with --no-tags and brings tags down only through an explicit refspec; for a SHA ref that refspec is the bare commit (ref-helper.ts getRefSpec, git-command-manager.ts fetch, at the pinned de0fac2). Pinning without it hands GoReleaser a repo with no tags and no way to name the version. With it, a tag that moved after `resolve` no longer points at HEAD, and `git describe --exact-match` inside GoReleaser's git pipe fails the run rather than mispublishing. Verified: the job graph parses, every `needs` resolves, all four downstream checkouts pin to needs.resolve.outputs.sha, and the three outputs read are the three declared. The resolve step emits tag+sha on a tag push and adds extra_flags=--snapshot only under dry_run. The notes gate still passes real `changie batch` output and still rejects every hand-edited fixture. * fix(ci): require the release notes heading to name the tag being released The allowlist matched '^## ' and '^### ' by prefix, so it accepted any version heading at all. Copy or rename an earlier release's notes file to changes/<new-tag>.md and every check passed: the entries carry valid issue links, nothing is hand-written, and GoReleaser hands the body through verbatim — so the v1.0.0 release opens with a heading linking to the v0.2.0 release, dated to it. The heading is now rebuilt from the tag and required exactly, exactly once. Dots in the tag are escaped, which is not cosmetic: without it the regex for v9.9.9 matches a heading reading v9x9x9. Kind headings are restricted to the labels in .changie.yaml, read out of the config rather than restated here so that adding a kind does not start failing releases. If that extraction ever stops matching it yields an empty set, which rejects every kind heading — the check fails loudly instead of silently checking nothing, the same failure mode the empty-entry gate above exists for. Verified against authentic `changie batch` output, 14 cases: correct tag passes; the same file under a different tag, a stale heading, two headings, no heading, '### Bugfixes', an ordered item, an indented item, a pasted paragraph, an entry without an issue link, changes/v0.1.0.md and an absent path all fail. changes/v0.2.0.md still passes under its own tag. Dot escaping confirmed by control: the unescaped variant passes the v9x9x9 heading.
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.
Bumps actions/upload-artifact from 4 to 7.
Release notes
Sourced from actions/upload-artifact's releases.
... (truncated)
Commits
043fb46Merge pull request #797 from actions/yacaovsnc/update-dependency634250cInclude changes in typespec/ts-http-runtime 0.3.5e454baaReadme: bump all the example versions to v7 (#796)74fad66Update the readme with direct upload details (#795)bbbca2dSupport direct file uploads (#764)589182cUpgrade the module to ESM and bump dependencies (#762)47309c9Merge pull request #754 from actions/Link-/add-proxy-integration-tests02a8460Add proxy integration testb7c566aMerge pull request #745 from actions/upload-artifact-v6-releasee516bc8docs: correct description of Node.js 24 support in READMEDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)