Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release task should work in "detached HEAD" state #6

Open
tschulte opened this issue Sep 30, 2015 · 5 comments
Open

Release task should work in "detached HEAD" state #6

tschulte opened this issue Sep 30, 2015 · 5 comments
Milestone

Comments

@tschulte
Copy link
Owner

This is related to ajoberstar/gradle-git#137.

As stated in ajoberstar/gradle-git#137, CI servers do not always checkout the branch, but the latest commit of the branch instead, therefore operating in detached HEAD state. The plugin does however check the branch name

  • to decide if a release is possible (by default only master and release-branches are allowed)
  • to add the branch name to the version otherwise (branch feature/foo results in 1.0.0-foo-SNAPSHOT)

This will create problems when building in detached HEAD state.

@tschulte tschulte added this to the 2.0 milestone Sep 30, 2015
@kopax
Copy link

kopax commented Mar 28, 2019

Hi @tschulte and thanks for making this plugin!

I am a big fan of semantic-release, and I decided to wrap our gradle-release-plugin task with it.

We use Gitlab-CI for our CI jobs, thanks to @semantic-release/exec we are able to trigger the gradle release command. Now I have :

Release process failed, reverting back any changes made by Release Plugin
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task \':api:preTagCommit\'.
> Failed to push to remote - [[fatal: invalid refspec \'(HEAD detached from 2a50e314)

I have tried to disable the branch check, but being in a detached state is forbidden by the plugin.

I see this issue is quite old, do you know how I can get through?

Thanks in advance,

@grv87
Copy link
Contributor

grv87 commented Mar 28, 2019

@tschulte, as I see, to accomplish two tasks you mentioned, we could accept branch name from somewhere else. So these are not the problems.
The problem is that the plugin tries to do push. This is not possible in detached HEAD.
And the push is required in order to be sure that we are building (and tagging) actual master/release branch.
Do I understand correctly, or you had something else in mind?

Another question is how original semantic-release solves this problem? Either they don't check this. Or they don't support detached HEAD too, and just have workarounds to set branch name under Gitlab etc.?

@grv87
Copy link
Contributor

grv87 commented Mar 28, 2019

@kopax, correct me if I'm wrong.
In your build, semantic-release runs Gradle build with this plugin applied.
Right?

If yes, then this is senseless and won't work.
These are two separate implementations, you don't need both in one build.
When you workaround the problem with detached HEAD and get everything working, your version will be bumped twice.

When I was talking about semantic-release, I meant that we should replace this plugin with the new one, which wouldn't do any semantic-release work by itself but would call semantic-release to do it.

But your idea - to run Gradle from semantic-release - may be even simpler.
You don't need this plugin.
You just need a way to pass the version from semantic-release to Gradle. For example, save it to a temp file, and in build.gradle read it from there.

UPDATE:
@kopax, I see that you discovered KengoTODA's new work: https://github.com/KengoTODA/gradle-semantic-release-plugin
This is just the implementation of the second idea, on which I said it may be even simpler.
So, I hope your problems are resolved.

@kopax
Copy link

kopax commented Mar 29, 2019

@grv87 I got lucky because KengoTODA's released that like two days ago. I have tested it and it was working only if I did my own build from master.

Yes, I have found this plugin too complexe to work, I have tried to remove the 2nd tag from gradle release etc.... I believe this can be done, but as you said without this plugin.

I have tested KengoTODA's implementation and I am very satisfied with it. Thanks for the quick reply @grv87

@tschulte
Copy link
Owner Author

tschulte commented Apr 4, 2019

Thanks for pointing to KengaTODA's implementation. I have not known it yet. That is a very interesting approach to call node instead of gradle when doing a release and updating gradle.properties. That way only the build server needs to use node and the devs can use gradle in their day-to-day work. And only the build server needs node installed.

The first idea would mean to call node from gradle during configuration phase and set the version. That might be a performance problem. But the advantage would be not having to commit the version and thus being more true to the idea of semantic release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants