Ready?

[kopax]

Is this module ready ?

Hi @KengoTODA and happy new year 🐷!

I am looking to use semantic-release with my gradle project, and I can't use tschulte/gradle-semantic-release-plugin because of gradle-semantic-release-plugin/issues/#6, an issue that happen with Gitlab-CI.

Is this plugin :

• ready for production use?
• can deal with release on detached state? (gradle-semantic-release-plugin/issues/#6)

Also, I have checked the source and there is no reference to -SNAPSHOT version. I'd like to build one from dev, it would be nice if this plugin could also optionally push the snapshot version on the development branch.

Testing

• Your Gradle project should manage its version by gradle.properties (not by build.gradle nor build.gradle.kts).
• Your Gradle project should have an executable Gradle wrapper script at the project root directory.
• Your CI environment should run on Linux environment that can run ./gradlew.
• Your Gradle project should use Maven Publish Plugin or Legacy publishing to publish artifact.

I have tested and:

[6:24:42 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The commit should not trigger a release
[6:24:42 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: fix(test): test semantic-release
[6:24:42 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is patch
[6:24:42 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: chore(Release): [skip ci] new version commit:  'api-1.0.17-SNAPSHOT'.
[6:24:42 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The commit should not trigger a release
[6:24:42 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: chore(Release): [skip ci] pre tag commit:  'api-1.0.16'.
[6:24:42 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  The commit should not trigger a release
[6:24:42 AM] [semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analysis of 4 commits complete: patch release
[6:24:42 AM] [semantic-release] › ✔  Completed step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[6:24:43 AM] [semantic-release] › ℹ  The next release version is 1.0.17
[6:24:43 AM] [semantic-release] › ℹ  Start step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[6:24:43 AM] [semantic-release] › ✔  Completed step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[6:24:43 AM] [semantic-release] › ℹ  Start step "prepare" of plugin "gradle-semantic-release-plugin"
[6:24:46 AM] [semantic-release] › ✔  Completed step "prepare" of plugin "gradle-semantic-release-plugin"
[6:24:46 AM] [semantic-release] › ℹ  Start step "prepare" of plugin "@semantic-release/changelog"
[6:24:46 AM] [semantic-release] [@semantic-release/changelog] › ℹ  Update /mnt/mesos/sandbox/builds/kopaxgroup/api/CHANGELOG.md
[6:24:46 AM] [semantic-release] › ✔  Completed step "prepare" of plugin "@semantic-release/changelog"
[6:24:46 AM] [semantic-release] › ℹ  Start step "prepare" of plugin "@semantic-release/git"
[6:24:46 AM] [semantic-release] [@semantic-release/git] › ℹ  Found 1 file(s) to commit
[6:24:49 AM] [semantic-release] [@semantic-release/git] › ℹ  Prepared Git release: v1.0.17
[6:24:49 AM] [semantic-release] › ✔  Completed step "prepare" of plugin "@semantic-release/git"
[6:24:49 AM] [semantic-release] › ℹ  Start step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[6:24:49 AM] [semantic-release] › ✔  Completed step "generateNotes" of plugin "@semantic-release/release-notes-generator"
[6:24:50 AM] [semantic-release] › ✔  Created tag v1.0.17
[6:24:50 AM] [semantic-release] › ℹ  Start step "publish" of plugin "gradle-semantic-release-plugin"
[6:24:54 AM] [semantic-release] › ✔  Completed step "publish" of plugin "gradle-semantic-release-plugin"
[6:24:54 AM] [semantic-release] › ℹ  Start step "publish" of plugin "@semantic-release/gitlab"
[6:24:55 AM] [semantic-release] [@semantic-release/gitlab] › ℹ  Published GitLab release: v1.0.17
[6:24:55 AM] [semantic-release] › ✔  Completed step "publish" of plugin "@semantic-release/gitlab"
[6:24:55 AM] [semantic-release] › ✔  Published release 1.0.17

After looking at the commited+push change within the prepare step, there is just the CHANGELOG.md was updated.

Thanks a lot for sharing this oss.

[KengoTODA]

I'm sure it's production ready. Consider to share mcve that reproduces your problem.

This plugin doesn't handle Git and others pointed by you. So it should work even with detached state. If you met problem around Git, it should come from other semantic-release plugin like @semantic-release/git and @semantic-release/commit-analyzer.

About SNAPSHOT qualifier, I don't think it works with semantic-release because their purpose has conflict. See FAQ at semantic-release.gitbook.io.

[KengoTODA]

Here is the point:

[2:03:40 PM] [semantic-release] › ⚠  This run was not triggered in a known CI environment, running in dry-run mode.
[2:03:40 PM] [semantic-release] › ⚠  Run automated release from branch dev in dry-run mode

You're now running semantic-release in dry-run mode. This lets gradle-semantic-release-plugin to skip everything:

[2:04:15 PM] [semantic-release] › ⚠  Skip step "prepare" of plugin "gradle-semantic-release-plugin" in dry-run mode
[2:04:15 PM] [semantic-release] › ⚠  Skip v1.0.14 tag creation in dry-run mode
[2:04:15 PM] [semantic-release] › ⚠  Skip step "publish" of plugin "gradle-semantic-release-plugin" in dry-run mode

About SNAPSHOT qualifier, I don't think that your consideration is reasonable. In npm's culture they release packages even for test. So I recommend to avoid using semantic-release, and follow other direct solution for Java community like this (this is my personal opinion, of course). It is also valuable to consider to have multiple repos to publish (one for test, other for publish).

[kopax]

v1.0.2 is broken.
I've test the master build and it worked directly.

I distributed it under @gradle/[email protected] and now can use your plugin.

I've also tried to downgrade to v1.0.2 and it failed again.

Regading -SNAPSHOT, I have tested my idea and you were right, it was horrible.

[grv87]

@KengoTODA, I think that your reasoning on SNAPSHOT qualifier is not correct.

Please, correct me where I'm wrong:
semantic-release releases from master (or other specific release) branch and from clean repo only.
That's why it doesn't need SNAPSHOT.
All other branches are not released.

If this is correct, then this is a big surprise for Java developers and their CI/CDs.

In Java we build each commit, from each branch, maybe even from dirty repo from local machine. We could call these builds releases or couldn't. But they produce artifacts that are always versioned and published to some repos.
We just mark all these versions with SNAPSHOT and put them in separate Maven repository.
If we don't have CI then we at least use local Maven repo.
This way we develop and test other projects depending on these not-yet-released artifacts. Before making an actual release.

This is the real key difference with tschulte's work.

[KengoTODA]

All other branches are not released.

No. You can release to distribution channel. I hope official guideline helps you to grasp how it works.

[KengoTODA]

From my personal experience, SNAPSHOT doesn't work if project is big and it has dependency tree. Because the version identifier (x.x.x-SNAPSHOT) doesn't identify one package. It means version A but it will be version B suddenly.

In other words, SNAPSHOT introduces problem especially when:

0. dependar has deep dependency tree (e.g. app:1-SNAPSHOT -> lib:2-SNAPSHOT -> core:3-SNAPSHOT). Here is one example scenario:
   • when we build lib:2-SNAPSHOT-1, the version of core was 3-SNAPSHOT-1,
   • when we build app:1-SNAPSHOT-1, the version of core was 3-SNAPSHOT-2,
   • so lib doesn't work even though it has passed all tests
1. dependee breaks backward compatibility
2. under high frequency release and integration (more than several times per day)

This opinion is based on my working experience, however I can imagine that other teams have different situation. :)

[kopax]

@grv87 either way, it is easy to setup back and test your use case without touching this module. If you think this could be integrated in CI in a certain way, I have found that you'll need to have a snapshot branch for releasing them, and as @KengoTODA it can bring some drawback.

@KengoTODA would you mind release 1.0.3 so I can test again with your module?

[KengoTODA]

I've released v1.0.3 just now, could you have a try? @kopax

[kopax]

v1.0.3 is working thanks!

[grv87]

All other branches are not released.

No. You can release to distribution channel.

The documentation you've referring to - says nothing about different branches. It says (emphasis is mine):

For each new commits added to the release branch

Distribution channels are targets where produced artifacts go, like different Maven release and snapshot repos. Not source branches.

But I've figured this out. They implemented other branches not so long ago: semantic-release/semantic-release#563. It's just not mentioned in documentation yet.

[kopax]

The documentation you've referring to - says nothing about different branches. It says (emphasis is mine):

Thanks to you I am aware of that feature. Maybe you should report that to them if that's not already done.

[grv87]

I saw that there are some problems reported in comments to that issue. I think they don't announce it just because it's not production-ready.
I think I'll wait for several months, finishing my current projects, then give a try to this new feature of semantic-release combined with your plugin.