Open michelzanini opened 4 years ago
+1
In these cases, what are the downsides to checking out the tag you want to rebuild and running Gradle again? (Just trying to understand what benefits this provides)
I find this useful also; sometimes you don't infer the final version, but just impose it at some point. Say you would like to release something in a CI/CD environment, but the flow is only triggered when you create a tag. In that case, Reckon will recognize the next final version instead of the actual one.
For those cases, it's also useful to ignore the default Reckon behavior because you want the actual tag value rather than the future one.
Some setting(s) that let the users use the current tag, bypassing Reckon discovery, will be helpful.
@michelzanini Thinking about your use case more I think the ideal way around it would be to configure CI builds to not fire (or not release) when only certain files are changed.
That may not be possible in all CI servers, but for Actions at least:
on:
push:
paths-ignore:
- 'README.*'
- 'docs/**'
@x80486 I'm not fully sure I'm following your use case. The general case of push a tag and have reckon re-use that already works (and is in fact how I've used reckon to release my OSS projects for years).
Unless I'm doing something wrong, I think Reckon always takes the next tag instead. For instance, let's say you are developing something and your repository is at v0.1.0
. Three merges are done, so the tag it's still the same (I don't increase it for every merge). Now I'm ready to release v0.1.1
(patch
increase, for instance); from the moment such tag is pushed, Recon will infer v0.1.2
instead for that build where the tag was pushed from.
So basically, what I would like to read is the tag in question, and not to infer the next one.
@x80486 Can you open a new issue with a reproduction of that scenario? It should already work, so I'm curious to see the details.
OK, I'll create a small project for this, but I think the key part here is that what initiates the build is the action of pushing the tag to the repository, that's why I say Reckon will infer the next version at that point, instead of reading the actual tag.
Take a look at the last two builds for this project.
The last pipeline was triggered by pushing a tag (v0.2.0
), so Reckon inferred version 0.3.0
. This is the usual Reckon's behavior, but it's basically the ask for this ticket: that it would be great to just read the actual tag, rather than inferring it sometimes.
The build before the last one would be a usual build done by a merge commit into the project's mainstream branch — main
in this case. The version is correctly inferred.
@x80486 You're reproducing #133 rather than the issue @michelzanini reported in OP. Please make future replies on #133. (As noted in my comments there, you're experiencing intentional behavior of reckon.)
Hi,
There are a few files in our repositories that we want to be ignored when they are changed, without the need to create a new released version. For example read me, change log and documentation files etc...
The problem we are having is that we tag using Reckon and the changes to this files can come after the tag. For example:
I know if the HEAD has a tag, it's possible to rebuild the same tag. I wanted to be able to tell it to rebuild the last tag regardless of new commits after the last tag.
I was checking out Nebula release plugin and they support this as following:
./gradlew -Prelease.useLastTag=true final
You can tell it to use the last tag and re-build it. I would be really good if it was possible to do this with Reckon. Tell it to re-use the last tag instead of incrementing.
I know it seems like an edge case, but it's much more useful that it looks.