diff --git a/multi/multi__spring_cloud_release_tools.html b/multi/multi__spring_cloud_release_tools.html index 39ad12c0..6eb99c66 100644 --- a/multi/multi__spring_cloud_release_tools.html +++ b/multi/multi__spring_cloud_release_tools.html @@ -1,8 +1,9 @@ 1. Spring Cloud Release Tools
1. Spring Cloud Release Tools
Prev   

1. Spring Cloud Release Tools

Spring Cloud projects reuse the same pattern of building and deploying the applications. That’s -why this tool makes it easy to automate the release / dependency update process of our applications.

1.1 What does it do?

  • Clones the Spring Cloud Release project and picks all versions (Boot + Cloud projects)

  • Modifies the project versions with values from SC-Release

    • throws an exception when we bump versions to release and there’s a SNAPSHOT version referenced in the POM

  • Performs the build and checks if the docs modules have properly created the documentation

    • throws an exception when in the docs module there’s an unresolved tag in any HTML file
  • Commits changed poms (ONLY FOR NON-SNAPSHOT VERSIONS)
  • Creates a tag for the release / milestone (ONLY FOR NON-SNAPSHOT VERSIONS)
  • Runs the deployment of the artifacts
  • Publishes the docs (to spring-cloud-static for non-snapshots, to gh-pages for snapshots)
  • Reverts back to snapshots, bumps the version by a patch (1.0.1.RELEASE → 1.0.2.BUILD-SNAPSHOT) (ONLY FOR RELEASE VERSIONS)
  • Closes the milestone on Github (e.g. v1.0.1.RELEASE) (ONLY FOR NON-SNAPSHOT VERSIONS)
  • Generates an email template under target/email.txt (ONLY FOR NON-SNAPSHOT VERSIONS)
  • Generates a blog template under target/blog.md (ONLY FOR NON-SNAPSHOT VERSIONS)
  • Generates a tweet template under target/tweet.txt (ONLY FOR NON-SNAPSHOT VERSIONS)
  • Generates a release notes template under target/notes.md (ONLY FOR NON-SNAPSHOT VERSIONS)
  • Updates project information in Sagan (http://spring.io) (ONLY FOR SNAPSHOT / RELEASE VERSIONS)
  • For GA/ SR release will create an issue in Spring Guides under https://github.com/spring-guides/getting-started-guides/issues/
  • For GA/ SR release will update the links under https://github.com/spring-cloud/spring-cloud-static/tree/gh-pages/current
[Important]Important

Starting with version that does Sagan integration, you MUST pass the OAuth token, -otherwise the application will fail to start

1.2 What should I do first?

Members of the Spring Cloud Team typically use this tool as follows. They first +why this tool makes it easy to automate the release / dependency update process of our applications.

1.1 What does it do?

1.1.1 Single project

For a single project

  • Clones the Spring Cloud Release project and picks all versions (Boot + Cloud projects)

  • Modifies the project versions with values from SC-Release

    • throws an exception when we bump versions to release and there’s a SNAPSHOT version referenced in the POM

  • Performs the build and checks if the docs modules have properly created the documentation

    • throws an exception when in the docs module there’s an unresolved tag in any HTML file
  • Commits changed poms (ONLY FOR NON-SNAPSHOT VERSIONS)
  • Creates a tag for the release / milestone (ONLY FOR NON-SNAPSHOT VERSIONS)
  • Runs the deployment of the artifacts
  • Publishes the docs (to spring-cloud-static for non-snapshots, to gh-pages for snapshots)
  • Reverts back to snapshots, bumps the version by a patch (1.0.1.RELEASE → 1.0.2.BUILD-SNAPSHOT) (ONLY FOR RELEASE VERSIONS)
  • Closes the milestone on Github (e.g. v1.0.1.RELEASE) (ONLY FOR NON-SNAPSHOT VERSIONS)
[Important]Important

Starting with version that does Sagan integration, you MUST pass the OAuth token, +otherwise the application will fail to start

After project release

1.1.2 Meta-release

  • Uses the fixed versions to clone and check out each project (e.g. spring-cloud-sleuth: 2.1.0.RELEASE)

  • From the version analyzes the branch and checks it out. E.g.

    • for spring-cloud-release’s `Finchley.RELEASE version will resolve either Finchley.x branch or will fallback to master if there’s no Finchley.x branch.
    • for spring-cloud-sleuth’s `2.1.0.RELEASE version will resolve 2.1.x branch
  • Performs the release tasks per each project
  • Performs the post release tasks at the end of the release
[Important]Important

For the meta-releaser to work we assume that the path to the +custom configuration file for each project is always config/releaser.yml.

1.2 What should I do first?

Members of the Spring Cloud Team typically use this tool as follows. They first clone the releaser locally and build the jar manually

$ git clone git@github.com:spring-cloud/spring-cloud-release-tools.git
 $ cd spring-cloud-release-tools
 $ ./mvnw clean install
[Important]Important

You must set the value of the OAuth token. You can do it either via @@ -101,8 +102,14 @@ $ java -jar ~/repo/spring-cloud-release-tools/spring-cloud-release-tools-spring/ 

$ java -jar ~/repo/spring-cloud-release-tools/spring-cloud-release-tools-spring/target/spring-cloud-release-tools-spring-1.0.0.BUILD-SNAPSHOT.jar --releaser.pom.branch=vDalston.SR1 --spring.config.name=releaser -r d-p -i=false

Running single task 'closeMilestone' (automatic).  

$ java -jar ~/repo/spring-cloud-release-tools/spring-cloud-release-tools-spring/target/spring-cloud-release-tools-spring-1.0.0.BUILD-SNAPSHOT.jar --releaser.pom.branch=vDalston.SR1 --spring.config.name=releaser --closeMilestone -i=false

-

1.5 Project options

  • releaser.fixed-versions - A String to String mapping of manually set versions. E.g. "spring-cloud-cli" → "1.0.0.RELEASE" will set -the spring-cloud-cli.version to 1.0.0.RELEASE regardless of what was set in spring-cloud-release project. Example --releaser.fixed-versions[spring-cloud-cli]=1.0.0.RELEASE.
  • releaser.git.fetch-versions-from-git - If true then should fill the map of versions from Git. If false then picks fixed versions
  • releaser.git.clone-destination-dir - Where should the Spring Cloud Release repo get cloned to. If null defaults to a temporary directory
  • releaser.git.spring-cloud-release-git-url - URL to Spring Cloud Release Git repository. Defaults to https://github.com/spring-cloud/spring-cloud-release
  • releaser.git.documentation-url - URL to the documentation Git repository. Defaults to https://github.com/spring-cloud/spring-cloud-static
  • releaser.git.documentation-branch - Branch to check out for the documentation project. Defaults to gh-pages
  • releaser.git.oauth-token - GitHub OAuth token to be used to interact with GitHub repo.
  • releaser.git.username - Optional Git username. If not passed keys will be used for authentication.
  • releaser.git.password - Optional Git password. If not passed keys will be used for authentication.
  • releaser.git.number-of-checked-milestones - In order not to iterate endlessly over milestones we introduce a threshold of milestones that +

1.5 How to run meta-release (automatic-mode)

All you have to do is run the jar with the releaser and pass the +-x=true option to turn on meta-release and a list of fixed versions +in the `--"releaser.fixed-versions[project-name]=project-version" format

$ java -jar spring-cloud-release-tools-spring/target/spring-cloud-release-tools-spring-1.0.0.BUILD-SNAPSHOT.jar --spring.config.name=releaser -x=true --"releaser.fixed-versions[spring-cloud-sleuth]=2.0.1.BUILD-SNAPSHOT"
[Important]Important

For the meta release the startFrom or taskNames take into consideration +the project names, not task names. E.g. you can start from spring-cloud-netflix project, +or build only tasks with names spring-cloud-build,spring-cloud-sleuth.

1.6 Project options

  • releaser.fixed-versions - A String to String mapping of manually set versions. E.g. "spring-cloud-cli" → "1.0.0.RELEASE" will set +the spring-cloud-cli.version to 1.0.0.RELEASE regardless of what was set in spring-cloud-release project. Example --releaser.fixed-versions[spring-cloud-cli]=1.0.0.RELEASE. +Use these properties to provide versions for the meta release.
  • releaser.meta-release.enabled - You have to turn it on to enable a meta release. Defaults to false
  • releaser.meta-release.release-train-project-name - Name of the project that represents the BOM of the release train. Defaults to spring-cloud-release
  • releaser.meta-release.git-org-url - The URL of the Git organization. We’ll append each project’s name to it. +Defaults to https://github.com/spring-cloud
  • releaser.git.fetch-versions-from-git - If true then should fill the map of versions from Git. If false then picks fixed versions
  • releaser.git.clone-destination-dir - Where should the Spring Cloud Release repo get cloned to. If null defaults to a temporary directory
  • releaser.git.spring-cloud-release-git-url - URL to Spring Cloud Release Git repository. Defaults to https://github.com/spring-cloud/spring-cloud-release
  • releaser.git.documentation-url - URL to the documentation Git repository. Defaults to https://github.com/spring-cloud/spring-cloud-static
  • releaser.git.documentation-branch - Branch to check out for the documentation project. Defaults to gh-pages
  • releaser.git.oauth-token - GitHub OAuth token to be used to interact with GitHub repo.
  • releaser.git.username - Optional Git username. If not passed keys will be used for authentication.
  • releaser.git.password - Optional Git password. If not passed keys will be used for authentication.
  • releaser.git.number-of-checked-milestones - In order not to iterate endlessly over milestones we introduce a threshold of milestones that we will go through to find the matching milestone. Defaults to 10
  • releaser.maven.build-command - Command to be executed to build the project. Defaults to ./mvnw clean install -Pdocs
  • releaser.maven.deploy-command - Command to be executed to deploy a built project". Defaults to ./mvnw deploy -DskipTests -Pfast
  • releaser.maven.publish-docs-commands - Command to be executed to deploy a built project. If present {{version}} will be replaced by the proper version. Defaults to the standard Spring Cloud wget and execution of ghpages.
  • releaser.maven.system-properties - Additional system properties that should be passed to any commands. If present {{systemProps}} will be replaced by the contents of this property.
  • releaser.maven.wait-time-in-minutes - Max wait time in minutes for the process to finish. Defaults to 20
  • releaser.gradle.gradle-props-substitution - a map containing a key which is a property key inside gradle.properties and a value of a project name. E.g. in gradle.properties you have foo=1.0.0.BUILD-SNAPSHOT and you would like spring-cloud-contract version to @@ -114,18 +121,19 @@ Example for application arguments: java -jar target/spring run a script (e.g. scripts/foo.sh) then inside foo.sh if you call a Maven build ./mvnw clean install then remember to pass all arguments of the script there too. E.g. ./mvnw clean install ${@}. That’s because the releaser will pass any system properties to the build / deploy command, such as system properties - with keys and we need them to be passed inside the command executed by the releaser.

1.6 Examples

1.6.1 Keeping configuration in the project

If your project has some custom configuration (e.g. Spring Cloud Contract needs a script to be executed + with keys and we need them to be passed inside the command executed by the releaser.

1.7 Examples

1.7.1 Keeping configuration in the project

If your project has some custom configuration (e.g. Spring Cloud Contract needs a script to be executed to build the project and properly merge the docs) then you can put a file named e.g. releaser.yml under config folder and run your application like this:

$ wget http://repo.spring.io/libs-milestone/org/springframework/cloud/internal/spring-cloud-release-tools-spring/1.0.0.M1/spring-cloud-release-tools-spring-1.0.0.M1.jar -O ../spring-cloud-release-tools-spring-1.0.0.M1.jar
 $ java -jar target/spring-cloud-release-tools-spring-1.0.0.M1.jar --spring.config.name=releaser
[Tip]Tip

Notice that we’re downloading the jar to a parent folder, not to target. That’s because target get cleaned -during the build process

1.6.2 Specifying A Branch

By deafult the releaser will default to using the master branch of spring-cloud-release. -If you would like to use another branch you can specify it using the releaser.pom.branch property.

$ java -jar spring-cloud-release-tools-spring-1.0.0.M1.jar --releaser.pom.branch=Camden.SR6

1.6.3 Using Environment Variables

In some cases it might be easier to specify environment variables instead of passing parameters to +during the build process

[Important]Important

For the meta-releaser to work we assume that the path to the +configuration file is always config/releaser.yml.

1.7.2 Specifying A Branch

By deafult the releaser will default to using the master branch of spring-cloud-release. +If you would like to use another branch you can specify it using the releaser.pom.branch property.

$ java -jar spring-cloud-release-tools-spring-1.0.0.M1.jar --releaser.pom.branch=Camden.SR6

1.7.3 Using Environment Variables

In some cases it might be easier to specify environment variables instead of passing parameters to releaser. For example, you might want to use environment variables if you are going to be releasing multiple projects, this keeps you from having to specify the same parameters for each release

$ export RELEASER_POM_BRANCH=Dalston.RELEASE
 $ export RELEASER_GIT_OAUTH_TOKEN=...
 $ wget http://repo.spring.io/libs-milestone/org/springframework/cloud/internal/spring-cloud-release-tools-spring/1.0.0.M1/spring-cloud-release-tools-spring-1.0.0.M1.jar -O spring-cloud-release-tools-spring-1.0.0.M1.jar
-$ java -jar target/spring-cloud-release-tools-spring-1.0.0.M1.jar --releaser.working-dir=/path/to/project/root

1.7 FAQ

1.7.1 JSchException: Auth fail

I got such an exception

Caused by: org.eclipse.jgit.errors.TransportException: git@github.com:spring-cloud/spring-cloud-sleuth.git: Auth fail
+$ java -jar target/spring-cloud-release-tools-spring-1.0.0.M1.jar --releaser.working-dir=/path/to/project/root

1.8 FAQ

1.8.1 JSchException: Auth fail

I got such an exception

Caused by: org.eclipse.jgit.errors.TransportException: git@github.com:spring-cloud/spring-cloud-sleuth.git: Auth fail
 	at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:160) ~[org.eclipse.jgit-4.6.0.201612231935-r.jar!/:4.6.0.201612231935-r]
 	at org.eclipse.jgit.transport.SshTransport.getSession(SshTransport.java:137) ~[org.eclipse.jgit-4.6.0.201612231935-r.jar!/:4.6.0.201612231935-r]
 	at org.eclipse.jgit.transport.TransportGitSsh$SshPushConnection.<init>(TransportGitSsh.java:322) ~[org.eclipse.jgit-4.6.0.201612231935-r.jar!/:4.6.0.201612231935-r]
diff --git a/multi/multi_spring-cloud-release-tools.html b/multi/multi_spring-cloud-release-tools.html
index 93ba3659..6d0b5b96 100644
--- a/multi/multi_spring-cloud-release-tools.html
+++ b/multi/multi_spring-cloud-release-tools.html
@@ -1,3 +1,3 @@
 
       
-   Spring Cloud Release Tools
Spring Cloud Release Tools
   Next
Spring Cloud Release Tools
Table of Contents
1. Spring Cloud Release Tools
1.1. What does it do?
1.2. What should I do first?
1.3. How to run it (interactive mode)
1.4. How to run it (automatic mode)
1.5. Project options
1.6. Examples
1.6.1. Keeping configuration in the project
1.6.2. Specifying A Branch
1.6.3. Using Environment Variables
1.7. FAQ
1.7.1. JSchException: Auth fail
   Next
   1. Spring Cloud Release Tools

\ No newline at end of file
+   Spring Cloud Release Tools
Spring Cloud Release Tools
   Next
Spring Cloud Release Tools
Table of Contents
1. Spring Cloud Release Tools
1.1. What does it do?
1.1.1. Single project
1.1.2. Meta-release
1.2. What should I do first?
1.3. How to run it (interactive mode)
1.4. How to run it (automatic mode)
1.5. How to run meta-release (automatic-mode)
1.6. Project options
1.7. Examples
1.7.1. Keeping configuration in the project
1.7.2. Specifying A Branch
1.7.3. Using Environment Variables
1.8. FAQ
1.8.1. JSchException: Auth fail
   Next
   1. Spring Cloud Release Tools

\ No newline at end of file
diff --git a/single/spring-cloud-release-tools.html b/single/spring-cloud-release-tools.html
index 9bb53761..e932f984 100644
--- a/single/spring-cloud-release-tools.html
+++ b/single/spring-cloud-release-tools.html
@@ -1,8 +1,9 @@
 
       
-   Spring Cloud Release Tools
Spring Cloud Release Tools
Table of Contents
1. Spring Cloud Release Tools
1.1. What does it do?
1.2. What should I do first?
1.3. How to run it (interactive mode)
1.4. How to run it (automatic mode)
1.5. Project options
1.6. Examples
1.6.1. Keeping configuration in the project
1.6.2. Specifying A Branch
1.6.3. Using Environment Variables
1.7. FAQ
1.7.1. JSchException: Auth fail
1. Spring Cloud Release Tools
Spring Cloud projects reuse the same pattern of building and deploying the applications. That’s
-why this tool makes it easy to automate the release / dependency update process of our applications.
1.1 What does it do?
  • Clones the Spring Cloud Release project and picks all versions (Boot + Cloud projects)
  • Modifies the project versions with values from SC-Release
    • throws an exception when we bump versions to release and there’s a SNAPSHOT version referenced in the POM
  • Performs the build and checks if the docs modules have properly created the documentation
    • throws an exception when in the docs module there’s an unresolved tag in any HTML file
  • Commits changed poms (ONLY FOR NON-SNAPSHOT VERSIONS)
  • Creates a tag for the release / milestone (ONLY FOR NON-SNAPSHOT VERSIONS)
  • Runs the deployment of the artifacts
  • Publishes the docs (to spring-cloud-static for non-snapshots, to gh-pages for snapshots)
  • Reverts back to snapshots, bumps the version by a patch (1.0.1.RELEASE → 1.0.2.BUILD-SNAPSHOT) (ONLY FOR RELEASE VERSIONS)
  • Closes the milestone on Github (e.g. v1.0.1.RELEASE) (ONLY FOR NON-SNAPSHOT VERSIONS)
  • Generates an email template under target/email.txt (ONLY FOR NON-SNAPSHOT VERSIONS)
  • Generates a blog template under target/blog.md (ONLY FOR NON-SNAPSHOT VERSIONS)
  • Generates a tweet template under target/tweet.txt (ONLY FOR NON-SNAPSHOT VERSIONS)
  • Generates a release notes template under target/notes.md (ONLY FOR NON-SNAPSHOT VERSIONS)
  • Updates project information in Sagan (http://spring.io) (ONLY FOR SNAPSHOT / RELEASE VERSIONS)
  • For GA/ SR release will create an issue in Spring Guides under https://github.com/spring-guides/getting-started-guides/issues/
  • For GA/ SR release will update the links under https://github.com/spring-cloud/spring-cloud-static/tree/gh-pages/current
[Important]Important
Starting with version that does Sagan integration, you MUST pass the OAuth token,
-otherwise the application will fail to start
1.2 What should I do first?
Members of the Spring Cloud Team typically use this tool as follows. They first
+   Spring Cloud Release Tools
Spring Cloud Release Tools
Table of Contents
1. Spring Cloud Release Tools
1.1. What does it do?
1.1.1. Single project
1.1.2. Meta-release
1.2. What should I do first?
1.3. How to run it (interactive mode)
1.4. How to run it (automatic mode)
1.5. How to run meta-release (automatic-mode)
1.6. Project options
1.7. Examples
1.7.1. Keeping configuration in the project
1.7.2. Specifying A Branch
1.7.3. Using Environment Variables
1.8. FAQ
1.8.1. JSchException: Auth fail
1. Spring Cloud Release Tools
Spring Cloud projects reuse the same pattern of building and deploying the applications. That’s
+why this tool makes it easy to automate the release / dependency update process of our applications.
1.1 What does it do?
1.1.1 Single project
For a single project
  • Clones the Spring Cloud Release project and picks all versions (Boot + Cloud projects)
  • Modifies the project versions with values from SC-Release
    • throws an exception when we bump versions to release and there’s a SNAPSHOT version referenced in the POM
  • Performs the build and checks if the docs modules have properly created the documentation
    • throws an exception when in the docs module there’s an unresolved tag in any HTML file
  • Commits changed poms (ONLY FOR NON-SNAPSHOT VERSIONS)
  • Creates a tag for the release / milestone (ONLY FOR NON-SNAPSHOT VERSIONS)
  • Runs the deployment of the artifacts
  • Publishes the docs (to spring-cloud-static for non-snapshots, to gh-pages for snapshots)
  • Reverts back to snapshots, bumps the version by a patch (1.0.1.RELEASE → 1.0.2.BUILD-SNAPSHOT) (ONLY FOR RELEASE VERSIONS)
  • Closes the milestone on Github (e.g. v1.0.1.RELEASE) (ONLY FOR NON-SNAPSHOT VERSIONS)
[Important]Important
Starting with version that does Sagan integration, you MUST pass the OAuth token,
+otherwise the application will fail to start
After project release
1.1.2 Meta-release
  • Uses the fixed versions to clone and check out each project (e.g. spring-cloud-sleuth: 2.1.0.RELEASE)
  • From the version analyzes the branch and checks it out. E.g.
    • for spring-cloud-release’s `Finchley.RELEASE version will resolve either Finchley.x branch or will fallback to master if there’s no Finchley.x branch.
    • for spring-cloud-sleuth’s `2.1.0.RELEASE version will resolve 2.1.x branch
  • Performs the release tasks per each project
  • Performs the post release tasks at the end of the release
[Important]Important
For the meta-releaser to work we assume that the path to the
+custom configuration file for each project is always config/releaser.yml.
1.2 What should I do first?
Members of the Spring Cloud Team typically use this tool as follows. They first
 clone the releaser locally and build the jar manually
$ git clone git@github.com:spring-cloud/spring-cloud-release-tools.git
 $ cd spring-cloud-release-tools
 $ ./mvnw clean install
[Important]Important
You must set the value of the OAuth token. You can do it either via
@@ -101,8 +102,14 @@ $ java -jar ~/repo/spring-cloud-release-tools/spring-cloud-release-tools-spring/
 
$ java -jar ~/repo/spring-cloud-release-tools/spring-cloud-release-tools-spring/target/spring-cloud-release-tools-spring-1.0.0.BUILD-SNAPSHOT.jar --releaser.pom.branch=vDalston.SR1 --spring.config.name=releaser -r d-p -i=false

 
Running single task 'closeMilestone' (automatic). 
 
$ java -jar ~/repo/spring-cloud-release-tools/spring-cloud-release-tools-spring/target/spring-cloud-release-tools-spring-1.0.0.BUILD-SNAPSHOT.jar --releaser.pom.branch=vDalston.SR1 --spring.config.name=releaser --closeMilestone -i=false

-
1.5 Project options
  • releaser.fixed-versions - A String to String mapping of manually set versions. E.g. "spring-cloud-cli" → "1.0.0.RELEASE" will set
-the spring-cloud-cli.version to 1.0.0.RELEASE regardless of what was set in spring-cloud-release project. Example --releaser.fixed-versions[spring-cloud-cli]=1.0.0.RELEASE.
  • releaser.git.fetch-versions-from-git - If true then should fill the map of versions from Git. If false then picks fixed versions
  • releaser.git.clone-destination-dir - Where should the Spring Cloud Release repo get cloned to. If null defaults to a temporary directory
  • releaser.git.spring-cloud-release-git-url - URL to Spring Cloud Release Git repository. Defaults to https://github.com/spring-cloud/spring-cloud-release
  • releaser.git.documentation-url - URL to the documentation Git repository. Defaults to https://github.com/spring-cloud/spring-cloud-static
  • releaser.git.documentation-branch - Branch to check out for the documentation project. Defaults to gh-pages
  • releaser.git.oauth-token - GitHub OAuth token to be used to interact with GitHub repo.
  • releaser.git.username - Optional Git username. If not passed keys will be used for authentication.
  • releaser.git.password - Optional Git password. If not passed keys will be used for authentication.
  • releaser.git.number-of-checked-milestones - In order not to iterate endlessly over milestones we introduce a threshold of milestones that
+
1.5 How to run meta-release (automatic-mode)
All you have to do is run the jar with the releaser and pass the
+-x=true option to turn on meta-release and a list of fixed versions
+in the `--"releaser.fixed-versions[project-name]=project-version" format
$ java -jar spring-cloud-release-tools-spring/target/spring-cloud-release-tools-spring-1.0.0.BUILD-SNAPSHOT.jar --spring.config.name=releaser -x=true --"releaser.fixed-versions[spring-cloud-sleuth]=2.0.1.BUILD-SNAPSHOT"
[Important]Important
For the meta release the startFrom or taskNames take into consideration
+the project names, not task names. E.g. you can start from spring-cloud-netflix project,
+or build only tasks with names spring-cloud-build,spring-cloud-sleuth.
1.6 Project options
  • releaser.fixed-versions - A String to String mapping of manually set versions. E.g. "spring-cloud-cli" → "1.0.0.RELEASE" will set
+the spring-cloud-cli.version to 1.0.0.RELEASE regardless of what was set in spring-cloud-release project. Example --releaser.fixed-versions[spring-cloud-cli]=1.0.0.RELEASE.
+Use these properties to provide versions for the meta release.
  • releaser.meta-release.enabled - You have to turn it on to enable a meta release. Defaults to false
  • releaser.meta-release.release-train-project-name - Name of the project that represents the BOM of the release train. Defaults to spring-cloud-release
  • releaser.meta-release.git-org-url - The URL of the Git organization. We’ll append each project’s name to it.
+Defaults to https://github.com/spring-cloud
  • releaser.git.fetch-versions-from-git - If true then should fill the map of versions from Git. If false then picks fixed versions
  • releaser.git.clone-destination-dir - Where should the Spring Cloud Release repo get cloned to. If null defaults to a temporary directory
  • releaser.git.spring-cloud-release-git-url - URL to Spring Cloud Release Git repository. Defaults to https://github.com/spring-cloud/spring-cloud-release
  • releaser.git.documentation-url - URL to the documentation Git repository. Defaults to https://github.com/spring-cloud/spring-cloud-static
  • releaser.git.documentation-branch - Branch to check out for the documentation project. Defaults to gh-pages
  • releaser.git.oauth-token - GitHub OAuth token to be used to interact with GitHub repo.
  • releaser.git.username - Optional Git username. If not passed keys will be used for authentication.
  • releaser.git.password - Optional Git password. If not passed keys will be used for authentication.
  • releaser.git.number-of-checked-milestones - In order not to iterate endlessly over milestones we introduce a threshold of milestones that
 we will go through to find the matching milestone. Defaults to 10
  • releaser.maven.build-command - Command to be executed to build the project. Defaults to ./mvnw clean install -Pdocs
  • releaser.maven.deploy-command - Command to be executed to deploy a built project". Defaults to ./mvnw deploy -DskipTests -Pfast
  • releaser.maven.publish-docs-commands - Command to be executed to deploy a built project. If present {{version}} will be replaced by the proper version.
 Defaults to the standard Spring Cloud wget and execution of ghpages.
  • releaser.maven.system-properties - Additional system properties that should be passed to any commands. If present {{systemProps}} will be replaced by the contents of this property.
  • releaser.maven.wait-time-in-minutes - Max wait time in minutes for the process to finish. Defaults to 20
  • releaser.gradle.gradle-props-substitution - a map containing a key which is a property key inside gradle.properties and a value of
 a project name. E.g. in gradle.properties you have foo=1.0.0.BUILD-SNAPSHOT and you would like spring-cloud-contract version to
@@ -114,18 +121,19 @@ Example for application arguments: java -jar target/spring
  run a script (e.g. scripts/foo.sh) then inside foo.sh if you call a Maven build ./mvnw clean install
  then remember to pass all arguments of the script there too. E.g. ./mvnw clean install ${@}. That’s because
  the releaser will pass any system properties to the build / deploy command, such as system properties
- with keys and we need them to be passed inside the command executed by the releaser.
1.6 Examples
1.6.1 Keeping configuration in the project
If your project has some custom configuration (e.g. Spring Cloud Contract needs a script to be executed
+ with keys and we need them to be passed inside the command executed by the releaser.
1.7 Examples
1.7.1 Keeping configuration in the project
If your project has some custom configuration (e.g. Spring Cloud Contract needs a script to be executed
 to build the project and properly merge the docs) then you can put a file named e.g. releaser.yml under config
 folder and run your application like this:
$ wget http://repo.spring.io/libs-milestone/org/springframework/cloud/internal/spring-cloud-release-tools-spring/1.0.0.M1/spring-cloud-release-tools-spring-1.0.0.M1.jar -O ../spring-cloud-release-tools-spring-1.0.0.M1.jar
 $ java -jar target/spring-cloud-release-tools-spring-1.0.0.M1.jar --spring.config.name=releaser
[Tip]Tip
Notice that we’re downloading the jar to a parent folder, not to target. That’s because target get cleaned
-during the build process
1.6.2 Specifying A Branch
By deafult the releaser will default to using the master branch of spring-cloud-release.
-If you would like to use another branch you can specify it using the releaser.pom.branch property.
$ java -jar spring-cloud-release-tools-spring-1.0.0.M1.jar --releaser.pom.branch=Camden.SR6
1.6.3 Using Environment Variables
In some cases it might be easier to specify environment variables instead of passing parameters to
+during the build process
[Important]Important
For the meta-releaser to work we assume that the path to the
+configuration file is always config/releaser.yml.
1.7.2 Specifying A Branch
By deafult the releaser will default to using the master branch of spring-cloud-release.
+If you would like to use another branch you can specify it using the releaser.pom.branch property.
$ java -jar spring-cloud-release-tools-spring-1.0.0.M1.jar --releaser.pom.branch=Camden.SR6
1.7.3 Using Environment Variables
In some cases it might be easier to specify environment variables instead of passing parameters to
 releaser.  For example, you might want to use environment variables if you are going to be
 releasing multiple projects, this keeps you from having to specify the same parameters for
 each release
$ export RELEASER_POM_BRANCH=Dalston.RELEASE
 $ export RELEASER_GIT_OAUTH_TOKEN=...
 $ wget http://repo.spring.io/libs-milestone/org/springframework/cloud/internal/spring-cloud-release-tools-spring/1.0.0.M1/spring-cloud-release-tools-spring-1.0.0.M1.jar -O spring-cloud-release-tools-spring-1.0.0.M1.jar
-$ java -jar target/spring-cloud-release-tools-spring-1.0.0.M1.jar --releaser.working-dir=/path/to/project/root
1.7 FAQ
1.7.1 JSchException: Auth fail
I got such an exception
Caused by: org.eclipse.jgit.errors.TransportException: git@github.com:spring-cloud/spring-cloud-sleuth.git: Auth fail
+$ java -jar target/spring-cloud-release-tools-spring-1.0.0.M1.jar --releaser.working-dir=/path/to/project/root
1.8 FAQ
1.8.1 JSchException: Auth fail
I got such an exception
Caused by: org.eclipse.jgit.errors.TransportException: git@github.com:spring-cloud/spring-cloud-sleuth.git: Auth fail
 	at org.eclipse.jgit.transport.JschConfigSessionFactory.getSession(JschConfigSessionFactory.java:160) ~[org.eclipse.jgit-4.6.0.201612231935-r.jar!/:4.6.0.201612231935-r]
 	at org.eclipse.jgit.transport.SshTransport.getSession(SshTransport.java:137) ~[org.eclipse.jgit-4.6.0.201612231935-r.jar!/:4.6.0.201612231935-r]
 	at org.eclipse.jgit.transport.TransportGitSsh$SshPushConnection.<init>(TransportGitSsh.java:322) ~[org.eclipse.jgit-4.6.0.201612231935-r.jar!/:4.6.0.201612231935-r]
diff --git a/spring-cloud-release-tools.xml b/spring-cloud-release-tools.xml
index 496ca4c4..a6012817 100644
--- a/spring-cloud-release-tools.xml
+++ b/spring-cloud-release-tools.xml
@@ -4,7 +4,7 @@
 
 
 Spring Cloud Release Tools
-2018-06-15
+2018-06-25
 
 
 Spring Cloud Release Tools
@@ -12,6 +12,9 @@
 why this tool makes it easy to automate the release / dependency update process of our applications.
 

 What does it do?
+

+Single project
+For a single project
 
 
 Clones the Spring Cloud Release project and picks all versions (Boot + Cloud projects)
@@ -50,6 +53,13 @@ why this tool makes it easy to automate the release / dependency update process
 
 Closes the milestone on Github (e.g. v1.0.1.RELEASE) (ONLY FOR NON-SNAPSHOT VERSIONS)
 
+
+
+Starting with version that does Sagan integration, you MUST pass the OAuth token,
+otherwise the application will fail to start
+
+After project release
+
 
 Generates an email template under target/email.txt (ONLY FOR NON-SNAPSHOT VERSIONS)
 
@@ -72,11 +82,37 @@ why this tool makes it easy to automate the release / dependency update process
 For GA/ SR release will update the links under https://github.com/spring-cloud/spring-cloud-static/tree/gh-pages/current
 
 
+

+

+Meta-release
+
+
+Uses the fixed versions to clone and check out each project (e.g. spring-cloud-sleuth: 2.1.0.RELEASE)
+
+
+From the version analyzes the branch and checks it out. E.g.
+
+
+for spring-cloud-release’s `Finchley.RELEASE version will resolve either Finchley.x branch or will fallback to master if there’s no Finchley.x branch.
+
+
+for spring-cloud-sleuth’s `2.1.0.RELEASE version will resolve 2.1.x branch
+
+
+
+
+Performs the release tasks per each project
+
+
+Performs the post release tasks at the end of the release
+
+
 
-Starting with version that does Sagan integration, you MUST pass the OAuth token,
-otherwise the application will fail to start
+For the meta-releaser to work we assume that the path to the
+custom configuration file for each project is always config/releaser.yml.
 
 

+

 

 What should I do first?
 Members of the Spring Cloud Team typically use this tool as follows. They first
@@ -232,12 +268,35 @@ $ java -jar ~/repo/spring-cloud-release-tools/spring-cloud-release-tools-spring/
 
 
 

+

+How to run meta-release (automatic-mode)
+All you have to do is run the jar with the releaser and pass the
+-x=true option to turn on meta-release and a list of fixed versions
+in the `--"releaser.fixed-versions[project-name]=project-version" format
+$ java -jar spring-cloud-release-tools-spring/target/spring-cloud-release-tools-spring-1.0.0.BUILD-SNAPSHOT.jar --spring.config.name=releaser -x=true --"releaser.fixed-versions[spring-cloud-sleuth]=2.0.1.BUILD-SNAPSHOT"
+
+For the meta release the startFrom or taskNames take into consideration
+the project names, not task names. E.g. you can start from spring-cloud-netflix project,
+or build only tasks with names spring-cloud-build,spring-cloud-sleuth.
+
+

 

 Project options
 
 
 releaser.fixed-versions - A String to String mapping of manually set versions. E.g. "spring-cloud-cli" → "1.0.0.RELEASE" will set
-the spring-cloud-cli.version to 1.0.0.RELEASE regardless of what was set in spring-cloud-release project. Example --releaser.fixed-versions[spring-cloud-cli]=1.0.0.RELEASE.
+the spring-cloud-cli.version to 1.0.0.RELEASE regardless of what was set in spring-cloud-release project. Example --releaser.fixed-versions[spring-cloud-cli]=1.0.0.RELEASE.
+Use these properties to provide versions for the meta release.
+
+
+releaser.meta-release.enabled - You have to turn it on to enable a meta release. Defaults to false
+
+
+releaser.meta-release.release-train-project-name - Name of the project that represents the BOM of the release train. Defaults to spring-cloud-release
+
+
+releaser.meta-release.git-org-url - The URL of the Git organization. We’ll append each project’s name to it.
+Defaults to https://github.com/spring-cloud
 
 
 releaser.git.fetch-versions-from-git - If true then should fill the map of versions from Git. If false then picks fixed versions
@@ -326,6 +385,10 @@ $ java -jar target/spring-cloud-release-tools-spring-1.0.0.M1.jar --spring.confi
 Notice that we’re downloading the jar to a parent folder, not to target. That’s because target get cleaned
 during the build process
 
+
+For the meta-releaser to work we assume that the path to the
+configuration file is always config/releaser.yml.
+
 

 

 Specifying A Branch