Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improvements to the release process/CI #15

Closed
5 of 7 tasks
denschub opened this issue Sep 12, 2022 · 2 comments
Closed
5 of 7 tasks

Improvements to the release process/CI #15

denschub opened this issue Sep 12, 2022 · 2 comments
Labels
✨ enhancement New feature or request

Comments

@denschub
Copy link
Owner

denschub commented Sep 12, 2022

There are a couple of things I could improve.

  • The binary inside the archive doesn't have the executable flag set. This is due to an issue in the upload-artifact action, but this can be worked around by building a tar/zip manually and uploading that.
  • Instead of camo-linux-amd64.zip, it probably makes sense to add the version number to the archive, something like camo-v0.3.0-linux-amd64.zip so it's clear when linking to it.
  • For releasing, I currently have to wait until the build job for the release branch is done, then downloading the artifacts, drafting a release, and attaching the artifacts there. In theory, I could run GHA when a new tag is created, build release artifacts, and automatically create a new draft release with the artifacts attached. The matrix-org/synapse repo has something close to that where I could probably take inspiration from.
  • My current version number hacks based on ::set-output are deprecated, and there is a much nicer way available.
  • action-rs seems unmaintained. This will become an issue soon since GitHub Actions will deprecate NodeJS 12. I can probably just manually use rustup and call cargo...

Optionally, some other things:

  • The docker-release workflow currently doesn't care about the "pre-release" checkbox in a release, and would tag even pre-releases to latest. This probably isn't a big deal since I don't plan on releasing pre-releases, but it might be worth adjusting that, and only push a tag 1.0.0-dev, instead of pushing it to 1, 1.0, 1.0.0-dev, and latest.
  • I currently push container images to Docker Hub, but there's no reason not to push it towards the GitHub Container Registry as well.
@denschub denschub added this to the 1.0.0 milestone Sep 12, 2022
@denschub denschub added the ✨ enhancement New feature or request label Sep 12, 2022
denschub added a commit that referenced this issue Dec 8, 2022
This makes sure that executable flags are preserved, but it also makes
sure the version number is in the filename.
denschub added a commit that referenced this issue Dec 8, 2022
@denschub denschub changed the title Improvements to the release process for v1.0.0 Improvements to the release process/CI Dec 8, 2022
@denschub
Copy link
Owner Author

denschub commented Dec 8, 2022

I've made some of the required changes (see the checklist in the initial issue), but I'll postpone some others, mainly the "maintainer comfort" things. GitHub Actions isn't my favorite CI, and I feel like to comfortably do this without too many hacks, I'd need to invent my own action(s). This isn't needed for a 1.0.0 release, so I'll unblock the release.

@denschub denschub removed this from the 1.0.0 milestone Dec 8, 2022
denschub added a commit that referenced this issue Dec 8, 2022
Clearly, the world isn't ready for libraries that new yet.
@denschub
Copy link
Owner Author

I'm currently too lazy to address any of the remaining issues, mainly because I don't have a need for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
✨ enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant