Add publishAggregationToCentralSnapshots and publishFooPublicationToCentralSnapshots
#63
Conversation
| ./gradlew -p tests/jvm publishAggregationToCentralPortal | ||
| ./gradlew -p tests/jvm publishAggregationToCentralSnapshots |
There was a problem hiding this comment.
Should there be a single task that decides on snapshot/release depending on the project version?
E.g. if project.version.toString() ends with -SNAPSHOT, then it should publish to snaphots. Otherwise it should publish to releases.
WDYT?
There was a problem hiding this comment.
Yea maybe that'd be better.
But I also kind of like the separation of intents. Having separate task names and separate CI workflows makes for a clear separation. Plus historically those were 2 different task names so there is some brain muscle attached. Not saying we shouldn't change it of course but I'm not 100% convinced it would help yet. Did you have any specific use cases in mind?
There was a problem hiding this comment.
The reasoning I have in mind is that the action the same: "push publication to the repository".
I don't understand why should I push it differently depending on the project version.
It is pretty much like you don't have jar vs jarSnapshot depending on the project version. You always have a single jar task which builds the jar according to the current project version.
I'm fine if there are two independent technical task for the implementation details, however, in that case it would be nice to have an out of the box wrapper task which would depend on one of them as the project version requires.
Historically, I use "autosnapshot" project version: build script automatically adds -SNAPSHOT to the version unless there's -Prelease flag.
So it sounds reasonable to have ./gradlew publishAllPublicationsToCentralPortal and ./gradlew -Prelease publishAllPublicationsToCentralPortal. In other words: -Prelease selects the project version while the rest ("publish to central portal") being intact.
There was a problem hiding this comment.
It's not the same repository though. The url to consume and the immutability guarantees are not the same.
I get where you're coming from with the -Prelease flag, though. That's interesting and it's currently a pain in my workflows to make a commit specifically to drop the -SNAPSHOT... Having something like this would definitely make it easier.
Give me a few weeks so that I can try it out in a pet project and I'll report back? I'll open an issue so we keep track of this. (edit: here)
There was a problem hiding this comment.
@vlsi do you have a sample project using -Prelease I could take inspiration from?
There was a problem hiding this comment.
There was a problem hiding this comment.
@vlsi I ended up adopting the "autosnapshot" versioning in a couple of projects, it's nice! Thanks for pointing me to this 🙏
That being, said, I'm not 100% convinced that we need a wrapper task just yet. My snapshot and release workflows are usually different and having different task names doesn't hurt me too much. If anything, they act as an additional explicit check that I'm publishing in the correct location.
I might get there ultimately but since it's always easier to add than remove, I prefer keeping our options open there and not committing in that direction.
Closes #21