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
@@ -144,9 +143,9 @@ One common stumbling block for teams adjusting to gitflow with Maven projects is
144
143
In practice, the Maven versions should:
145
144
146
145
* Be synchronized with release branch and hotfix branch names.
147
-
* Never be -SNAPSHOT in the master, support, release, or hotfix branches. Also, no -SNAPSHOT parent or (plugin) dependencies are allowed. (This condition may be disabled by setting `enforceNonSnapshots` = `false`.)
148
-
* Always be -SNAPSHOT in the feature and develop branches.
149
-
* Be irrelevant if there's no git branch resolvable from your environment.
146
+
* Never be -SNAPSHOT in the master, support, release, or hotfix branches. Also, no -SNAPSHOT parent or (plugin) dependencies are allowed.
147
+
* Always be -SNAPSHOT in the develop branch.
148
+
* Be irrelevant if there's no git branch resolvable from your environment or working in a branch which is not deployed to remote repositories.
150
149
151
150
The `enforce-versions` goal asserts these semantics when it can resolve the `gitBranchExpression`.
152
151
@@ -166,7 +165,6 @@ The following properties change the behavior of this goal:
166
165
| supportBranchPattern | (origin/)?support/(.*) | No | Regex. When matches, signals a support branch (long term master-equivalent for older release) being built. Last subgroup, if present, must be start of the Maven project version. |
167
166
| releaseBranchPattern | (origin/)?release/(.*) | No | Regex. When matched, signals a release branch being built. Last subgroup, if present, must match the Maven project version. |
168
167
| hotfixBranchPattern | (origin/)?hotfix/(.*) | No | Regex. When matched, signals a hotfix branch is being built. Last subgroup, if present, must match the Maven project version. |
169
-
| featureOrBugfixBranchPattern | (origin/)?(?:feature|bugfix)/(.*) | Yes | Regex. When matched, signals a feature or bugfix branch is being built. |
170
168
| developmentBranchPattern | (origin/)?develop | Yes | Regex. When matched, signals a development branch is being built. Note the lack of a subgroup. |
171
169
172
170
@@ -185,7 +183,6 @@ plugins in the build process (deploy, site-deploy, etc.) will use the repositori
185
183
| Property | Default Value | Description |
186
184
| -------- | ------------- | ----------- |
187
185
| gitBranchExpression | current git branch resolved from SCM or ${env.GIT_BRANCH} | Maven property expression to resolve in order to determine the current git branch |
188
-
| deploySnapshotTypeBranches |`false`| When `true`, feature branches will also be deployed to the snapshots repository. |
189
186
| releaseDeploymentRepository | n/a | The repository to use for releases. (Builds with a GIT_BRANCH matching `masterBranchPattern` or `supportBranchPattern`) |
190
187
| stageDeploymentRepository | n/a | The repository to use for staging. (Builds with a GIT_BRANCH matching `releaseBranchPattern` or `hotfixBranchPattern`) |
191
188
| snapshotDeploymentRepository | n/a | The repository to use for snapshots. (Builds matching `developmentBranchPattern`) |
@@ -339,7 +336,6 @@ The following table describes the git branch expression -> repository used for r
339
336
| supportBranchPattern | release |
340
337
| releaseBranchPattern | stage |
341
338
| hotfixBranchPattern | stage |
342
-
| featureOrBugfixBranchPattern | snapshots |
343
339
| developmentBranchPattern | snapshots |
344
340
| All Others | local |
345
341
@@ -361,15 +357,26 @@ it's building. The attach-deploy will 'clean' the maven project, then download t
361
357
that the first build deployed into. Once they're attached to the project, the `jboss-as:deploy-only` goal will deliver
362
358
the artifacts built by the first job into a jboss application server.
363
359
364
-
365
-
# Resolving the Git branch name
366
-
As stated before, the plugin determines what to do by resolving the Git branch name.
367
-
368
-
* The first try is a `git symbolic-ref HEAD` to check the local branch name. If it's found, that's the branch name that's used.
369
-
* If the `symbolic-ref` fails then it's probably due to a detached HEAD. This typically happens on Jenkins, when it simply checks out the commit hash that was just pushed.
370
-
Or, it's because of a developer doing a `git checkout origin/feature/x`, e.g. when doing a code review and no local branch is required.
371
-
In such a case:
372
-
* The plugin will first resolve the HEAD to a commit using `git rev-parse HEAD`.
373
-
* Next, it will do a `git show-ref` to check which (local/remote) branches point to the commit.
374
-
* If it can resolve the commit to a single branch type (e.g. develop or master) then that's the branch name that's used.
375
-
* If all of the above fails, `${env.GIT_BRANCH}` is tried.
360
+
# Additional Notes
361
+
## How Git branch name resolution works
362
+
1. If the `<scm>` sections of the pom points to a git repository, `git symbolic-ref HEAD` to is used to check the local branch name.
363
+
2. If the `symbolic-ref` fails then it's likely due to a detached HEAD.
364
+
This is typical of CI servers like Jenkins, where the commit hash that was just pushed is pulled.
365
+
This can also be done as a consequene of attempting to rebuild from a tag, without branching, or in some
366
+
workflows where code reviews are done without branches.
367
+
368
+
In the case of a detached HEAD the plugin will:
369
+
* Resolve the HEAD to a commit using `git rev-parse HEAD`.
370
+
*`git show-ref` to resolve which (local/remote) branches point to the commit.
371
+
* If the detached HEAD commit resolves to a single branch type, it uses that branch name.
372
+
3. If the first two methods fail, the plugin attempts to resolve `${env.GIT_BRANCH}`.
373
+
374
+
## Building with IntelliJ IDEA notes
375
+
### To Debug Tests:
376
+
Configure the Maven commandline to include
377
+
`-DforkMode=never` You will likely get warnings when you run maven without this argument.
378
+
379
+
### To inspect code-coverage results from Integration Tests:
380
+
* Select the **Analyze** -> **Show Coverage Data** menu.
381
+
* In the dialog that appears, click the **+** in the upper left corner to `Add (Insert)`, and browse to `target/jacoco.exec`.
382
+
* Selecting that file will show coverage data in the code editor.
0 commit comments