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

Auto-release new versions #39

Closed
alexevanczuk opened this issue Oct 5, 2022 · 3 comments
Closed

Auto-release new versions #39

alexevanczuk opened this issue Oct 5, 2022 · 3 comments

Comments

@alexevanczuk
Copy link
Contributor

alexevanczuk commented Oct 5, 2022

Steps to publish currently are:

- /~https://github.com/rubyatscale/stimpack/releases
- “Draft a new release” button
- Release title => stimpack M.m.p
- “Choose a tag => vM.m.p => create new tag on publish with target main (other dropdown)
- “Generate release notes”
- Click big green publish release
- A github action should automatically be kicked off

This is a bit toilsome. Instead, it would be great to do all of this automatically each time a new (green) commit lands on main that changes the version. With a lot of gems, this would make it simpler to percolate changes throughout the ecosystem.

This applies to all gems in the rubyatscale org.

/~https://github.com/duderman/gh-gem-tag-action
This GitHub action automatically tags commits based on the gem spec. We'd likely want to fork this since this appears to be largely unmaintained. It also appears to not exit gracefully if a tag already exists, which we would want to add.

With this, we could simply bump the version and merge and viola, we would tag the commit, the release notes should be automatically generated, and we should run the publish job (I hope).

@alexevanczuk
Copy link
Contributor Author

I just found out that you can publish from the command line with gh release create from a gem repo, which makes this a bit less important for me but could still be really neat in the long-run.

@alexevanczuk
Copy link
Contributor Author

I experimented with this in /~https://github.com/rubyatscale/use_packwerk but have found that some of the existing solutions are incomplete and don't play super nice together. One idea I had here was it would be interesting to look at the GitHub actions I used in use_packwerk as inspiration to come up with two GitHub actions: continuous integration for open-source gems and continuous deployment for open source gems. That way each of the projects can just use two actions and get a consistent build, test, and deploy with less boiler plate.

CI would include build, lint, type check and CD would include build, tag, release, and deploy.

@alexevanczuk
Copy link
Contributor Author

This is finished, see #41

Note there are a couple of things that I think might be nice to have:

  • discourse/publish-rubygems-action uses a Dockerfile to run a bash script. I think this is overkill and we could probably just inline that bash script into a simpler GitHub action, which should make it a lot faster with less unnecessary output. This isn't super important since this only happens on main and is less of a blocker than CI.
  • Several of the GitHub actions use deprecated Github APIs (namely: set-output). You can see this in the CI and CD log for the actions. I've submitted PRs to update these and it would be nice to update to the latest commit once/if these get merged.
  • Lastly, I wondered if it would be worth it to bundle up these actions in a new "orchestration" GitHub action. That way there would be a lot less boiler plate and everything is maintained in that one action that others could use too. I feel like this is less important since most of the work is already being done in other actions.

Going to close this for now.

Repository owner moved this from 📋 Backlog to ✅ Done in RubyAtScale Public Backlog Oct 15, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Done
Development

No branches or pull requests

1 participant