I have a list of patch in review on Gerrit (31 patches that follow each other), and would like to know how to pull them all at once on my local git.
I know it is possible to download a patch though the graphical interface:
Checkout: git fetch <url> refs/changes/78/141978/9 && git checkout FETCH_HEAD
Cherry Pick: git fetch <url> refs/changes/78/141978/9 && git cherry-pick FETCH_HEAD
Format Patch: git fetch <url> refs/changes/78/141978/9 && git format-patch -1 --stdout FETCH_HEAD
Pull git pull <url> refs/changes/78/141978/9
Patch-File 376aeb6.diff.base64 | 376aeb6.diff.zip
Archive tgz | tar | tbz2 | txz
I usually fetch the patch and cherry pick it using the command:
git fetch <url> refs/changes/78/141978/9 && git cherry-pick FETCH_HEAD
But I don't want to do this for all the patches I need.
You can use git cherry-pick to get a bench of consecutive patches.
git fetch <url> refs/changes/78/141978/9
git cherry-pick <first-patch-sha>^..<last-patch-sha>
The fetch command will download the patches from the remote repository and the cherry-pick command will apply the changes from <first-patch-sha> included to <last-patch-sha> included.
You can use the REST api and a Bash script:
changes=$(curl -s --request GET --user USER:PASS "https://GERRIT-SERVER/a/changes/?q=owner:self+AND+status:open&o=CURRENT_REVISION" | sed 1d | jq --raw-output ".[].revisions[].ref")
for c in $changes
do
echo ""
echo $c
echo ""
git fetch URL $c && git cherry-pick FETCH_HEAD
done
More info at Gerrit documentation here.
Related
I have the following pipeline syntax code in a Jenkinsfile to clone a git repo:
checkout([$class: 'GitSCM',
branches: [[name: "${branch}"]],
doGenerateSubmoduleConfigurations: false,
extensions: [[$class: 'SubmoduleOption',
disableSubmodules: false,
parentCredentials: false,
recursiveSubmodules: true,
reference: '',
trackingSubmodules: false],
[$class: 'LocalBranch',
localBranch: ""],
[$class: 'RelativeTargetDirectory',
relativeTargetDir: relative_dir]],
submoduleCfg: [],
userRemoteConfigs: [[credentialsId: cred_id,
url: git_url]]])
Following is the output of one instance of this Jenkins job, which reveals the git commands used to clone a repo:
> git init /home/user/workspace/CICD/PRJ/repo/PRJ/repo/121/src # timeout=10
Fetching upstream changes from ssh://git#bitbucket.company.com:7999/PRJ/repo.git
> git --version # timeout=10
using GIT_SSH to set credentials user - ssh username with private key.
> git fetch --tags --progress -- ssh://git#bitbucket.company.com:7999/PRJ/repo.git +refs/heads/*:refs/remotes/origin/* # timeout=10
> git config remote.origin.url ssh://git#bitbucket.company.com:7999/PRJ/repo.git # timeout=10
> git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
> git config remote.origin.url ssh://git#bitbucket.company.com:7999/PRJ/repo.git # timeout=10
Fetching upstream changes from ssh://git#bitbucket.company.com:7999/PRJ/repo.git
using GIT_SSH to set credentials user - ssh username with private key.
> git fetch --tags --progress -- ssh://git#bitbucket.company.com:7999/PRJ/repo.git +refs/heads/*:refs/remotes/origin/* # timeout=10
> git rev-parse refs/remotes/origin/feature/hcf^{commit} # timeout=10
> git rev-parse refs/remotes/origin/refs/heads/feature/hcf^{commit} # timeout=10
Checking out Revision 37b9492373951ab0b4c70fa64a3320be58133e0e (refs/remotes/origin/feature/hcf)
> git config core.sparsecheckout # timeout=10
> git checkout -f 37b9492373951ab0b4c70fa64a3320be58133e0e # timeout=10
> git branch -a -v --no-abbrev # timeout=10
> git checkout -b feature/hcf 37b9492373951ab0b4c70fa64a3320be58133e0e # timeout=10
Commit message: "Uncomment set_fault"
> git rev-list --no-walk 59ce67929be6c901975596db509de7a72b3c557a # timeout=10
This same Jenkinsfile automatically applies git tags using gitversion like so:
docker run -u $(id -u ${USER}):$(id -g ${USER}) --rm -v "$(pwd):/repo" artifactory.company.com/gittools/gitversion:5.7.1 /repo
The above methods of git cloning and using gitversion to generate new git tags has been working fine for several months without incident.
Problem:
Today, gitversion failed unexpectedly when this Jenkins job was run to build a git branch that I cannot see anything unique about (versus the many successfully-built branches).
The error, below, seems to indicate an inability to identify development or release branches, which are dev and master, respectively, in our case.
+ docker run -u 1172002866:1172000513 --rm -v /home/user/workspace/CICD/PRJ/repo/PRJ/repo/121/src:/repo artifactory.company.com/gittools/gitversion:5.7.1 /repo
INFO [01/26/22 23:30:14:02] Working directory: /repo
INFO [01/26/22 23:30:14:26] Project root is: /repo/
INFO [01/26/22 23:30:14:26] DotGit directory is: /repo/.git
INFO [01/26/22 23:30:14:59] Begin: Loading version variables from disk cache
INFO [01/26/22 23:30:14:59] Cache file /repo/.git/gitversion_cache/AF7963E4F79300A465EFC56DBA14B2B679307C08.yml not found.
INFO [01/26/22 23:30:14:59] End: Loading version variables from disk cache (Took: 1.50ms)
INFO [01/26/22 23:30:14:61] Using latest commit on specified branch
INFO [01/26/22 23:30:14:62] Begin: Attempting to inherit branch configuration from parent branch
INFO [01/26/22 23:30:14:65] Begin: Finding branch source of 'feature/hcf'
INFO [01/26/22 23:30:14:66] End: Finding branch source of 'feature/hcf' (Took: 15.87ms)
INFO [01/26/22 23:30:14:67] Begin: Getting branches containing the commit '37b9492'.
INFO [01/26/22 23:30:14:67] Trying to find direct branches.
INFO [01/26/22 23:30:14:67] No direct branches found, searching through all branches.
INFO [01/26/22 23:30:14:67] Searching for commits reachable from 'origin/dev'.
INFO [01/26/22 23:30:14:69] The branch 'origin/dev' has no matching commits.
INFO [01/26/22 23:30:14:69] Searching for commits reachable from 'origin/master'.
INFO [01/26/22 23:30:14:70] The branch 'origin/master' has no matching commits.
INFO [01/26/22 23:30:14:70] Searching for commits reachable from 'origin/release-npm2'.
INFO [01/26/22 23:30:14:70] The branch 'origin/release-npm2' has no matching commits.
INFO [01/26/22 23:30:14:70] Searching for commits reachable from 'origin/release-npm3'.
INFO [01/26/22 23:30:14:71] The branch 'origin/release-npm3' has no matching commits.
INFO [01/26/22 23:30:14:71] Searching for commits reachable from 'origin/release-5944.0'.
INFO [01/26/22 23:30:14:72] The branch 'origin/release-5944.0' has no matching commits.
INFO [01/26/22 23:30:14:72] Searching for commits reachable from 'origin/release-5944.1'.
INFO [01/26/22 23:30:14:73] The branch 'origin/release-5944.1' has no matching commits.
INFO [01/26/22 23:30:14:73] End: Getting branches containing the commit '37b9492'. (Took: 63.52ms)
INFO [01/26/22 23:30:14:73] Found possible parent branches:
INFO [01/26/22 23:30:14:74] End: Attempting to inherit branch configuration from parent branch (Took: 116.47ms)
ERROR [01/26/22 23:30:14:82] An unexpected error occurred:
System.InvalidOperationException: Gitversion could not determine which branch to treat as the development branch (default is 'develop') nor releaseable branch (default is 'main' or 'master'), either locally or remotely. Ensure the local clone and checkout match the requirements or considering using 'GitVersion Dynamic Repositories'
at GitVersion.Configuration.BranchConfigurationCalculator.InheritBranchConfiguration(IBranch targetBranch, BranchConfig branchConfiguration, ICommit currentCommit, Config configuration, IList`1 excludedInheritBranches) in D:\a\GitVersion\GitVersion\src\GitVersion.Core\Configuration\BranchConfigurationCalculator.cs:line 137
at GitVersion.Configuration.BranchConfigurationCalculator.GetBranchConfiguration(IBranch targetBranch, ICommit currentCommit, Config configuration, IList`1 excludedInheritBranches) in D:\a\GitVersion\GitVersion\src\GitVersion.Core\Configuration\BranchConfigurationCalculator.cs:line 47
at GitVersion.GitVersionContextFactory.Create(GitVersionOptions gitVersionOptions) in D:\a\GitVersion\GitVersion\src\GitVersion.Core\Core\GitVersionContextFactory.cs:line 40
at GitVersion.GitVersionCoreModule.<>c__DisplayClass0_0.<RegisterTypes>b__1() in D:\a\GitVersion\GitVersion\src\GitVersion.Core\GitVersionCoreModule.cs:line 38
at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode)
at System.Lazy`1.ExecutionAndPublication(LazyHelper executionAndPublication, Boolean useDefaultConstructor)
at System.Lazy`1.CreateValue()
at System.Lazy`1.get_Value()
at GitVersion.VersionCalculation.NextVersionCalculator.get_context() in D:\a\GitVersion\GitVersion\src\GitVersion.Core\VersionCalculation\NextVersionCalculator.cs:line 17
at GitVersion.VersionCalculation.NextVersionCalculator.FindVersion() in D:\a\GitVersion\GitVersion\src\GitVersion.Core\VersionCalculation\NextVersionCalculator.cs:line 32
at GitVersion.GitVersionCalculateTool.CalculateVersionVariables() in D:\a\GitVersion\GitVersion\src\GitVersion.Core\Core\GitVersionCalculateTool.cs:line 52
at GitVersion.GitVersionExecutor.RunGitVersionTool(GitVersionOptions gitVersionOptions) in D:\a\GitVersion\GitVersion\src\GitVersion.App\GitVersionExecutor.cs:line 70
INFO [01/26/22 23:30:14:82] Attempting to show the current git graph (please include in issue):
INFO [01/26/22 23:30:14:82] Showing max of 100 commits
INFO [01/26/22 23:30:14:93] * 37b9492 3 minutes ago (HEAD -> feature/hcf, origin/feature/hcf)
What I have tried:
When I manually clone the repo and check out the branch using the above git commands, I can reproduce the gitversion failure.
When I "simplify" my git clone and branch checkout to just:
$ git clone ssh://git#bitbucket.company.com:7999/PRJ/repo.git
$ git checkout feature/hcf
$ docker run -u $(id -u ${USER}):$(id -g ${USER}) --rm -v "$(pwd):/repo" artifactory.company.com/gittools/gitversion:5.7.1 /repo
...then gitversion succeeds and returns an expected value.
Questions:
Can the Jenkinsfile checkout() statement be modified so that it is functionally identical to the "simple" git clone and git checkout statements? There is obviously some salient difference between the two "methods" of cloning from git and checking out branches that is relevant to gitversion.
If possible, I would prefer a solution that uses the Jenkins pipeline checkout() function over a shell script invocation like sh(script:"git clone...") -- but perhaps an experienced answerer can convince me that that preference isn't justified.
Can someone explain how I can determine what is "unique" about this particular git repo or branch? With other repos/branches, the above checkout() statement in our Jenkinsfile continues to work simpatico with the subsequent gitversion invocation. So it would seem there is something unique about this one failing case that I don't know how to determine.
I don't use Jenkins myself, but it looks like the develop branch is missing from its clone of the repository, which may indicate that Jenkins is doing a sparse or shallow clone. As stated in GitVersion's requirements, it needs a full clone of the repository in order to do its calculations.
The reason your git clone && git checkout statements work is because, by default, Git performs a full clone of the repository. What you need to do is instruct Jenkins to do an unshallow clone of the repository. GitVersion's Jenkins documentation lists a number of things you can and should do to have GitVersion work properly:
Advanced clone behaviors
Enable Fetch tags
Enable Honor refspec on intial clone
Check out to matching local branch
Prune stale remote-tracking branches
Specify ref specs
Ref Spec: +refs/heads/*:refs/remotes/#{remote}/*
With the above Jenkins settings tuned correctly, it should work.
I have been running into an issue where most, but not all, of the jenkins jobs to build our branches are failing, when connecting by proxy, with:
> git fetch --tags --progress https://github.com/myorg/myrepo.git
> +refs/heads/*:refs/remotes/origin/* # timeout=60
> ERROR: Error cloning remote repo 'origin'
> hudson.plugins.git.GitException: Command "git fetch --tags --progress >
> https://github.com/myorg/myrepo.git +refs/heads/*:refs/remotes/origin/*" >
> returned status code 128:
> stdout:
> stderr: error: RPC failed; result=18, HTTP code = 200
> fatal: The remote end hung up unexpectedly
The Jenkins script that I have, started like so:
stage ( "Checkout" ) {
sh label: "Use proxy to access GitHub", script:
"""
git config --global http.proxy ${httpProxy}
"""
scmVars = checkout scm
... ^^ this call wraps the failing `git fetch --tags --progress` call
Reading various other stack articles (git bash: error: RPC failed; result = 18, HTP code = 200B | 1KiB/s Git clone return result=18 code=200 on a specific repository etc), the only thing I have found of note is to increase the postBuffer size. ie. git config --global http.postBuffer 524288000 # 500mb
This then looks like:
stage ( "Checkout" ) {
sh label: "Use proxy to access GitHub", script:
"""
git config --global http.postBuffer 524288000
git config --global http.proxy ${httpProxy}
"""
scmVars = checkout scm
...
This has no net effect. ~90%+ of the builds fail on fetch; ~10% will go through (independent of the branch being built).
This is where affairs become very hard to explain: after hours of banging my head against the wall, I eventually decided to invoke checkout scm twice, consecutively; first I call scm checkout in a try/catch. The second call, I assign scmVars. (nb. if the first call succeeds, the second is idempotent). This looks like:
stage ( "Checkout" ) {
sh label: "Use proxy to access GitHub", script:
"""
git config --global http.postBuffer 524288000
git config --global http.proxy ${httpProxy}
"""
try {
checkout scm
} catch (nil) {
println "Initial SCM CHECKOUT fails"
}
scmVars = checkout scm
Calling checkout scm twice, catching an error on the first call, succeeds every time, in over 50 runs.
Why?
Is git config --global http.postBuffer 524288000 being applied to both calls or only the second?
If http.postBuffer is only set on the second call, how do I correctly set the property for the first call?
In broad strokes, what is actually happening here?
long-time listener, first-time caller; I am not a dev-ops engineer, I just play one on T.V. - thank you in advance for any and all insights
I have been using Jenkins for a few days, and before: I used the GITEA plugin
Now that I have switched my projects to GitBucket, I would like to use the "Build by Webhook" Feature.
I followed many tutorials, and now : i'm stuck on a simple/big problem.
In advance, I'm sorry to have to blur the sensitive links, I know it can be annoying.
Here is the full error :
using credential 10
Wiping out workspace first.
Contributing variables:
Cloning the remote Git repository
Cloning repository https://MY_GITBUCKET/git/MY_USERNAME/MY_PROJECT
> git init /Jenkins/workspace/GitBUcket # timeout=10
Fetching upstream changes from https://MY_GITBUCKET/git/MY_USERNAME/MY_PROJECT
> git --version # timeout=10
> git --version # 'git version 2.20.1'
using GIT_ASKPASS to set credentials Utilisateur GitBucket Perso
> git fetch --tags --force --progress -- https://MY_GITBUCKET/git/MY_USERNAME/MY_PROJECT +refs/heads/*:refs/remotes/origin/* # timeout=10
> git config remote.origin.url https://MY_GITBUCKET/git/MY_USERNAME/MY_PROJECT # timeout=10
> git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10
Avoid second fetch
Seen 0 remote branches
> git show-ref --tags -d # timeout=10
ERROR: Couldn't find any revision to build. Verify the repository and branch configuration for this job.
Finished: FAILURE
Here is my configuration on Jenkins : https://i.stack.imgur.com/jdlTt.png
Thank you very much in advance
EDIT : My only branche is master --> https://i.imgur.com/lXJ0xyN.png
This is what you can try:
Manage Jenkins -> Global Tool Configuration -> Git
Check if Path to Git executable is set: C:\PATH\git.exe
Dashboard -> select your job -> Configure -> Source Code Management -> select Git
Insert your Repository URL and Credentials(Optional) then under Branches to build change */master to */main.
I put "make" in Jenkins's Execute Shell, following the tutorial here https://github.com/jbankes/Hello_Jenkins, but Jenkins does not run the make from the underlying Github repository, as shown in the error message below.
What is the right way to demand Jenkins to run "make" from its monitored GitHub repository?
Running as SYSTEM
Building in workspace /var/jenkins_home/workspace/test003
The recommended git tool is: NONE
No credentials specified
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url https://github.com/zhoulaifu/Hello_Jenkins # timeout=10
Fetching upstream changes from https://github.com/zhoulaifu/Hello_Jenkins
> git --version # timeout=10
> git --version # 'git version 2.20.1'
> git fetch --tags --force --progress -- https://github.com/zhoulaifu/Hello_Jenkins +refs/heads/*:refs/remotes/origin/* # timeout=10
> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
Checking out Revision bc3931a313e4f3945c257ae3247e63265b1debb7 (refs/remotes/origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f bc3931a313e4f3945c257ae3247e63265b1debb7 # timeout=10
Commit message: "Otherside (#5)"
> git rev-list --no-walk bc3931a313e4f3945c257ae3247e63265b1debb7 # timeout=10
[test003] $ /bin/sh -xe /tmp/jenkins2704537311990415428.sh
+ make
make: *** No targets specified and no makefile found. Stop.
Build step 'Execute shell' marked build as failure
Finished: FAILURE
In the repository Make file located inside original folder. So to be able to run Make you need navigate to it.
After git clone execute cd original/ and then run Make.
I have jenkins job for with GitHub Pull Request Builder.
In build, I added first step to set the JIRA_ISSUE variable.
JIRA: Add related environment variables to build
Extracts JIRA information for the build to environment variables.
Available variables:
JIRA_ISSUES - A comma separated list of issues which are referenced in the version control system changelog
JIRA_URL - Primary URL for the JIRA server
Typical usage:
Add this build step
Use the "Progress JIRA issues by workflow action" or "Move issues matching JQL to the specified version" with JQL like:
issue in (${JIRA_ISSUES})
Second step is to update these jira issues.
<builders>
<hudson.plugins.jira.JiraEnvironmentVariableBuilder plugin="jira#3.0.0"/>
<hudson.plugins.jira.JiraIssueUpdateBuilder plugin="jira#3.0.0">
<jqlSearch>issue in (${JIRA_ISSUES})</jqlSearch>
<workflowActionName>Ready for Review</workflowActionName>
<comment>add comment</comment>
</hudson.plugins.jira.JiraIssueUpdateBuilder>
</builders>
When I create PR, and it trigger the job, it not set JIRA_ISSUES
GitHub pull request #356 of commit 2e2b92d107a5460c4cc593fcab78c63f800d6472, no merge conflicts.
Setting status of 2e2b92d107a5460c4cc593fcab78c63f800d6472 to PENDING with url https://myjenkins.com/job/cicd-myjob-prtest-unittest/69/ and message: 'running tox...'
Using context: tox testing
[EnvInject] - Loading node environment variables.
Building remotely on myslave.node.box.com (linux) in workspace /var/lib/jenkins/workspace/cicd-myjob-prtest-unittest
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url https://mygithub.com/myuser/myproject.git # timeout=10
Fetching upstream changes from https://mygithub.com/myuser/myproject.git
> git --version # timeout=10
using GIT_ASKPASS to set credentials Github Service Account Username with token
> git fetch --tags --progress https://mygithub.com/myuser/myproject.git +refs/pull/*:refs/remotes/origin/pr/*
> git rev-parse refs/remotes/origin/pr/356/merge^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/pr/356/merge^{commit} # timeout=10
Checking out Revision 0ff9e43bbc1385303429f7bcf93fea36e8c455d3 (refs/remotes/origin/pr/356/merge)
> git config core.sparsecheckout # timeout=10
> git checkout -f 0ff9e43bbc1385303429f7bcf93fea36e8c455d3
Commit message: "Merge 2e2b92d107a5460c4cc593fcab78c63f800d6472 into 731994024e723b1257374f521b4784060df9e5b5"
First time build. Skipping changelog.
[JIRA] Setting JIRA_ISSUES to .
[JIRA] Updating issues using workflow action Ready for Review.
[JIRA] JQL: issue in ()
[JIRA] Updating issue MYPROJECT-1234
Setting status of 2e2b92d107a5460c4cc593fcab78c63f800d6472 to SUCCESS with url https://myjenkins.com/job/cicd-myjob-prtest-unittest/69/ and message: 'All is well.
'
Using context: tox testing
Finished: SUCCESS
The [JIRA] Updating issue MYPROJECT-1234 is from publisher
<publishers>
<hudson.plugins.jira.JiraIssueUpdater plugin="jira#3.0.0">
<issueSelector class="hudson.plugins.jira.selector.JqlIssueSelector">
<jql>issue=MYPROJECT-1234</jql>
</issueSelector>
<labels/>
</hudson.plugins.jira.JiraIssueUpdater>
</publishers>
If I look for change log for commit 2e2b92d107a5460c4cc593fcab78c63f800d6472 it has the jira issue in comment and title.
commit 2e2b92d107a5460c4cc593fcab78c63f800d6472 (HEAD -> MYPROJECT-1234, origin/MYPROJECT-1234)
Author: myuser <myuser#mygithub.com>
Date: Tue Aug 21 15:55:41 2018 -0500
MYPROJECT-1234: Tox testing
MYPROJECT-1234 change the data.
Why JiraEnvironmentVariableBuilder is not able to set JIRA_ISSUES to MYPROJECT-1234? while same exists in changelog.