Integration with gerrit, the code review tool for git, would be much easier with a plugin that polled using gerrit's ssh-based api. Could you consider adding support for this tool with a repository plugin and perhaps a new step type that votes a gerrit patch up or down?
Description
Integration with gerrit, the code review tool for git, would be much easier with a plugin that polled using gerrit's ssh-based api. Could you consider adding support for this tool with a repository plugin and perhaps a new step type that votes a gerrit patch up or down?
We are receiving a lot of pressure from a small but vocal development group to switch to Jenkins for the Gerrit support. I know that with SVN+ReviewBoard there is an architectural conflict in that QB expects SCM Changes to either be committed already _or_ to be uncommitted changes from a User Agent in a proof build. With Gerrit the change sets _are_ already committed to a special ref that can be queried via the API (REST I believe). Gerrit is an official component of the Eclipse CBI and OpenStack, and is part of the official Android build stack. I think it's safe to say that official support for Gerrit as a Repository type would be a really safe investment, given that you already support Git, Repo, and GitHub.
For example the 1st submitted patch for changeset #5 has refspec (not sure of how to determine the format but I believe it's documented, at least in the API docs).
refs/changes/05/5/1
The Gerrit web front-end displays 4 different commands to get the change set
Justin Georgeson[26/Jun/14 10:01 PM]
We are receiving a lot of pressure from a small but vocal development group to switch to Jenkins for the Gerrit support. I know that with SVN+ReviewBoard there is an architectural conflict in that QB expects SCM Changes to either be committed already _or_ to be uncommitted changes from a User Agent in a proof build. With Gerrit the change sets _are_ already committed to a special ref that can be queried via the API (REST I believe). Gerrit is an official component of the Eclipse CBI and OpenStack, and is part of the official Android build stack. I think it's safe to say that official support for Gerrit as a Repository type would be a really safe investment, given that you already support Git, Repo, and GitHub.
For example the 1st submitted patch for changeset #5 has refspec (not sure of how to determine the format but I believe it's documented, at least in the API docs).
refs/changes/05/5/1
The Gerrit web front-end displays 4 different commands to get the change set
git fetch http://gerrit.example.com:8080/tycho-template refs/changes/05/5/1 && git checkout FETCH_HEAD
git fetch http://gerrit.example.com:8080/tycho-template refs/changes/05/5/1 && git cherry-pick FETCH_HEAD
git fetch http://gerrit.example.com:8080/tycho-template refs/changes/05/5/1 && git format-patch -1 --stdout FETCH_HEAD
git pull http://gerrit.example.com:8080/tycho-template refs/changes/05/5/1
So I assume that the API provides all the same relevant details. The Jenkins plugin seems to run these commands
> /opt/git-1.9.1/bin/git rev-parse --is-inside-work-tree
> /opt/git-1.9.1/bin/git config remote.origin.url http://gerrit.example.com:8080/tycho-template/
> /opt/git-1.9.1/bin/git --version
> /opt/git-1.9.1/bin/git config --local credential.helper store --file=/tmp/git7718945787932401579.credentials
> /opt/git-1.9.1/bin/git fetch --tags --progress http://gerrit.example.com:8080/tycho-template/ refs/changes/05/5/1
> /opt/git-1.9.1/bin/git config --local --remove-section credential
> /opt/git-1.9.1/bin/git rev-parse 75da4d2db0842c3cf96f1df4d0b0914ccebba54e^{commit}
> /opt/git-1.9.1/bin/git config core.sparsecheckout
> /opt/git-1.9.1/bin/git checkout -f 75da4d2db0842c3cf96f1df4d0b0914ccebba54e
> /opt/git-1.9.1/bin/git rev-parse FETCH_HEAD^{commit}
> /opt/git-1.9.1/bin/git rev-list b8032e2e37c1ed80f84eefbb6df4775bcf9f18d7
For example the 1st submitted patch for changeset #5 has refspec (not sure of how to determine the format but I believe it's documented, at least in the API docs).
refs/changes/05/5/1
The Gerrit web front-end displays 4 different commands to get the change set
git fetch http://gerrit.example.com:8080/tycho-template refs/changes/05/5/1 && git checkout FETCH_HEAD
git fetch http://gerrit.example.com:8080/tycho-template refs/changes/05/5/1 && git cherry-pick FETCH_HEAD
git fetch http://gerrit.example.com:8080/tycho-template refs/changes/05/5/1 && git format-patch -1 --stdout FETCH_HEAD
git pull http://gerrit.example.com:8080/tycho-template refs/changes/05/5/1
So I assume that the API provides all the same relevant details. The Jenkins plugin seems to run these commands
> /opt/git-1.9.1/bin/git rev-parse --is-inside-work-tree
> /opt/git-1.9.1/bin/git config remote.origin.url http://gerrit.example.com:8080/tycho-template/
> /opt/git-1.9.1/bin/git --version
> /opt/git-1.9.1/bin/git config --local credential.helper store --file=/tmp/git7718945787932401579.credentials
> /opt/git-1.9.1/bin/git fetch --tags --progress http://gerrit.example.com:8080/tycho-template/ refs/changes/05/5/1
> /opt/git-1.9.1/bin/git config --local --remove-section credential
> /opt/git-1.9.1/bin/git rev-parse 75da4d2db0842c3cf96f1df4d0b0914ccebba54e^{commit}
> /opt/git-1.9.1/bin/git config core.sparsecheckout
> /opt/git-1.9.1/bin/git checkout -f 75da4d2db0842c3cf96f1df4d0b0914ccebba54e
> /opt/git-1.9.1/bin/git rev-parse FETCH_HEAD^{commit}
> /opt/git-1.9.1/bin/git rev-list b8032e2e37c1ed80f84eefbb6df4775bcf9f18d7