On Wed, Dec 2, 2020 at 12:56 AM <unlimh...@gmail.com> wrote:
> Thanks for your reply.
> Temporarily, I have to roll back to the old, but working successfully
> solution with git:
>
> git(
> url: 'https://github.com/enterpr/myrepo.git',
> credentialsId: 'github-PAT',
> branch: "${params.branch_name}"
> )
>
> But I would like to solve my problem with checkout and incorrect revisions
> on each run.
> Here is the full code with checkout, which randomly gives different
> revisions:
>
> checkout ([
> $class: 'GitSCM',
> branches: [[name: '"*/"${params.branch_name}']],
> doGenerateSubmoduleConfigurations: 'false',
> extensions: [[$class: 'CheckoutOption', timeout: 180],[$class:
> 'CloneOption', depth: 1, noTags: true, reference: '', shallow: true,
> timeout: 60]],
> submoduleCfg: [],
> userRemoteConfigs: [[url: 'https://github.com/enterpr/myrepo.git',
> credentialsId: 'github-PAT']]])
>
> {Params. branch_name} always has the same value - branch 'dev'
>
>
Try this instead:
checkout ([
$class: 'GitSCM',
branches: [[name: params.branch_name]],
extensions: [[$class: 'CheckoutOption', timeout: 180],[$class:
'CloneOption', depth: 1, noTags: true, reference: '', shallow: true,
timeout: 60]],
userRemoteConfigs: [[url: 'https://github.com/enterpr/myrepo.git',
credentialsId: 'github-PAT']]])
Since you're cloning from a single repository, you don't need the leading
'*/' to precede the branch name.
Since you want to use the value of params.branch_name you don't need to
embed that in single quotes.
Since you're using the default values for doGenerateSubmoduleConfigurations
and submoduleCfg , you don't need to specify them.
If your checkout only requires one branch, then you can reduce the work on
the remote server and the disc space on the agent by using the "honor
refspec on initial clone" along with a specifically defined refspec that
uses only the specific branch. Examples of intentionally narrowed refspecs
are available in several places, including this repository
<https://github.com/MarkEWaite/jenkins-bugs/blob/a46c9378000f0880588e8af88cff18a04278da73/Jenkinsfile#L20>
.
> >However, you didn't tell us if this is a Pipeline job with the script
> inside the job, a Pipeline job that is getting the script from SCM...
> My pipeline is loaded from SCM (github) as a script code (Pipeline)
> (enabling or disabling Lightweight checkout in the pipeline settings does
> not affect issue with different revisions).
>
> > When you say "restart the same pipeline", do you mean that you press
> the "Replay" button for the pipeline?
> Any launch "Build with parameters" or "Restart from stage", because in
> each stage I have code with "checkout" call.
>
> >Is there something special about the local file system that causes you to
> set the checkout timeout (a local file system operation) to allow more time
> that the clone timeout (which is a network operation)?
> If You mean the set values of [timeout: 180 & timeout: 60] in my code,
> then these parameters were added intentionally, because earlier when using
> git, where this default value is [timeout: 10], there were regular problems
> when loading my large repository.
>
>
Yes, those are exactly what I mean. If you're using a git repository that
is large enough to exceed the default 10 minute timeout when cloning the
repository, you probably should review the "Git in the Large
<https://youtu.be/jBGFjFc6Jf8?t=6434>" video segment that will point you to
the things you can do on Jenkins agents to significantly reduce the time
and the disc space cost of large repositories. The key items (in priority
order) are:
1. Reference repository on the agent in a known location (almost always
effective at reducing data transfer and data storage on agents)
2. Narrow refspec for the job and honor refspec on initial clone
(effective for repositories with many branches that have largely
independent branches, less effective for large repositories with
interdependent branches0
3. Shallow clone (not nearly as effective as I'd hoped)
Your current settings allow up to 60 minutes to pull the repository data
from the remote git server, then allow up to 180 minutes to perform the
local checkout on the agent file system. That is a surprising combination
of values. Access to the agent file system is usually significantly faster
than access to the remote git repository. If that is not the case in your
installation, then you may need to investigate why file system access to
the agent file system is slower than network access to a git repository.
> I am sure that this is an error in checkout, because without any changes
> in the SCM or code, restarting the same pipeline can take different
> revisions.
> How do I always ensure the latest revision?
>
>
>
>
> On Tue, Dec 1, 2020 at 5:32 AM <unlimh...@gmail.com> wrote:
>
> There is such a jenkins-code:
>
> checkout ([ ...
> extensions: [[$class: 'CheckoutOption', timeout: 180],[$class:
> 'CloneOption', depth: 1, noTags: true, reference: '', shallow: false,
> timeout: 60]],
> ... )]
>
> Why do I get different revisions when I restart the same pipeline, without
> any changes in SCM (github)?
> The latest versions of git & jenkins are installed. Thank you.
> It's a bug in Jenkins? I ask for help and any ideas, because this is very
> urgent and important!
>
> If it is very urgent and important, then it should be important enough to
> provide a detailed description of the precise steps you're taking, a
> complete list of the checkout step (without eliding important values like
> the branch name), the things you've explored, what you saw in those
> explorations, and more.
>
> If there are no new changes in SCM, then I would expect the same commit to
> be used each time you run that job on that branch. Wiithout new commits on
> the branch, running the job should use the most recent commit on the branch
> that is being used for the checkout. However, you didn't tell us if this
> is a Pipeline job with the script inside the job, a Pipeline job that is
> getting the script from SCM, or a Pipeline job that is being defined as
> part of a multibranch pipeline.
>
> When you say "restart the same pipeline", do you mean that you press the
> "Replay" button for the pipeline? Do you mean that you press the "Build
> now" link? Do you mean that you're starting the job from a command line
> interface call? Are you starting the job from another job?
>
> Is there something special about the local file system that causes you to
> set the checkout timeout (a local file system operation) to allow more time
> that the clone timeout (which is a network operation)?
>
> Mark Waite
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtEy-jdP2VXGC%3Dum%2B9e7%2BBbEPsrrum6UGLvkYk1sofCN0w%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtEy-jdP2VXGC%3Dum%2B9e7%2BBbEPsrrum6UGLvkYk1sofCN0w%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/435403385.20201202105609%40gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-users/435403385.20201202105609%40gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-users/CAO49JtEKejgEpkX_5wCOrvJzanNOwkgMVDQdcPg%2BprYMC%2ByKCA%40mail.gmail.com.
