-- 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-use...@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. |
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'
>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.
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 <unli...@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-use...@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.
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-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/435403385.20201202105609%40gmail.com.
--
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-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/459881610.20201211234224%40gmail.com.
Hi, let’s separate two completely different tasks of what you are trying to achieve: 1) Configure Jenkins server to serve itself over SSL / HTTPS 2) Use a certificate that your browser recognise as valid The documents you listed, tell you how to do point 1) and in general is left to you (or to other guides) how to do point 2) Now, from the error you see on the browser, “CERT_AUTHORITY_INVALID”, I’m pretty sure that you achieved 1) So, you actually did it !! But maybe you don’t know exactly what the error means. So, I’ll try to details to best of my knowledge (I’m not an expert of certificate authorities): - the browser tries to reach your Jenkins over port 443 (HTTPS) - Jenkins reply correctly and the browser is happy and they start to establish an SSL connection between them (that means they successfully exchanged the SSL certificate and they can encrypt the connection) - But the browser wants to be sure that the certificate has been made by some “known” trusted authority … let’s think of it like a known valid institution that produce valid certificates - … but when it looks inside the certificates, it can’t find a certificate authority that knows … and then, for safety, it stops the communication and raise an error saying that it can’t “trust” the certificate because it’s not produced by an authority that it knows. So, Jenkins is setup correctly and you did everything correctly on configure it. The last bit that remains for you is to get a “real” valid certificate from a real valid certificate authority … if you can’t, then you can’t avoid the browser giving the CERT_AUTHORITY_INVALID error. I hope that’s clear. Cheers, Gianluca. P.S.: The fact Jenkins does not have access to the Internet, doesn’t prevent you to get a valid certificate from a valid authority, like letsencrypt or other certificate authorities like Comodo SSL, and so on. We have many servers in our infrastructure without access to Internet but with valid certificate from Comodo SSL and LetsEncrypt |
|
|
|
-- 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-use...@googlegroups.com. |
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/6422CCE5-7F24-4671-A5D7-9DE43A47721E%40gmail.com. |