Controlling release type from gradle command line?

[t...@quarendon.net]

We use bndtools (clearly), and currently have things set up so that we 

publish to a maven repository, so in the cnf/bnd.bnd file we have

-plugin.9.Release: \

 \

     aQute.bnd.repository.maven.provider.MavenBndRepository; \

         releaseUrl                      =   https://artifactory.ourdomain.local/artifactory/list/our-release-repo/ ; \

         snapshotUrl                     =   https://artifactory.ourdomain.local/artifactory/list/our-snapshot-repo/ ; \

         name                =       Release ;

 

-pom: version = ${versionmask;===;${@version}-SNAPSHOT}

But this will always do a snapshot release. If I want to do a "release" release,

I need to change the bnd.bnd file, commit it, run the build, then when its done 

change the code to put the "-SNAPSHOT" back again. This would seem to be rather 

tedious so I haven't done it. I don't really like the idea of locally modifying the file

as part of the script that does the build, that seems nasty. 

Is is possible to somehow override this from the gradle command line? I'm thinking

it might be useful to be able to have 2 jenkins build jobs, one that does a snapshot build 

and one that then does a release build.

It's quite possible though that I'm just mad and shouldn't be wanting to do that. I just don't

know how else I have a nightly build that runs and makes snapshot artefacts available, 

and then have some kind of "release" process that ends up publishing to a different place.

Maybe I *don't* have a nightly build that produces a snapshot, but that *every* nightly build

is actually a "release" build, and I leave the "-SNAPSHOT" off completely and use 

api-baselining support and just essentially semantically version each commit?

I know there are probably many ways t do this, but any experiences would be great.

Thanks.

[BJ Hargrave]

In the Bnd build, we use the -snapshot instruction to control whether the built version number is snapshot. See https://github.com/bndtools/bnd/blob/master/cnf/build.bnd#L25-L31. Also, note the versionmask in -pom: ===s.

Controlling it from the command line is not a good idea in my opinion. You need it under source control and tagged so you can build on the CI system and so you can always go back to the tag and build it again if needed.

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

BJ

[t...@quarendon.net]

On Friday, 16 June 2017 15:09:20 UTC+1, BJ Hargrave wrote:

In the Bnd build, we use the -snapshot instruction to control whether the built version number is snapshot. See https://github.com/bndtools/bnd/blob/master/cnf/build.bnd#L25-L31. Also, note the versionmask in -pom: ===s.

So in order to switch, you make a commit to do the build, then make a commit to go to snapshot? 

So during a release process you close the git to new commits (since this is presumably a pull model, that's easy), then make the commit, then once the release is done, put it back to "snapshot"?

That seems fine for infrequent releases. not sure how that would work if you wanted to "release" at the end of a 2 week sprint for example.

Thanks.

[Peter Kriens]

That seems fine for infrequent releases. not sure how that would work if you wanted to "release" at the end of a 2 week sprint for example.

Good software engineering requires that you have a git commit for a release build so you can tag it. So the only thing extra is the extra commit for the next snapshot. I think from ‘an amount of work’ point of view this is hard to beat? It basically takes the time of 2 builds.

Kind regards,

Peter Kriens

[t...@quarendon.net]

Good software engineering requires that you have a git commit for a release build so you can tag it. So the only thing extra is the extra commit for the next snapshot. I think from ‘an amount of work’ point of view this is hard to beat? It basically takes the time of 2 builds.

But good software engineering also suggests having a single button build doesn't it?. That is I should have a completely automated process for doing it, otherwise I'm just going to do it wrong and mess it up. Now I guess I can automate doing the git commits I suppose, but that feels like it will be fragile. I'll have to write some kind of process to automate making the change to the file, then commiting, then building, then undoing the change etc. And it's bound to fail to push the commits because of merge conflicts, and then require manual intervention etc.

Having checked out a commit in a CI build server and built it, there's no trouble then tagging what you've just built so that you can go back to it. So you don't need a *special* commit, you can just tag what's there can't you? That means you can then reproduce exactly that build if you want to, or easily know exactly what commit went into that build.

But I'm probably misunderstanding, or not really explaining what I'm trying to do.

Thanks for your time though.

[BJ Hargrave]

The commit to change to not-snapshot can be tagged and pushed as the tag. Then you build from the tag. That commit never has to be made to the main branch. So you can automate a CI build which you can manually run. This build can checkout the branch, make the change to non-snapshot, tag, push the tag (for posterity) and then build. So this CI build just needs to be parameterized with the tag name to use and the base commit to start with.

--
You received this message because you are subscribed to the Google Groups "bndtools-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

BJ