Re: different github checkout revisions

[unlimhost]

Title: Re: different github checkout revisions


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  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.






-- 
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.

Re: Authorization on Multibranch Pipeline

[Gautam, Rishi]

some way to restrict User1 to  trigger the build button from console on
master branch?

On Wed, Dec 2, 2020 at 2:03 AM Jibsan Joel Rosa Toirac 
wrote:

> Well I solved the problem, I used "sudo" before the commands and it
> started to work, anyhow I ran the command
> "root/.sdkman/candidates/grails/3.3.2/bin/grails war" and all started to
> work. Thanks for your help
>
> El mar, 1 dic 2020 a las 10:30, Rishi Gautam ()
> escribió:
>
>> Is there any way to enable authorization to build only specific
>> branch(job) on jenkins multbranch pipeline?
>>
>> Use Case:
>> User1: can only build test branch.
>> User2: can build both test and master branch.
>>
>> It would be very helpful to get the solution. Thanks in advance.
>>
>> --
>> 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/86a58043-d55c-40ac-ae59-3f9e185b53bbn%40googlegroups.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-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/CAAFuM4EEgdmSJZKbksDY05WB1qKY1-Oyp3_0puU9zHhCocwG-Q%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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAF4beLiozXoWtgGp1zLJHeuzd-b0-H%3DbGmHtPzFmW-3d0h1D8A%40mail.gmail.com.

loop over branches

[jeremy mordkoff]

We have too many tests, so we have broken them up into three groups. One 
group that runs after each checkin and one group that runs once a day on 
any branch with changes and one group that I would like to limit to one 
instance at a time but still test any active branch. 

What is the best way to structure such a job? I am thinking a daemon type 
job that just iterates over branches and kicks off the real test job and 
then waited. The daemon would be sitting idle for almost 6 hours and then 
busy for 10 seconds, and then idle again, which seems slightly wasteful but 
at least this way jenkins would be self managing and I could tweak the 
daemon side to have priorities if I wanted, e.g. if master had changes and 
hadn't run in 36 hours, run it next, then go back to rotating fairly across 
the branches with changes. 

I can't have just one long running job that does it all because then my 
test results would get mixed together (I think) and I would not have 
red/yellow/blue for each branch. 

Any other ideas? 

-- 
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/bcf0f35d-ed37-4ef6-8445-e628373c7817n%40googlegroups.com.

Re: Authorization on Multibranch Pipeline

[Jibsan Joel Rosa Toirac]

Well I solved the problem, I used "sudo" before the commands and it started
to work, anyhow I ran the command
"root/.sdkman/candidates/grails/3.3.2/bin/grails war" and all started to
work. Thanks for your help

El mar, 1 dic 2020 a las 10:30, Rishi Gautam ()
escribió:

> Is there any way to enable authorization to build only specific
> branch(job) on jenkins multbranch pipeline?
>
> Use Case:
> User1: can only build test branch.
> User2: can build both test and master branch.
>
> It would be very helpful to get the solution. Thanks in advance.
>
> --
> 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/86a58043-d55c-40ac-ae59-3f9e185b53bbn%40googlegroups.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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAAFuM4EEgdmSJZKbksDY05WB1qKY1-Oyp3_0puU9zHhCocwG-Q%40mail.gmail.com.

Authorization on Multibranch Pipeline

[Rishi Gautam]

Is there any way to enable authorization to build only specific 
branch(job) on jenkins multbranch pipeline?

Use Case:
User1: can only build test branch.
User2: can build both test and master branch.

It would be very helpful to get the solution. Thanks in advance.

-- 
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/86a58043-d55c-40ac-ae59-3f9e185b53bbn%40googlegroups.com.

Re: different github checkout revisions

[Mark Waite]

On Tue, Dec 1, 2020 at 5:32 AM  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.

Default Admin API Token

[Shahbaz Subedar]

Hello Team,

I have been trying to implement the functionality of having default Admin 
API token at the time of deployment of Jenkins. I have been following the 
below link.
https://github.com/jenkinsci/jenkins/pull/4027/commits 

As per the instruction, I have setup the system properties with fixed 
token, but still not able to use the same token to access the API.

I have been using Helm chart to deploy the jenkins with version as = 2.261.


Here are some details of my values.yaml file.

global:
  hosts:
domain: ${domain}
master:
  resources:
requests:
  cpu: 512m
  memory: 512Mi
  javaOpts: >-
-Dhudson.model.DirectoryBrowserSupport.CSP="default-src 'self' 
'unsafe-inline' 'unsafe-eval'; img-src 'self' 'unsafe-inline' data:;"
-Dcasc.jenkins.config="/var/jenkins_home/casc_configs"
-Djenkins.install.runSetupWizard="false"

-Djenkins.install.SetupWizard.ADMIN_INITIAL_API_TOKEN=11b9b3fafe25923768621ca1b64d44bfd1
-Djenkins.security.ApiTokenProperty.adminCanGenerateNewTokens="true"
-Djenkins.security.ApiTokenProperty.showTokenToAdmins="true"
  tag: 2.261
  useSecurity: true
  adminUser: "shahbaz"
  adminInitialApiToken: "true"
  JCasC:
enabled: true
defaultConfig: false

configScripts:
  jenkins-settings: |
jenkins:
  authorizationStrategy:
loggedInUsersCanDoAnything:
  allowAnonymousRead: false
  securityRealm:
%{if persistence == true }
keycloak
%{ else }
local:
  allowsSignup: false
  users:
  - id: "admin" 

-- 
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/b46ad6c8-cc55-4148-bd6d-88d48598fd93n%40googlegroups.com.