Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [krazo-dev] How to perform releases


On Sat, Oct 19, 2019 at 3:20 PM Christian Kaltepoth <christian@xxxxxxxxxxxx> wrote:
Hi Ivar,

thanks a lot for sharing these details. In this case I'll try to check why the setup documented by Oracle is so complicated compared to what you are suggesting. Because it is basically the same process.

It is probably legacy from times when the build systems were more complicated...
  

Christian

Am Sa., 19. Okt. 2019 um 10:49 Uhr schrieb Ivar Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>:


On Sat, Oct 19, 2019 at 9:45 AM Christian Kaltepoth <christian@xxxxxxxxxxxx> wrote:
Hi Ivar,

thanks a lot for sharing your thoughts. This definitely looks much simpler than the release scripts I saw in the Eclipse Wiki some time ago. I would be fine with trying it this way. 

A few questions:
  • I wonder what the simplest way is to actually allow Jenkins to push back to the GitHub repo. Set up a separate SSH key pair would be the way to go?
Yes, that's how we did it. 
  • Step 2 in your example is part of the single release job? Or is it just some kind of confirm step?
Yes, it is the same job. 
  • Do you manually merge the release branch back to master or would this be part of step 2?
I would do a manual merge there. But it could be automated as well. 

Thanks

Christian

Am Sa., 19. Okt. 2019 um 08:53 Uhr schrieb Ivar Grimstad <ivar.grimstad@xxxxxxxxxxxxxxxxxxxxxx>:
I don't like creating things manually so what I usually do is to let the Jenkins job create the tag for me something like this:

Given I have created a release branch e.g. release/1.0.0
I then have a parameterized Jenkins Job with "version" as a String parameter. In this case, the value of ${version} would be "1.0.0"

The Job config would then look like this:

Step one, Execute Shell:
# Version the pom and create tag
git checkout release/${version}
git pull origin release/${version}
mvn --batch-mode release:prepare -DreleaseVersion=${version}-b$BUILD_NUMBER -DdevelopmentVersion=${version}-SNAPSHOT
mvn release:clean
git push origin release/${version}
git push --tags

Step two, Execute Shell:
# Build the deliverable
git checkout ${version}-b$BUILD_NUMBER

mvn deploy (or whatever step is needed to get the artifact out to the repository)

Ivar

On Sat, Oct 19, 2019 at 8:17 AM Christian Kaltepoth <christian@xxxxxxxxxxxx> wrote:
Hi all,

I'm about to start preparing the required setup for publishing our first release. Unfortunately there are some aspects that are much more complicated under the Eclipse umbrella. Especially:
  • The GPG key used for signing releases is only available on Jenkins, and we don't have direct access to it
  • We don't have our own Sonatype OSS account to push the releases to central.
This means that we MUST create a separate release job on our Jenkins instance. Previously I simply did releases using my own GPG key and my private Sonatype account.

Now the question is how we design our release job. Oracle published a recommendation which basically works like this:
  • You define as special release job which is parameterized
  • The job checks out the source, updates the versions, tags the release and pushes the changes to GitHub
  • Then the job builds the artifacts and pushes them to the Sonatype staging area
IMO this approach as quite some downsides:
  • It requires a long and non-trival shell script
  • It requires us set up the repository so that Jenkins can also push tags and version updates which feels a bit dirty
To be honest, I don't like that. In our company we are using a much more lightweight approach, which basically works like this.

I update the version in the pom, tag the release and push the result manually on my workstation like this:

    mvn versions:set -DgenerateBackupPoms=false -DnewVersion=1.1.0
    git commit -am "Preparing 1.1.0 release"
    git tag 1.1.0
    git push 

Our GitLab instance is configured to start a special job for all tags which basically just runs "mvn deploy". That's all. Simple and straight forward. I would like create our Krazo job in a similar way:
  • We update the version in the pom and create the tag manually.
  • Then we start a release job on Jenkins which has a single parameter: The tag to release
  • The job the checks out this tag and perform the release (which should be easy, as we are already doing something similar with our nightly job)
What do you think about this? Do you think this approach is acceptable?

Christian


_______________________________________________
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/krazo-dev


--

Ivar Grimstad

Jakarta EE Developer Advocate | Eclipse Foundation, Inc.

Eclipse Foundation: The Platform for Open Innovation and Collaboration
_______________________________________________
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/krazo-dev


--
_______________________________________________
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/krazo-dev


--

Ivar Grimstad

Jakarta EE Developer Advocate | Eclipse Foundation, Inc.

Eclipse Foundation: The Platform for Open Innovation and Collaboration
_______________________________________________
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/krazo-dev


--
_______________________________________________
krazo-dev mailing list
krazo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/krazo-dev


--

Ivar Grimstad

Jakarta EE Developer Advocate | Eclipse Foundation, Inc.

Eclipse Foundation: The Platform for Open Innovation and Collaboration

Back to the top