staging releases should actually make a github release somewhere
Categories
(Taskcluster :: Services, enhancement)
Tracking
(Not tracked)
People
(Reporter: dustin, Assigned: dustin)
Details
(somewhere on a test repo!) This will probably also entail deleting the 99.9.9 release at the start.
This will allow us to test the release process including uploading artifacts, which has been somewhat problematic in the past.
Assignee | ||
Comment 1•4 years ago
|
||
I've created https://github.com/taskcluster/staging-releases and will set things up to do staging pushes there, instead of to branches on the main repo.
Assignee | ||
Comment 2•4 years ago
|
||
https://github.com/mozilla/community-tc-config/pull/291
woo :)
Next up:
- supply it with GitHub credentials that can only access this new repo
- create the release even for staging releases (but still
--no-push
, so no packages or docker images are pushed) - write a
yarn staging-release
that will push a staging release to the new repo, perhaps searching for a release version that doesn't already exist, or just inventing one from the current timestamp.
With this, the only things special-cased for staging releases are the version determination and getting the changelog text.
Comment 3•4 years ago
|
||
Worth doing a nightly staging release off the tip of master to catch when we break things?
Assignee | ||
Comment 4•4 years ago
|
||
Nightly seems like a lot. Let's do it on-demand, like when we're thinking "let's do a release this afternoon" we can do a staging release in the morning :)
Assignee | ||
Comment 5•4 years ago
|
||
I created a new taskcluster-staging-bot github account, created a PAT, and put it in passwordstore. Next step would be to add it as a collaborator (or whatever) on the staging-releases repo, but it's been flagged by GitHub so I can't do that just yet. I sent a support request.
Assignee | ||
Comment 6•4 years ago
|
||
Flagging is cleared, and I added a secret containing the PAT.
Assignee | ||
Comment 7•4 years ago
|
||
I started to modify this so that it would use tags on the staging-releases repo instead of branches, but then remembered: tags tend to get pushed everywhere. So if I made a 99.8.7 tag to test a staging release, it'd be easy to accidentally push that tag to the real repo. Just noting that here in case I get confused again :)
Assignee | ||
Comment 8•4 years ago
|
||
Assignee | ||
Comment 9•4 years ago
|
||
Woah -- https://github.com/taskcluster/staging-releases/releases/tag/untagged-343e2e4008313d9b0697
It's a draft release, hence the weird name. But as a bonus, draft releases can have the same number, so it doesn't really matter what version number we pick.
Assignee | ||
Comment 10•4 years ago
|
||
Assignee | ||
Updated•4 years ago
|
Description
•