petethepig
commented
2 years ago @eh-am reported there's still some rough edges with release-please:
- for release-please to work correctly, it requires commits to use either feat/fix. so if you are just updating the build for example, but you still want to release that code, it requires using feat/fix
- speaking of commits, since we squash commits, the only commit message we care about is the merge one, which by the time it's merged it's already too late
- release-please creates the release, then we run an action (publishing lambdas) and THEN we update the release inplace, which is not idempotent
- also manual flow is confusing, there's multiple places things can fail and it's not easy to retry ONLY that part
I figured in this repo we might also have issues with 2 separate packages.
I'd say let's start with release part which would build artifacts and publish them for each tag that matches something like ruby-v* and python-v*. We could use this Running your workflow only when a push of specific tags occurs functionality.
And then later in the future we can integrate it with release-please or something else like that for automated tagging + updates in version.rb and setup.py.
We need to make it so that a new release for ruby or python can be created, built and published via Github Actions in 1 step.
We do a similar thing here in pyroscope-lambda-extension repo, we can use it for inspiration.
My understanding is that there are 2 workflows:
release-please— this one creates a "release PR" based on conventional commits in the main repo. They have support for ruby and python packages which is nice.release— this one runs on each release tag — it builds artifacts, publishes the results and updates github release.I figured we can have the same thing here. We already have the building phases implemented for both ruby and python. ~
release-pleasecan help us automate the tagging phase, and publishing we'll have to implement ourselves I suppose.~ see my comment below about the proposed order for this.