Depend on new gradle-git projects #30
Comments
|
Any success with that? Looks like it requires total rewrite from scratch. Do you have a plan, or a vision of new architecture? |
grv87
added a commit
to grv87/gradle-semantic-release-plugin
that referenced
this issue
Jun 6, 2018
Closes tschulte#30 BREAKING CHANGE
grv87
added a commit
to grv87/gradle-semantic-release-plugin
that referenced
this issue
Jun 6, 2018
Closes tschulte#30 BREAKING CHANGE:
grv87
added a commit
to grv87/gradle-semantic-release-plugin
that referenced
this issue
Jun 7, 2018
Closes tschulte#30 BREAKING CHANGE:
grv87
added a commit
to grv87/gradle-semantic-release-plugin
that referenced
this issue
Jun 7, 2018
Closes tschulte#30 BREAKING CHANGE:
grv87
added a commit
to grv87/gradle-semantic-release-plugin
that referenced
this issue
Jun 7, 2018
Closes tschulte#30 BREAKING CHANGE: Incompatible with other plugins still using Grgit 1, namely `org.ajoberstar.release-*` and `org.ajoberstar.github-pages`
grv87
added a commit
to grv87/gradle-semantic-release-plugin
that referenced
this issue
Jun 17, 2018
Closes tschulte#30 BREAKING CHANGE: Incompatible with other plugins still using Grgit 1, namely `org.ajoberstar.release-*` and `org.ajoberstar.github-pages`
|
I've copied classes from It works. So, I'm opened to any suggestions. Of course, it´s just a start. |
|
I have not yet had any time to really look into that issue. But from what I have seen, gradle-git has changed a lot. Another way to go might be to just use the original semantic-release code, instead of re-implementing it. |
|
What do you mean by 'original semantic-release code'? Isn't it implemented in JavaScript? |
|
Yes, that is implemented in JS. But maybe there is a way to call JavaScript from Java ( On the other hand, the idea behind semantic-release is not that complex, and gradle-git already implemented a lot of it, therefore I chose it as a base. And coming from an enterprise world, I also saw the need for different workflows, which are not supported by the much more strict and opinionated original. But maybe strict and opinionated it should be. On the other hand, the new https://github.com/ajoberstar/reckon/blob/master/docs/index.md, goes a long way in the right direction. This plugin (semantic-release) does only add the automatic check whether to increment major, minor or bugfix. Plus if to release at all, i.e. allowing to always call But now that I had a look, by using code from the ReckonPlugin (https://github.com/ajoberstar/reckon/blob/master/reckon-gradle/src/main/java/org/ajoberstar/reckon/gradle/ReckonPlugin.java), i.e. using, as you already suggested, But by at least somehow delegating work to e.g. https://github.com/semantic-release/release-notes-generator and https://github.com/semantic-release/commit-analyzer, we could at least get rid of that code (plus benefit from the better tested and maintained code of these projects). And semantic-release already has code for gitlab and to generate changelog files. |
|
Considering that there are too many existing plugins for original semantic-release, I see that the best approach is to just wrap original tools. |
|
Hi and thanks for doing this module. @grv87 by that, do you mean using That's what I am trying with Is there a way to implement semantic-release with gradle? How do you think it can be wrapped? |
yes, something like that.
I didn't actually use original
I see that Gitlab has an opened issue on this: https://gitlab.com/gitlab-org/gitlab-ce/issues/19421
Of course, there is. |
|
I found the KengoTODA's implementation perfect. It respect the semantic-release choosen language, respect the semantic-release plugin specification. As soon as when we decided to use semantic-release, it made sens that we would have nodejs in dev and in CI next to java. It make sens to maintain a plugin in javascript instead of java. Also, bringing an ecosystem of node devDependencies into java is not bad, javascript is way faster for most of the dev tasks. |
|
Is there a solution to this problem? Because as of Gradle 7 version 1.3.1 we are still using is no longer working. |
Someone reported #42 for this. I think that bug might be fixed with little effort. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Gradle-git was split into multiple repositories. We must upgrade to these new repositories. I.e. it is not possible to use both gradle-semantic-release plugin and git-publish plugin.
The text was updated successfully, but these errors were encountered: