You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+27-15Lines changed: 27 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -10,6 +10,7 @@ It does so by:
10
10
* SCM tagging builds for master and support branches. You can use the project SCM definition, or if you omit it, you can resolve the CI server's repository connection information. (Zero Maven scm configuration necessary)
11
11
* Promoting existing tested (staged) artifacts for release, rather than re-building the artifacts. Eliminates the risk of accidental master merges or commits resulting in untested code being released, and provides digest hash traceability for the history of artifacts.
12
12
* Enabling the decoupling of repository deployment and execution environment delivery based on the current git branch.
13
+
* Allowing for long-running non-release branches to be deployed to snapshots, automatically reversioning the artifacts based off the branch name.
13
14
* Automated deployment, promotion, and delivery of projects without the [maven-release-plugin](http://maven.apache.org/maven-release/maven-release-plugin/) or some other [*almost there* solution](https://axelfontaine.com/blog/final-nail.html).
14
15
* Customizing maven project and system properties based upon the current branch being built. This allows test cases to target different execution environments without changing the artifact results.
15
16
* Enabling automatic purging and resolving (force update) of 'release' and 'hotfix' release versioned dependencies resolved from the 'stage' repository.
@@ -24,6 +25,7 @@ This plugin solves a few specific issues common in consolidated Hudson/Jenkins C
24
25
4. Set arbitrary project properties based upon the type of GIT branch being built.
25
26
5. Reliably tag deploy builds from the master and support branches
26
27
6. Enable split 'deploy' vs. 'deliver' maven CI job configuration, without rebuilding artifacts for the 'deliver' phase.
28
+
7. Allow for deployment of long-running feature branches to repositories without having to mangle the version in the pom.xml.
27
29
28
30
In addition to supporting these goals for the project, this plugin does it in a manner that tries to be as effortless (yet configurable) as possible.
29
31
If you use non-standard gitflow branch names (emer instead of hotfix), this plugin supports that. If you don't want to do version enforcement, this plugin supports that.
@@ -107,14 +109,16 @@ All of the solutions to these issues are implemented independently in different
@@ -167,6 +171,19 @@ The following properties change the behavior of this goal:
167
171
| hotfixBranchPattern | (origin/)?hotfix/(.*) | No | Regex. When matched, signals a hotfix branch is being built. Last subgroup, if present, must match the Maven project version. |
168
172
| developmentBranchPattern | (origin/)?develop | Yes | Regex. When matched, signals a development branch is being built. Note the lack of a subgroup. |
169
173
174
+
## Goal: `set-properties` (Dynamically Set Maven Project / System Properties)
175
+
176
+
Some situations with automated testing (and integration testing in particular) demand changing configuration properties
177
+
based upon the branch type being built. This is a common necessity when configuring automated DB refactorings as part of
178
+
a build, or needing to setup / configure datasources for automated tests to run against.
179
+
180
+
The `set-properties` goal allows for setting project (or system) properties, dynamically based on the detected git
181
+
branch being built. Properties can be specified as a Properties collection in plugin configuration, or can be loaded
182
+
from a property file during the build. Both property key names and property values will have placeholders resolved.
183
+
184
+
Multiple executions can be configured, and each execution can target different scopes (system or project), and can load
185
+
properties from files with an assigned keyPrefix, letting you name-space properties from execution ids.
186
+
170
187
171
188
## Goal: `retarget-deploy` (Branch Specific Deploy Targets & Staging)
172
189
@@ -186,7 +203,7 @@ plugins in the build process (deploy, site-deploy, etc.) will use the repositori
186
203
| releaseDeploymentRepository | n/a | The repository to use for releases. (Builds with a GIT_BRANCH matching `masterBranchPattern` or `supportBranchPattern`) |
187
204
| stageDeploymentRepository | n/a | The repository to use for staging. (Builds with a GIT_BRANCH matching `releaseBranchPattern` or `hotfixBranchPattern`) |
188
205
| snapshotDeploymentRepository | n/a | The repository to use for snapshots. (Builds matching `developmentBranchPattern`) |
189
-
206
+
| otherDeploymentBranchPattern | false | N/A | Regex. When matched, the branch name is normalized and any artifacts produced by the build will include the normalized branch name and -SNAPSHOT. Deployment will target the snapshot repository|
190
207
191
208
**The repository properties should follow the following format**, `id::layout::url::uniqueVersion`.
192
209
@@ -235,20 +252,15 @@ Can be replaced with the following plugin configuration, which also introduces t
235
252
...
236
253
</build>
237
254
255
+
### Deploying non-release (OTHER) type branches as -SNAPSHOT releases.
238
256
239
-
## Goal: `set-properties` (Dynamically Set Maven Project / System Properties)
240
-
241
-
Some situations with automated testing (and integration testing in particular) demand changing configuration properties
242
-
based upon the branch type being built. This is a common necessity when configuring automated DB refactorings as part of
243
-
a build, or needing to setup / configure datasources for automated tests to run against.
244
-
245
-
The `set-properties` goal allows for setting project (or system) properties, dynamically based on the detected git
246
-
branch being built. Properties can be specified as a Properties collection in plugin configuration, or can be loaded
247
-
from a property file during the build. Both property key names and property values will have placeholders resolved.
248
-
249
-
Multiple executions can be configured, and each execution can target different scopes (system or project), and can load
250
-
properties from files with an assigned keyPrefix, letting you name-space properties from execution ids.
251
-
257
+
In addition to setting up repository targets for release branches, the `retarget-depoy` branch can deploy other branches
258
+
matching the `otherDeploymentBranchPattern` as -SNAPSHOT artifacts which include the branch name as build metadata.
259
+
This is loosely based on the [semVer](https://semver.org) semantic version scheme, in that the plugin will reversion any
260
+
artifacts to be produced with `+feature-branch-name-normalized-SNAPSHOT` where any characters not in `[0-9A-Za-z-.]` will
261
+
be replaced with `-`. Artifact versions for feature branches will _always_ be -SNAPSHOT, and will _always_ target the
262
+
Snapshots repository. The intent for this configuration setting is to provide a way for long-running branches (matching
263
+
a naming convention you define) can be published to a SNAPSHOT repo for use by other projects.
252
264
253
265
## Goal: `update-stage-dependencies` (Force update of dependency staged Releases)
// Other branches never target release, but may target stage for non-SNAPSHOT artifacts.
39
40
// For this reason, "overwrite" is considered _highly_ dangerous.
40
-
if (!"false".equalsIgnoreCase(forceOtherDeploy)) {
41
-
// Setup the target based on the base project version.
42
-
if (ArtifactUtils.isSnapshot(project.getVersion())) {
43
-
setTargetSnapshots();
44
-
} else {
45
-
setTargetStage();
46
-
}
47
-
48
-
// Monkey with things to do our semVer magic.
49
-
if ("semVer".equalsIgnoreCase(forceOtherDeploy)) {
50
-
if (ArtifactUtils.isSnapshot(project.getVersion())) {
51
-
getLog().warn("Maven -SNAPSHOT builds break semVer standards, in that -SNAPSHOT must be the _last_ poriton of a maven version. In semVer, the pre-release status is supposed to come before the build meta-data.");
52
-
getLog().info("The gitflow-helper-maven-plugin will inject the build metadata preceding the -SNAPSHOT, allowing for snapshot deployments of this branch.");
0 commit comments