fix(ci): make a pushed tag actually release again - #21
Merged
Conversation
Two things stood between a tag and a release, and both had to be worked around by hand every time. Checkout failed before any job did real work. This workflow is triggered *by* the tag, so the tag is the ref being checked out and is already present — asking for `fetch-tags` on top makes checkout fetch the commit and the tag into the same `refs/tags/*`, which git refuses. That took down every tag-triggered release from v0.0.5 onward; v0.0.5, v0.0.6 and v0.0.7 all went out through the manual workflow instead. `deploy-manual.yml` keeps the flag, and needs it: it runs from a branch, where the tag is not the ref. `yarn release` failed before that, on the machine running it. `lerna version` starts with `git remote update`, which fetches every remote and recurses into their submodules; branches on the upstream fork reference `rum-events-format` commits its own remote does not serve. Nothing in a release reads upstream, so it is now kept out of that update — from the release command itself, so it holds on any clone rather than on whichever machine happened to be configured.
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.
Releasing is supposed to be: push a tag,
deploy-auto.ymltakes it from there. That has not worked since v0.0.5 — v0.0.5, v0.0.6 and v0.0.7 all shipped through the manual workflow instead, andyarn releaseneeded a hand-applied git config before it would even get as far as tagging.1. Checkout could not check out the tag
The workflow is triggered by the tag, so the tag is the ref being checked out and is already there. Asking for
fetch-tagson top adds a second refspec pointing at the samerefs/tags/*, and git refuses. Removed from all five checkouts here.deploy-manual.ymlkeeps the flag, and needs it — it runs from a branch, where the tag is not the ref andcheck-release.jswould otherwise not find it. That asymmetry is now written down in the workflow rather than left to be rediscovered.Nothing else in this workflow needs tags:
check-release.jsresolvesv<version>, which is the checked-out ref.The failure was safe — it happened in checkout, so
deploy-prodandpublish-npmwere skipped and nothing was ever published by mistake. But it produced a failed run and anotify-failureon every release, and left the real path undiscoverable.2.
yarn releasedied before tagginglerna versionstarts withgit remote update, which fetches every remote and recurses into their submodules. Branches on the upstream fork referencerum-events-formatcommits that its own remote does not serve:Nothing in a release reads upstream, so
cmd_releasenow keeps it out of that update. Doing it there rather than in someone's.git/configmeans it holds on any clone — this was previously worked around by hand, on one machine.Guarded on the remote existing, and idempotent.
Verified
git remote updatefails, then passes once the guard has run — checked by clearing the config and re-running it.with:blocks left behind in the workflow.The checkout fix can only be proven by the next tag push, since that is the trigger. If it still fails, nothing publishes — the failure mode is unchanged and safe.