chore: release v1.0.0 #102
Conversation
hacdias
force-pushed
the
release-1
branch
2 times, most recently
from
2af464d to
6818ad8
Compare
There was a problem hiding this comment.
@hacdias lgtm, when you start on Monday, feel free to merge #119 and then this PR to tag a stable v1.0.0 with what currently runs in our infra, before we merge and ship other things. This will give us stable image + confirm CI works.
I've created milestones for a few next minor versions:
https://github.com/ipfs/rainbow/milestones
feel free to adjust / merge them as needed.
The goal is to have milestones for next ~3 releases, and assign work according to priority, so it is clear what will ship in what order.
|
Suggested version: This is the first release of this module. Automatically created GitHub ReleaseA draft GitHub Release has been created. |
|
@lidel it seems that our release mechanism from the UCI is incompatible with our Docker workflow. Our releasing workflow creates the tag via the GitHub API and this does not trigger the In the meanwhile, I updated the Workflow to allow it to be manually triggered, but since it wasn't so in the release tag, I can't really trigger it in the past. So I just deleted the tag and pushed it manually. This successfully triggered the Docker workflow for the tag. We should see with @ipfs/ipdx if there's a better way of doing this. Maybe they already have some UCI for publishing Docker images. Or maybe there's a way to change the release workflow when it creates a tag to make it trigger |
|
@hacdias We can fix this! This happens because events created by the default GitHub Token do not trigger workflows. I do not like this design choice personally, but we can work around it. First, you can add the following trigger to the docker release workflow: It will trigger whenever there is a run of the Releaser workflow. Then, you can add the following job: The job checks details about the release, if it happened, what ref it used, etc. Remember to make the docker release job depend on the newly added one like so: Finally, use the retrieved ref in the checkout: |
|
@galargh thanks for the speedy answer. I will do this tomorrow and try it out when releasing v1.1.0 😄 If all goes smoothly, I will implement the same changes in |
@galargh are we able to avoid complexity here by using token from web3bot on the step that should trigger other workflows? See ipfs-shipyard/service-worker-gateway/.github/workflows/main.yml#L363-L376 where custom token allows us to create release on PR merge, which in turn correctly triggers ( |
|
Yes! Using a PAT to create releases would circumvent that issue. We can implement PAT support for the releaser workflow next month if you wanted us to. We definitely could create a fine-grained @web3-bot token which has write access to Interplanetary Shipyard repositories only, too. |
|
Yes, unfortunately, we have already reached the work quota this month and were asked not to go beyond. But we'll get to it first thing in May 💪 |
No description provided.