Scenario for releasing a Tebako package together with Rubygems

[ronaldtse]

As @bradgessler blogged at his excellent post:

Since Terminalwire is a monorepo with multiple gems, it took me a while to figure out which directory I had to pass into tebako press to get a binary out the other side. My CI pipeline currently uses the “packaged gem” scenario, which means I need to cut releases of my gem to RubyGems before building a Tebako executable. This complicates my pre-release CI workflow since I have to release *.*.*.alpha* gems, but it does get a Tebako build out the door.

This is an interesting take especially since we do the same at Metanorma.

Our workflow is:

• Release all gems
• Then we build the corresponding Tebako packages and Docker containers

My question for @bradgessler is: what's the reason for not releasing gems first and then building the package? Thank you!

[bradgessler]

My question for @bradgessler is: what's the reason for not releasing gems first and then building the package? Thank you!

Yeah, I think it's dangerous to release untested assets to the world, even if its an rc or alpha gem; thus, in my CI workflow I'd like to build the Terminalwire gems into .gem files, then hand those off to tebako press for all platforms to build the Tebako binary, then package that up into the gzip files with all the other assets, and run some integration tests against that to verify the package. After all those steps run I'd release the gems and the binaries.

There's a speed and reliability advantage to doing that all locally too since the CI wouldn't have to release RC gems, wait for the dependency graph to update, then download those assets and package them up.

Finally, I do end up in cases where I'd like to create branches of Terminalwire builds and distribute those to customers on an individual basis to verify those work before merging into main. That approach to builds doesn't lend itself well to sequential versioning, which is almost a requirement to release assets on RubyGems.