Prepare for sbt-ci-release usage

[limansky]

Hi @lloydmeta ,

Finally, I've done some preparations for sbt-ci-release usage. I removed all version values, to make sbt-dynver work. This requires to set tag on the previous version properly.

Also it is needed to setup build variables, to make publish work. (see https://github.com/sbt/sbt-ci-release).

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 85.71%. Comparing base (c76f948) to head (c53c5da).

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #420   +/-   ##
=======================================
  Coverage   85.71%   85.71%           
=======================================
  Files          63       63           
  Lines         511      511           
  Branches       34       34           
=======================================
  Hits          438      438           
  Misses         73       73           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[limansky]

I suppose this is the contact email field.

[lloydmeta]

Thanks for doing this!

Overall I think it should be a nice change. I do have a few questions (very noob ones too, since I've not used this plugin or GH action!):

• Is there a way to preview whether this works or not and the artefacts it publishes ?
• Does this mean that we end up publishing 1 version for everything ? e.g. if there is a change to an integration lib, we end up publishing new versions of macros and core?

[lloydmeta]

Interesting.

This was added as part of adding support for Scala 3.

https://github.com/lloydmeta/enumeratum/blame/c76f9487bc86b5fc744427e5450699d7f4558944/build.sbt#L150-L167

Does testing macro changes still work without this?

[limansky]

All tests are passed both locally and on CI. Is there any preconditions to verify this?

[lloydmeta]

I think it was used to test changes and fixes to macros during development. My suspicion is it may not be needed anymore and I'm happy to remove it and add it back in if we find otherwise later on.

[limansky]

I've just removed the rest of configureWithLocal and it looks like everything is works fine (I ran +clean, +test).

[limansky]

To be honest, I haven't used sbt-ci-release myself too, but as I see it's a kind of meta-plugin for several things like sbt-sonatype, sbt-dynver, and sbt-gpg. I'm using sbt-sonatype and sbt-gpg in https://github.com/limansky/beanpuree, and some other projects.

1. As I see +publishLocal is still working, so you can use it to test without publishing to sonatype. (I've found what enumeratum-play/update task is broken when it called without cross-compile, but works fine as +enumeratum-play/update, I'm going to investigate it).
2. Yes, all the libraries will have the same version. So, once you set a tag for a new version CI task "publish" calls sbt task "ci-release" which internally calls a sequence of other tasks like +publishSigned and sonatypeBundleRelease.

[limansky]

I think you can also use show task to verify the sbt settings (show version, show publishTo, etc).

[lloydmeta]

LGTM. Going to hold off on merging until I get a chance to re-read https://github.com/sbt/sbt-ci-release?tab=readme-ov-file#how-do-i-publish-cross-built-projects and set it up. Thanks !