Securing build scripts when building pull requests

[Christopher Weaver]

Hi, 

For a project I work on, we have set up Jenkins, using the GitHub Branch 
Source Plugin, to do automatic builds for pushes to our repository, 
including test builds for pull requests. This is all working, but I am 
concerned about the security implications for the pull requests. It is my 
understanding that Jenkins will protect the Jenkinsfile itself against 
changes by non-privileged users, but as far as I can tell there is no such 
protection of other files critical to the build process, for example the 
CMakeLists we use to define most of our build with cmake. Is this not 
actually the problem I think it is, is there some way to instruct Jenkins 
to ignore changes to additional build files, or is there some other 
practical method for aborting builds when these files have changed? I tried 
to implement the last of these with logic built into the Jenkinsfile, but I 
got out of my depth trying to coax the necessary information out of git.

Chris Weaver

-- 
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/0986f350-db59-4e44-8bc9-4fb33f911ab8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Parameterized SVN Tags Filter

[Jonathan Zuber]

Hi,

 

I am trying to set up a parameterized build and have it fill the list of 
available tag options with a subset of the full list.  I am trying to apply 
even a simple regex but nothing seems to work.  If I enter anything at all 
then the subset is empty.

 

If I setup a simple regex to match any tags with the letter “c” in them
[image: image.png]

When I try to build I get this:
[image: image.png]

If I leave the tags filter blank, I get the full list of tags (and many of 
them have a “c”).


Thanks,


Jonathan

-- 
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/9ac81069-cc5a-4a92-983c-8971f5ee072a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Git scm fails to check the expected branch when another branch has the target branch name as a suffix

[James Robson]

Using the `checkout` command directly does work. Using that I can specify
'origin/develop' as the branch, and the job is triggering as expected.
Thank You.

On Thu, 16 May 2019 at 15:33, Mark Waite  wrote:

> I don't know if it will help, but you could try replacing the "syntactic
> sugar" command `git` with the `checkout` command.  Pipeline Syntax link on
> the Pipeline pages will help get the correct syntax for the details of the
> checkout command.
>
> On Thu, May 16, 2019 at 7:25 AM James Robson 
> wrote:
>
>>
>>
>> On Wednesday, 15 May 2019 21:28:52 UTC+1, Mark Waite wrote:
>>>
>>>
>>> You can often avoid the guessing by naming the branch precisely, as in
>>> 'origin/develop'.
>>>
>>
>> I attempted to use 'origin/develop' as the branch name, but that causes
>> the job to fail the checkout with "ERROR: Couldn't find any revision to
>> build. Verify the repository and branch configuration for this job". Here's
>> the pipeline I'm testing this with:
>>
>> node('linux') {
>> stage('checkout') {
>> git branch: 'origin/develop', ...
>> }
>> }
>>
>> The last line of output before the failure is a 'git fetch' call which is
>> identical to a run using a branch name of 'develop' which will then
>> checkout successfully.
>>
>> --
>> 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/f03ac832-bad1-42cb-8840-ce0cb632ae21%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Thanks!
> Mark Waite
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-users/oCeXFei3bZ8/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAO49JtG%3D8AgjqrXmZpAHBsKPr6Ep7A-ZV%2BEfTGroc46VZB%3DvVg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CAD10zustnzcfjORTPBaR%2BSVdsvFbpSzzfJZVAhNED98eWhZrwg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Git scm fails to check the expected branch when another branch has the target branch name as a suffix

[James Robson]

On Wednesday, 15 May 2019 21:28:52 UTC+1, Mark Waite wrote:
>
>
> You can often avoid the guessing by naming the branch precisely, as in 
> 'origin/develop'.
>

I attempted to use 'origin/develop' as the branch name, but that causes the 
job to fail the checkout with "ERROR: Couldn't find any revision to build. 
Verify the repository and branch configuration for this job". Here's the 
pipeline I'm testing this with:

node('linux') {
stage('checkout') {
git branch: 'origin/develop', ...
}
}

The last line of output before the failure is a 'git fetch' call which is 
identical to a run using a branch name of 'develop' which will then 
checkout successfully.

-- 
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/f03ac832-bad1-42cb-8840-ce0cb632ae21%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Git scm fails to check the expected branch when another branch has the target branch name as a suffix

[Mark Waite]

I don't know if it will help, but you could try replacing the "syntactic
sugar" command `git` with the `checkout` command.  Pipeline Syntax link on
the Pipeline pages will help get the correct syntax for the details of the
checkout command.

On Thu, May 16, 2019 at 7:25 AM James Robson 
wrote:

>
>
> On Wednesday, 15 May 2019 21:28:52 UTC+1, Mark Waite wrote:
>>
>>
>> You can often avoid the guessing by naming the branch precisely, as in
>> 'origin/develop'.
>>
>
> I attempted to use 'origin/develop' as the branch name, but that causes
> the job to fail the checkout with "ERROR: Couldn't find any revision to
> build. Verify the repository and branch configuration for this job". Here's
> the pipeline I'm testing this with:
>
> node('linux') {
> stage('checkout') {
> git branch: 'origin/develop', ...
> }
> }
>
> The last line of output before the failure is a 'git fetch' call which is
> identical to a run using a branch name of 'develop' which will then
> checkout successfully.
>
> --
> 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/f03ac832-bad1-42cb-8840-ce0cb632ae21%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Thanks!
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/CAO49JtG%3D8AgjqrXmZpAHBsKPr6Ep7A-ZV%2BEfTGroc46VZB%3DvVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

node parameter makes pipeline fail even if it's unused

[gbon]

Hi All, 
Asking for advice on this weird behavior:

I have a (declarative) pipeline that works perfectly fine and selects the 
agent like so 

pipeline {
  agent {
node {
  label "SOME_LABEL"
}
  }
  ...
}

If I edit the pipeline configuration to add a parameter of type Node ( 
which I'm still not using in the pipeline! )  the pipeline fails 
immediately with the following error

Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
--progress g...@my-super-secret-gitlab-repository.git 
+refs/heads/*:refs/remotes/origin/*" returned status code 128:
stdout: 
stderr: Could not create directory '/export/homes/my_user/.ssh'.
Host key verification failed.
fatal: Could not read from remote repository.



That I think has nothing to do with git since it works perfectly fine and 
the label is still hardcoded.
Seems like the job isn't correctly dispatched or something but I can't 
figure out what's happening.

Thanks!

-- 
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/0f7c8c1c-c1a8-4495-8be5-d00b5c5997ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Kubernetes plugin - Service account authorization in Google Cloud

[Carlos Sanchez]

the right way for Kubernetes apps is to create a ServiceAccount

https://cloud.google.com/solutions/jenkins-on-kubernetes-engine
https://cloud.google.com/solutions/jenkins-on-kubernetes-engine-tutorial
https://github.com/jenkinsci/kubernetes-plugin#running-in-google-container-engine-gke

On Wed, May 15, 2019 at 10:18 PM Jonas Lindström 
wrote:

> Hello,
>
> I am trying to use the Kubernetes plugin to start Jenkins agents in Google
> Kubernetes Engine. For server to server applications, Google recommends
> that you create a GCP service account and then generate a key file (JSON
> format) for this service account. The key file can then be used to generate
> short-lived tokens for kubectl.
>
> https://cloud.google.com/docs/authentication/production
>
> However, I have been unable to figure out from the documentation how to
> use this method of authentication with the Kubernetes plugin. I am using
> gcloud and kubectl commands to deploy applications to Google Kubernetes
> Engine, so I know that the service account itself has sufficient
> permissions. (Note that this is a GCP service account, not a kubectl
> serviceaccount.)
>
> I can retrieve the access token for a service account with
> gcloud auth application-default print-access-token
> but this token is short-lived and meant for debugging, so it's not very
> usable.
>
> --
> 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/8bc468cf-28aa-43e4-9504-435fc00b8691%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/CALHFn6MKRPUhbBLmwriey848zAkXdzYHDNnCq6%2BLgv8JAEJguw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Cucumber Report displays incorrect total duration if total duration is more than 24 hour

[jay rokde]

When Total duration of feature is exceeding 24 hours, it gets reset to 0 so 
incorrect Total duration gets displayed in Cucumber Report

 

For Example, 1:40.915 when total duration was 25:40:915

Not able to find any option to format this

-- 
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/3f82de94-4386-47fc-b266-0dc4bfd926a0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Credentials "secret text" -> bash -> expect ?

[b o b i]

Please disregard the question, and sorry for bothering.

It truned out, it is not a jenkins problem, rather a problem with timing of 
the expect script

so putting sleep 2 before and after send solved the problem

On Thursday, May 16, 2019 at 7:19:02 AM UTC+2, b o b i wrote:
>
> Do you mean ?
> send \"${varSecretText}\n\" 
>
> -->  it has {}
>
> or do you mean
>
> puts "SECRET $varSecretText"
>
> --> it worked 
>
> SECRET 
>
> On Thursday, May 16, 2019 at 6:19:57 AM UTC+2, Mark Waite wrote:
>>
>> I'm accustomed to seeing variable references in groovy strings as 
>> "${variablename}", while it seemed in your example you were referencing it 
>> as "$variablename".  Is that an intentional difference, or accidental?
>>
>> On Wed, May 15, 2019 at 9:14 PM b o b i  wrote:
>>
>>> It is a single line secret, but it wont work :|
>>>
>>> On Wednesday, May 15, 2019 at 7:31:27 PM UTC+2, Ivan Fernandez Calvo 
>>> wrote:

 If your secret is multiline, the secret text does not work as expected, 
 you could store the one line base64 value of your secret and decode it 
 before send it, it could work
>>>
>>> -- 
>>> 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 jenkins...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-users/85dc81a4-6206-4286-9578-42f1bec2fcfb%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> -- 
>> Thanks!
>> 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/9648b63e-d51c-4459-ab10-c8c74e446339%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.