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.

Sign up for GitHub

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

Prepare for Maven release #613

Closed
wants to merge 6 commits into from
Closed

Prepare for Maven release #613

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
0fdec44
Prepare for Maven release
Jan 15, 2013
57801df
promoting released artifacts and closed staging
Jan 15, 2013
59f3fa6
removed settings.xml, updated building-junit.txt and pom.xml
Jan 16, 2013
a83de0f
public GnuPG key 67893CC4
Jan 16, 2013
4908f0a
-Dtag=4.12
Jan 17, 2013
aa70747
removed "Update SNAPSHOT version in pom.xml" "Upload stuff to github …
Jan 17, 2013
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 7 additions & 4 deletions doc/building-junit.txt
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,14 +2,17 @@ Steps to build junit:

- Must be manual
- Write release notes
- Update version in pom.xml
- Update SNAPSHOT version in pom.xml
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, sometimes it will be a SNAPSHOT version, and sometimes, it will be a final release, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dsaff
Proposing always snapshot in GitHub.
Release should be created by release-plugin and deployed from ClouBees as a copy of latest snapshot commit in GitHub.

@stephenc
@marcphilipp
Do you agree?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dsaff
@marcphilipp
@stephenc
Is it really worth to upgrade snapshot version in GitHub?
Easier to keep something like 4.0-SNAPSHOT.
Less manual work.

I think the maven release plugin will upgrade both versions at the same time and snapshot committed in to GitHub.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't have a reason to need the snapshot version upgraded on every release. Do we need it further on in the build chain?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK the maven-release-plugin takes care of updating the snapshot version in the repo as well. Thus, I don't see any benefit of having 4.0-SNAPSHOT in the repo.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcphilipp
I see only benefit from M2 release plugin in Jenkins.
@dsaff I hope you have the rights to login to our CloudBees account.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcphilipp
yes, using maven-release-plugin was the cool idea and standard way to make a release.
still i think the simplest and more safe solution for you @marcphilipp and @dsaff will be to use M2 release plugin in Jenkins instead of typing Maven goals with properties and tag name in Maven command.

- Not too tedious:
- Push to github (dsaff _and_ KentBeck)
- Run the mvn clean install
- Upload stuff to github (including tag)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're no longer uploading the artifacts to github.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dsaff
and tags?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yes, when we release, we should definitely tag the source in github.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dsaff
Regarding the tags and release management in CloudBees. The tags do not need to be specified by you in GitHub manually. You can specify it together with new versions and starting the build + deployment in one step in Jenkins.

Maybe you didn't see the discussion (setting release and dev version variables) from yesterday morning.
@marcphilipp said:
"We cannot use the M2 release Jenkins plugin to set these variables for us because it is not included in the free plan."
I asked if there is a way to persuade CloudBees to have this plugin.
@stephenc said
"I can see about if we can install the plugin for you if you really need it. Shouldn't be an issue, but not my call"

@dsaff
So if we had it, then you could have a more simple work without typing commands like mentioned in doc/building-junit.txt. That file is just info what Jenkins will do with the settings in pure UI release mgmt.

Just see this video which demonstrates how the release process should be like:

http://www.youtube.com/watch?v=7IJVG7asfPE

I am going to add -Dtag=4.12 to the doc, but using the M2 release Jenkins plugin it would be as easy as using UI.

Sorry for the long comment.

- Push to maven
- mvn -Dgpg.passphrase="<passphrase>" -Psign clean deploy
- Promote
- If not done, update src/main/config/settings.xml in /private/.../settings.xml on CloudBees' webdav share.
- If not done, copy GnuPG keys in to ${gpg.homedir}. See settings.xml.
- Perform Maven Release in Jenkins
- (to deploy snapshot version) mvn clean deploy
- (to deploy specified release version) mvn clean release:prepare release:perform
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably document the two parameters mentioned by @stephenc in https://github.com/KentBeck/junit/pull/511#issuecomment-12268366 here:

mvn -DreleaseVersion=4.12 -DdevelopmentVersion=4.13-SNAPSHOT release:prepare release:perform

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a step missing here: Once you have pushed a release to Sonatype's staging repo, you have to close that repo as described here:
https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide#SonatypeOSSMavenRepositoryUsageGuide-8a.ReleaseIt

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcphilipp
ok, but now it's event better than deploying it all manually.

I did not mention these system props because you use to configure the release version in Jenkins.
I understood @stephenc that release:prepare release:perform is simple and enough that you need to type as maven goals.
I think this will be real use. We should check it out. Are you able to delete a deployed artifact from Nexus release repo?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcphilipp
Pls see the building-junit.txt if you like it now.
Thx

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you need to update the pull request ;-)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While we're on the free FOSS plan of ClouBees the set of Jenkins plugins is limited. We cannot use the M2 release Jenkins plugin to set these variables for us because it is not included in the free plan. Thus we have to use regular Jenkins job params and pass those to the Maven call if we want to use Jenkins for releasing.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marcphilipp
I could not find the option for release version in my DEV@cloud you showed me either.
Then it is uncomfortable use to type these props. Is there any way to persuade the CloudBees without paying.
They are Java based?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see about if we can install the plugin for you if you really need it.
Shouldn't be an issue, but not my call

On 16 January 2013 08:32, Tibor Digana [email protected] wrote:

In doc/building-junit.txt:

  • Not too tedious:
    • Push to github (dsaff and KentBeck)
    • Run the mvn clean install
    • Upload stuff to github (including tag)
      • Push to maven
      • mvn -Dgpg.passphrase="" -Psign clean deploy
      • If not done, update src/main/config/settings.xml in /private/.../settings.xml on CloudBees' webdav share.
      • If not done, copy GnuPG keys in to ${gpg.homedir}. See settings.xml.
      • Perform Maven Release in Jenkins
      • (to deploy snapshot version) mvn clean deploy
      • (to deploy specified release version) mvn clean release:prepare release:perform

@marcphilipp https://github.com/marcphilipp
I could not find the option for release version in my DEV@cloud you
showed me either.
Then it is uncomfortable use to type these props. Is there any way to
persuade the CloudBees without paying.
They are Java based?

—
Reply to this email directly or view it on GitHubhttps://github.com/KentBeck/junit/pull/613/files#r2662293.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dsaff
See above.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe CloudBees logo in JUnit website would make it :)

- Promote the maven artifacts and close staging repository if release successfully
- Tedious:
- Update SourceForge if major release
- Update javadocs on github site (and "latest" link)
Expand Down
40 changes: 14 additions & 26 deletions pom.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -68,21 +68,14 @@
</dependencies>
<distributionManagement>
<downloadUrl>https://github.com/KentBeck/junit/wiki/Download-and-Install</downloadUrl>
<!--
Currently the deployment is under development and enabled for
the Snapshot Repository of the Maven Central.
-->
<snapshotRepository>
<id>maven-central-snapshots</id>
<name>upload.to.maven.central.snapshots</name>
<id>junit-snapshot-repo</id>
<name>Nexus Snapshot Repository</name>
<url>https://oss.sonatype.org/content/repositories/snapshots/</url>
</snapshotRepository>
<!--
Remote Release Repository.
-->
<repository>
<id>maven-central</id>
<name>upload.to.maven.central</name>
<id>junit-releases-repo</id>
<name>Nexus Release Repository</name>
<url>https://oss.sonatype.org/service/local/staging/deploy/maven2/</url>
</repository>
</distributionManagement>
Expand All @@ -98,20 +91,6 @@
</includes>
</resource>
</resources>
<extensions>
<!--
Specify HTTP providers.
The Maven Wagon is a transport abstraction.
For more information see http://maven.apache.org/wagon/index.html
and the guide
http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploy-ssh-external.html
-->
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-http</artifactId>
<version>1.0</version>
</extension>
</extensions>
<plugins>
<!--
Both "org.apache" and "org.codehaus" are default providers of MOJO plugins
Expand Down Expand Up @@ -282,11 +261,20 @@
</execution>
</executions>
</plugin>
<plugin>
<artifactId>maven-release-plugin</artifactId>
<version>2.3.2</version>
<configuration>
<mavenExecutorId>forked-path</mavenExecutorId>
<useReleaseProfile>false</useReleaseProfile>
<arguments>-Pjunit-release</arguments>
</configuration>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<id>sign</id>
<id>junit-release</id>
<!--
Signs all artifacts before deploying to Maven Central.
-->
Expand Down
50 changes: 21 additions & 29 deletions src/main/config/settings.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<!--
The JUnit build system is using this file.
The JUnit build system is using this file as a template.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would rather see this in building-junit.txt.

It is bad practice to give, what is a partial file, as a template. What you actually want to do is add the entries and the but only if you are a release manager. Nobody else needs this content, and I fear we will just confuse Maven nubies including this entire file.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ok, we can move it to the bottom of building-junit.txt.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change is still coming, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dsaff
done

All users should ignore it.

Settings Reference: http://maven.apache.org/ref/3.0.4/maven-settings/settings.html
Expand All @@ -21,36 +21,28 @@
a unique name within the system (referred to by the 'id' attribute below).
-->
<server>
<id>maven-central</id>
<username>???</username>
<password>???</password>
<filePermissions>664</filePermissions>
<directoryPermissions>775</directoryPermissions>
<configuration>
<timeout>15000</timeout> <!-- 15 seconds -->
<httpConfiguration>
<put>
<connectionTimeout>15000</connectionTimeout> <!-- 15 seconds -->
<readTimeout>15000</readTimeout> <!-- 15 seconds -->
</put>
</httpConfiguration>
</configuration>
<id>junit-snapshot-repo</id>
<username><!--a username registered with Sonatype for deployment--></username>
<password><!--corresponding password--></password>
</server>
<server>
<id>maven-central-snapshots</id>
<username>???</username>
<password>???</password>
<filePermissions>664</filePermissions>
<directoryPermissions>775</directoryPermissions>
<configuration>
<timeout>15000</timeout> <!-- 15 seconds -->
<httpConfiguration>
<put>
<connectionTimeout>15000</connectionTimeout> <!-- 15 seconds -->
<readTimeout>15000</readTimeout> <!-- 15 seconds -->
</put>
</httpConfiguration>
</configuration>
<id>junit-releases-repo</id>
<username><!--a username registered with Sonatype for deployment--></username>
<password><!--corresponding password--></password>
</server>
</servers>
<profiles>
<profile>
<id>junit-release</id>
<properties>
<gpg.keyname>...</gpg.keyname>
<gpg.passphrase>...</gpg.passphrase>
<gpg.defaultKeyring>false</gpg.defaultKeyring>
<gpg.useagent>true</gpg.useagent>
<gpg.homedir>/private/.../.gnupg</gpg.homedir>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These directories only need to be set if you are paranoid and want to keep your signing key on removable storage. If you are comfortable leaving the default gpg keyring you just need to keep gpg.keyname, gpg.passphrase and gpg.useagent

Additionally if you will have one and only one gpg key that will be used to sign releases in central you can hardcode the gpg.keyname in to the pom.xml and leave just the gpg.passphrase for either manual prompt via the agent or providing via ~/.m2/settings.xml in the profile.

Though if people want to release their own forks of JUnit to their own internal repo they will thank you for leaving gpg.keyname as a property.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stephenc
I am using just one key and do not need gpg.keyname -GPG plugin requested the passphrase which is enough.
We cannot use interactive mode of the plugin in CloudBees, so the passphrase has to be set in props like this.

@marcphilipp
What is the gpg keyname ?
If we set it in POM, we can removed it from settings.
Better to set it explicitly than wondering one day why build failed after adding non-default keyname.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahem.... @Tibor17 I work for CloudBees.... though I should probably do up a blog post on how to do a release that pushes to central ;-)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stephenc
I changed my previous comment.

<gpg.publicKeyring>/private/.../.gnupg/pubring.gpg</gpg.publicKeyring>
<gpg.secretKeyring>/private/.../.gnupg/secring.gpg</gpg.secretKeyring>
</properties>
</profile>
</profiles>
</settings>