embeddedkafka / embedded-kafka

A library that provides an in-memory Kafka instance to run your tests against.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Release process?

guizmaii opened this issue · comments

@francescopellegrini What is the release process? How do you make a new release?

I tried to create a new GitHub Release (I removed it) to trigger the "release" CI job. It worked but it published the new version as a SNAPSHOT as you can see here: https://github.com/embeddedkafka/embedded-kafka/actions/runs/5631099858/job/15257731028#step:5:181

Hi @guizmaii , to publish a new non-snapshot release you've to run sbt release from your pc: it will automatically bump the version, run cross-Scala version tests, and push to the origin, triggering the appropriate GitHub Action.
Let me know if it works for you :)

@francescopellegrini What do you think about automating it in the CI each time we make a new GitHub release?

I've never considered that, tbh, because if you create a release from GH you need to choose a commit where the library version hasn't been updated yet and that would be confusing..

if you create a release from GH you need to choose a commit where the library version hasn't been updated yet and that would be confusing..

Not sure to understand, sorry. 🤔
You'd just create a new release on the main branch. Usually, you don't want to pick a specific commit.
Then the CI will publish the new release. It's how we do in zio-kafka for example

My bad, I got confused by the fact that currently the released version number is tracked in version.sbt which is updated when you run sbt release.

The GHA release pipeline actually cares only about tags, so we could get rid of version.sbt (and of the sbt-release plugin?) and simply push whatever tag we want directly to master.

Do you think this would simplify the process? I'm open to suggestions :)

Do you think this would simplify the process?

It does because you don't need to do anything on your machine. You just create a new release in Github and everything is done automatically by the CI

About the implementation, I'm doing this in all of my projects so I could copy what I'm doing there
zio-kafka implementation of this mechanism is complex because it depends on an sbt plugin made for zio projects, but for example, that's how I release https://github.com/guizmaii/sbt-datadog

It uses sbt-ci-release instead of sbt-release

The release process is in https://github.com/guizmaii/sbt-datadog/blob/main/.github/workflows/release.yml

We'd need to configure these four secrets in the GitHub project:

          PGP_PASSPHRASE: ${{ secrets.PGP_PASSPHRASE }}
          PGP_SECRET: ${{ secrets.PGP_SECRET }}
          SONATYPE_PASSWORD: ${{ secrets.SONATYPE_PASSWORD }}
          SONATYPE_USERNAME: ${{ secrets.SONATYPE_USERNAME }}

We already have the sbt-ci-release plugin configured along with all the required secrets on the release pipeline, so I guess it's just a matter of replacing the trigger..?

Hi again @guizmaii, I noticed your project has a versionScheme := Some("semver-spec") set in the build.sbt.
When you tried to release embedded-kafka v3.5.1 a warning about that was actually logged, so I believe we don't need to change the CI pipeline trigger, just remove the version.sbt file and add a versionScheme to the build.sbt.
Does it make sense to you?

The versionScheme := Some("semver-spec") is an optional but recommended sbt settings

Does it make sense to you?

Yup it does. Let's give it a try :)

In the build process for projects I am currently using we match the version from org.apache.kafka:kafka-clients to be the same for this project (io.github.embeddedkafka:embedded-kafka_2.13 in our case), which seems to be something you intend by design.

However, often for a couple of weeks this project falls behind in tagging / releasing the new version. This PR seems a step into improving that.

Is there anything I can do to better help automate this release process so non conflicting (minor or patch) versions more quickly match the kafka-clients version?

Hi @azthec,
I used to do the same on previous projects, but then I stopped doing so because there have been cases in which I needed to release fixes for the latest version of embedded-kafka; I recommend you do the same. ;)

We hope that the new release process will help speeding up the availability of the latest embedded-kafka version.