This is a GoCD SCM plugin for Git feature branch support. Discussion Thread
Supported (as seperate plugins):
- Git repository for branches
- Github repository for Pull Requests
- Stash repository for Pull Requests
- Gerrit repository for Change Sets
- Bitbucket repository for Pull Requests
Addition of the white and blacklist feature to Git Feature Branch plugin changes the identity of the SCM material. This means that it may trigger automatically triggered pipelines that use Git Feature Branch material. When moving from version 1.2.x to 1.3.x be sure to pause all pipelines which shouldn't be triggered or be ready to cancel them in case they are triggered.
These plugins require GoCD version v15.x or above.
Installation:
- Download the latest plugin jar from the Releases section. Place it in
<go-server-location>/plugins/external
& restart Go Server. You can find the location of the Go Server installation here.
Usage:
-
Make sure plugins are loaded. Note: You can use GoCD build status notifier to update status of Pull Requests with build status.
-
Assuming you already have a pipeline "ProjectA" for one of your repos
-
'Extract Template' from the pipeline, if its not templatized already (this is optional step)
-
Create new pipeline say "ProjectA-FeatureBranch" off of the extracted template. You can clone "ProjectA" pipeline to achieve this.
-
In the materials configuration for your newly created pipeline, you will see that there is a new material for each of the plugins you have installed (Git Feature Branch, Github, Stash or Gerrit). Select one of these new materials, fill in the details and the plugin will build the pull requests from the given material.
-
You can delete the old material that is left over from cloning your pipeline.
-
First run of the new pipeline will be off of 'master' branch. This creates base PR-Revision map. It also serves as sanity check for newly created pipeline.
-
From then on, any new change (new PR create / new commits to existing PR) will trigger the new pipeline. Only the top commit in the PR will show up in build cause.
-
PR details (id, author etc.) will be available as environement variable for tasks to consume.
-
Build status notifier plugin will update Pull Request with build status
Authentication:
- You can create a file
~/.github
with the following contents: (Note:~/.github
needs to be available on Go Server and on all Go Agent machines)
login=johndoe
password=thisaintapassword
- You can also generate & use oauth token. To do so create a file
~/.github
with the following contents: (Note:~/.github
needs to be available on Go Server and on all Go Agent machines)
login=johndoe
oauth=thisaintatoken
Github Enterprise:
- If you intend to use this plugin with 'Github Enterprise' then add the following content in
~/.github
(Note:~/.github
needs to be available on Go Server and on all Go Agent machines)
# for enterprise installations - Make sure to add /api/v3 to the hostname
# ignore this field or have the value to https://api.github.com
endpoint=http://code.yourcompany.com/api/v3
Authentication
If authentication is required, place a file named .netrc
under the Go user's home directory. The file needs to be created in both the server and any number of agents that will build this material. You can find the home directory for Go server here and for Go Agent
here.
The .netrc
file takes the following format:
machine stash.vm.com
login myusername
password mypassword
Git feature branches support filtering the branches with whitelist and blacklist.
Both lists support glob syntax (*
, ?
, [...]
, {...}
) and multiple branch patterns
can be given as a comma separated list. The glob syntax is same as
defined in Java's FileSystem.getPathMatcher()
method. If neither blacklist or whitelist pattern is defined, all branches will be built.
The blacklist takes precedence over whitelist. I.e. a branch will not be built if the blacklist pattern matches to the branch name.
- Clean up the code esp. the JSON SerDe part
- Add proper tests around the plugin
- If more than 1 PR gets updated (create/update) Go bunches them together for the next pipeline run & uses the top change in the "build-cause" to build. You can force trigger pipeline with other revisions until this get fixed (thread).