Re: How can i do a reset with GitSCM?

[red 888]

hey thats cool. I'll have to test that, where is that in the docs? I 
couldn't find it anywhere maybe it was right under my nose.

On Tuesday, April 17, 2018 at 11:42:14 PM UTC-4, Mark Waite wrote:
>
> There is a strategy called "OURS" and a strategy called 
> "RECURSIVE_THEIRS".  Will either of those do what you want?
>
> Mark Waite
>
> On Tue, Apr 17, 2018 at 5:51 PM red 888  > wrote:
>
>> I want to merge a branch into the current one but reset the current 
>> branch to the one I'm merging in:
>>
>> checkout([$class: 'GitSCM',
>> branches: [[name: "${env.BRANCH_NAME}"]],
>> doGenerateSubmoduleConfigurations: false,
>> extensions: [
>> [$class: 'PreBuildMerge',
>> options: [
>> fastForwardMode: 'NO_FF',
>> mergeRemote: 'origin',
>> mergeStrategy: 'MergeCommand.Strategy',
>> mergeTarget: 'otherbranch']
>>  ],
>> ]
>> ])
>>
>> Is there an "except their changes" feature here? Actually I think I want 
>> a full reset because I want origin here to be identical to otherbranch
>>
>> -- 
>> 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/dfdb1112-fbdb-4929-87d7-0aebf3e4c553%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/9d9dbb71-cc47-45ef-a40d-e6b8c4da8b94%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ANN]: Snowglobe plugin (CI, CD, Docker, Pipelines, IAC)

[Nigel Magnay]

Greetings fellow Jenkins users.

I have just pushed v0.4 of snowglobe-plugin for jenkins, I thought this is
the point at which it is possibly useful for others treading down the same
path as us.

We develop software which is shipped as Docker images, which is neat. But
what starts out as a simple 'docker run ' rather rapidly turns in to
a complex nest of dependent containers (database. config. monitoring.
logging. etc) - deployment, testing, demos all became somewhat harder, and
a long list of "commands to run".

Even the simple act of spinning up a test environment for automated UI
tests to run has become somewhat problematic.

After trying various different toolings, we started to roll our own as none
of them quite hit the sweet spot of 'configuration' against 'flexibility'.

I describe SnowGlobe as 'docker-compose on steroids', or 'terraform with
added DSL goodness'. If you have met either of those tools, this is heavily
influenced by them.

As it ships today, You can specify a network of resources as a "SnowGlobe".
When the specification changes (say a new docker image is pushed), you can
'apply' the changes and the system automatically calculates which items
need to be recreated.

The server itself ships as a docker image and can be controlled with the
jenkins plugin (or via REST calls).

We are actively using this for:

- Deploying every built pull-request into a docker host so that QA can
manually verify
- Deploying and configuring live customer configurations

We intend very soon to use it to

- Continuous deployment of systems (Blue/Green deployments) into test
- Continuous deployment of systems into live environments

SnowGlobe is Java, and more importantly Groovy based - it should be
relatively simple to extend (currently it has provisions for Docker and
Consul, but we are likely to add Vault and AWS features soon). This means
that the configurations can leverage the power of Java/Groovy (think
Jenkinsfile).

There is some in-progress documentation here:
https://nirima.github.io/SnowGlobe/
and a getting-started which gives some flavour:
https://nirima.github.io/SnowGlobe/docs/guide/getting_started.html

I am currently adding more documentation.

The server is functional, but not pretty - there are likely bugs, but it is
working. There are lots of features to be added (such as: committing each
change to a git repository, additional providers) and examples to be
written. If this is something that interests you please get in touch - pull
requests are welcome !

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

Re: Question on behaviour of workflow-multibranch-plugin when building pull requests

[Mark Waite]

Git for Windows honors the Windows limit of 256 characters for a full
path.  A workaround is described at
https://stackoverflow.com/questions/22575662/filename-too-long-in-git-for-windows
 .

Mark Waite

On Wed, Apr 18, 2018 at 9:28 AM <
christian.beushau...@continental-corporation.com> wrote:

> Hi all,
>
> I stumbled over a behaviour that I do not quite understand.
>
> In our organisation we have a couple of Jenkins master running. Mixed
> between Linux based and Windows based masters.
> We have one Java application repository where the responsible team created
> a Jenkins Multibranch Pipeline project on a Linux master. On this
> environment the build of pull requests runs w/o problems. This job was now
> moved to a Windows based Jenkins master and we see the following problems
> with the pull requests:
>
> hudson.plugins.git.GitException: Command "git checkout -f
> a2e753c586b2dbf4ea2a101d49dcaa9cf0710147" returned status code 128:
> stdout:
> stderr: error: unable to create file : Filename too long
>
> Builds for existing branches on the other hand can successfully run on
> both instances.
> The main difference I saw is that for the pull request build the
> repository is initially checked out on master:
> Checking out git  into
>
> D:\casdev\.jenkins\workspace\vel_sw.tool.cofmk_gen_PR-22-JEYJ4XXNXUAUGONVULFEJEDR366W2SMKOHDDE7J4CPPY7OCPAJSQ@script
> to read Jenkinsfile
>
> Whereas the master branch build does not perform this checkout on the
> Jenkins master.
>
> Could you let me know if this is the expected behaviour and if you are
> aware of any possible workarounds?
>
>
> Mit freundlichen Gruessen/Best regards,
>
> Christian Beushausen
> I S PD SW SWF
> Interior Systems & Technology
>
> Besucheradresse / Visitor address:
> Continental Automotive GmbH
> Philipsstrasse 1, 35576 Wetzlar, Germany
> 
>
> Rechnungsadresse / Invoice address:
> Continental Automotive GmbH
> Philipsstrasse 1, 35576 Wetzlar, Germany
> 
>
> Telefon/Phone: +49 6441 370-9031 <+49%206441%203709031>
> Mobile: +49 151 74660227 <+49%201517%204660227>
> Telefax: +49 6441 37013-9031 <+49%206441%20370139031>
> E-Mail: christian.beushau...@continental-corporation.com
>
> http://www.continental-automotive.com
> 
>
> Continental Automotive GmbH, Vahrenwalder Str. 9, D-30165 Hannover
> 
> Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Helmut
> Matschi
> Geschaeftsfuehrer/Managing Director: Georg Sistermanns, Harald Stuhlmann
> Sitz der Gesellschaft/Registered Office: Hannover
> Registergericht/Registered Court: Amtsgericht Hannover, HRB 59424
> USt.-ID-Nr./VAT-ID-No. DE814950663
> 
>
> Proprietary and confidential. Distribution only by express authority of
> Continental AG or its subsidiaries.
>
> --
> 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/OF6ADE8291.8637CFC1-ONC1258273.0054B5A2-C1258273.0054ED55%40continental-corporation.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/CAO49JtGeUycNJDqRtmYNO-qeN-hnOrV856UsvMWTX8z9rd9gQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Linux + Jenkins Service Account + AWS MFA

[Felicia Rosemond]

Hello All,

Has anyone set up a Jenkins service account for accessing AWS CLI when MFA 
is required?  I have Jenkins running on a EC2 instance with all of the 
configuration in a EFS to hold configuration information.  I currently have 
a Jenkins service account set up in IAM with MFA disabled but we use MFA on 
all of our other user accounts.  The problem I am running into is that most 
Linux MFA tools don't seem compatible with AWS' virtual mfa device standard.

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/22a06e5d-0f87-498c-abf6-fa9345154a0f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Question on behaviour of workflow-multibranch-plugin when building pull requests

[Christian . Beushausen]

Hi all,

I stumbled over a behaviour that I do not quite understand.

In our organisation we have a couple of Jenkins master running. Mixed 
between Linux based and Windows based masters.
We have one Java application repository where the responsible team created 
a Jenkins Multibranch Pipeline project on a Linux master. On this 
environment the build of pull requests runs w/o problems. This job was now 
moved to a Windows based Jenkins master and we see the following problems 
with the pull requests:

hudson.plugins.git.GitException: Command "git checkout -f 
a2e753c586b2dbf4ea2a101d49dcaa9cf0710147" returned status code 128:
stdout: 
stderr: error: unable to create file : Filename too long

Builds for existing branches on the other hand can successfully run on 
both instances.
The main difference I saw is that for the pull request build the 
repository is initially checked out on master:
Checking out git  into 
D:\casdev\.jenkins\workspace\vel_sw.tool.cofmk_gen_PR-22-JEYJ4XXNXUAUGONVULFEJEDR366W2SMKOHDDE7J4CPPY7OCPAJSQ@script
 
to read Jenkinsfile

Whereas the master branch build does not perform this checkout on the 
Jenkins master.

Could you let me know if this is the expected behaviour and if you are 
aware of any possible workarounds?


Mit freundlichen Gruessen/Best regards,

Christian Beushausen
I S PD SW SWF
Interior Systems & Technology

Besucheradresse / Visitor address: 
Continental Automotive GmbH
Philipsstrasse 1, 35576 Wetzlar, Germany

Rechnungsadresse / Invoice address: 
Continental Automotive GmbH
Philipsstrasse 1, 35576 Wetzlar, Germany

Telefon/Phone: +49 6441 370-9031
Mobile: +49 151 74660227
Telefax: +49 6441 37013-9031
E-Mail: christian.beushau...@continental-corporation.com

http://www.continental-automotive.com


Continental Automotive GmbH, Vahrenwalder Str. 9, D-30165 Hannover 
Vorsitzender des Aufsichtsrats/Chairman of the Supervisory Board: Helmut 
Matschi 
Geschaeftsfuehrer/Managing Director: Georg Sistermanns, Harald Stuhlmann 
Sitz der Gesellschaft/Registered Office: Hannover 
Registergericht/Registered Court: Amtsgericht Hannover, HRB 59424
USt.-ID-Nr./VAT-ID-No. DE814950663 


Proprietary and confidential. Distribution only by express authority of
Continental AG or its subsidiaries.

-- 
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/OF6ADE8291.8637CFC1-ONC1258273.0054B5A2-C1258273.0054ED55%40continental-corporation.com.
For more options, visit https://groups.google.com/d/optout.

Re: Remote Jenkins Node never brought offline

[Alexandru Băluț]

It seems the script is killed when the command-launcher plugin is done with 
the agent. I filed https://issues.jenkins-ci.org/browse/JENKINS-50842

On Tuesday, 10 April 2018 15:40:57 UTC+2, Alexandru Băluț wrote:
>
>
>
> On 5 April 2018 at 15:44, Alexandru Băluț  
> wrote:
>
>> I'm using Jenkins ver. 2.107.1 and I created a Node. See the screenshot 
>> below for the configuration details of the Node.
>>
>>
>>
>>
> The problem I reported seems to be gone. But now there is another. In the 
> start-worker.sh script I have:
>
> #!/bin/sh
>
>
> I=$1
>
> P=...
>
> Z=...
>
>
> # According to `gcloud compute instances start --help` this is sync.
>
> gcloud compute --project $P instances start --zone $Z $I || exit 1
>
>
> finish() {
>
>   # Shutdown.
>
>   echo 3 >> /tmp/x
>
>   gcloud compute --project $P instances stop --zone $Z $I >> /tmp/x
>
> }
>
> trap finish EXIT
>
>
> # "What Jenkins expects from your script is that, in the end, it has to 
> execute
>
> # the agent program like java -jar agent.jar, on the right computer, and 
> have
>
> # its stdin/stdout connect to your script's stdin/stdout."
>
> # 
> https://wiki.jenkins.io/display/JENKINS/Distributed+builds#Distributedbuilds-WriteyourownscripttolaunchJenkinsagents
>
> echo 1 >> /tmp/x
>
> gcloud compute --project $P ssh --zone $Z $I --command 'wget "
> http://10.132.0.20:8080/jnlpJars/agent.jar; -O agent.jar && java -jar 
> agent.jar'
>
>
> echo 2 >> /tmp/x
>
>
> The agent is started fine, the job being run fails as expected, but then 
> "echo 2" is never executed. Not even "echo 3" which should be executed when 
> the scripts exits. It seems as if the script process is killed -9. This is 
> a problem because the instance I started cannot be brought down using this 
> nice synchronous mechanism provided by "gcloud compute instances 
> start/stop". 
>
> This is what I see in the node log:
>
> [...]
>
> Connection terminated
> channel stopped
>
> [04/10/18 13:13:47] Launching agent
> $ /var/lib/jenkins/start-worker.sh instance-eval-worker-template
> + I=instance-eval-worker-template
> + P=...
> + Z=...
> + gcloud compute --project ... instances start --zone ... 
> instance-eval-worker-template
>
> Starting instance(s) instance-eval-worker-template...
>
> .done.
> Updated 
> [https://www.googleapis.com/compute/v1/projects/.../instances/instance-eval-worker-template].
> + trap finish EXIT
> + echo 1
> + gcloud compute --project ... ssh --zone ... instance-eval-worker-template 
> --command wget "http://10.132.0.20:8080/jnlpJars/agent.jar; -O agent.jar && 
> java -jar agent.jar
>
> Updating project ssh metadata...
>
> .failed.
>
> --2018-04-10 13:14:14--  http://10.132.0.20:8080/jnlpJars/agent.jar
> Connecting to 10.132.0.20:8080... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: 762466 (745K) [application/java-archive]
> Saving to: ‘agent.jar’
>
>  0K .. .. .. .. ..  6%  102M 0s
>700K .. .. .. ..   100%  
> 206M=0.006s
>
> 2018-04-10 13:14:14 (131 MB/s) - ‘agent.jar’ saved [762466/762466]
>
> <===[JENKINS REMOTING CAPACITY]===>channel started
> Remoting version: 3.17
> This is a Unix agent
> Evacuated stdout
>
> Agent successfully connected and online
>
> Connection terminated
>
>
>
>
> Any idea what's going on? Should I file a bug or am I using it incorrectly?
>
>

-- 
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/c61d3e61-b68c-46b0-a9c9-cc98143a6e98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Vulnerability Scan

[Mark Waite]

On Wed, Apr 18, 2018 at 7:26 AM Eric Fetzer  wrote:

> Sorry Mark, not sure if you see "SECURITY-624" in the Table I posted.
> Here's the Jenkins Security Advisory:
>
> https://jenkins.io/security/advisory/2017-12-05/
>
> But then the Jenkins change log shows that with version 2.107, this was
> addressed (more than just a work around):  https://jenkins.io/changelog/.
> We are at 2.107.1, but the scan is still tagging us on this issue.
>
>
As far as I can tell, SECURITY-624 reported an XSS vulnerability in the Ant
plugin (and incorrectly reported an XSS vulnerability in Jenkins core).

The 2017-12-05 advisory 
reported that it was unresolved and provided a workaround.

The 2018-01-22 advisory

notes that the problem was specific to Ant plugin versions 1.7 and prior
and is fixed in Ant plugin 1.8.  That advisory lists other plugins and
their versions, though does not mention if any of those plugins are
affected by the XSS vulnerability.

The 2.89.4 LTS changelog 
reports that changes were made in core to reduce the risk of problems like
SECURITY-624.

The 2.107 (weekly) changelog  reports
the same changes that were made in 2.89.4 LTS to reduce the risk of
SECURITY-624 problems.

I assume that it is not enough to upgrade Jenkins core to those versions.
The Ant plugin needs to be upgraded to at least 1.8.  Likewise, I would
assume that the other plugins mentioned in the 2018-01-22 advisory need to
be upgraded to at least those versions.

Are you running new enough versions of the plugins listed in those
advisories?

Mark Waite



> Thanks,
> Eric
>
> On Tue, Apr 17, 2018 at 2:36 PM, Mark Waite 
> wrote:
>
>> Your mail doesn't tell us what security vulnerability is believed to
>> exist.
>>
>> Can you explain further what the report means and what you believe should
>> be done?
>>
>> Mark Waite
>>
>> On Tue, Apr 17, 2018, 9:02 AM Eric Fetzer  wrote:
>>
>>> No one has any ideas about this at all?
>>>
>>>
>>>
>>> On Friday, April 13, 2018 at 12:21:36 PM UTC-6, Eric Fetzer wrote:

 We're getting gigged on a security scan that looking at Jenkins
 documentation, should not be happening.  The scan is turning up:


 *Vulnerability*

 *Host*

 *IP*

 *Port*

 *201701*

 *201702*

 *201703*

 *201704*

 *201705*

 *201706*

 *201707*

 Jenkins JDK / Ant Tools Job Configuration Stored XSS Vulnerability
 (SECURITY-624)
 

 

 TCP:8080

 NO

 NO

 NO

 NO

 NO

 NO

 NO


 In the documentation, I see 2 places where this could be turning up.
 Ant plugin prior to 1.8, and Jenkins version prior to 2.93.  Our Jenkins
 version is 2.107.1 and we just upgraded our Ant plugin to 1.8.  Anyone have
 an idea what's getting us here?

 Thanks,
 Eric

>>> --
>>> 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/58bf582a-a106-4f95-966a-07642c16e11c%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> 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/fKY3_xmAPkk/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/CAO49JtH_8yxLHf2umcysCn1Wn7N248jMSyDXa-ybz%3D0fA6fBaw%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
> 

Re: Declarative script: How to escape 'Program Files (x86)'?

[Andrew Bayer]

I'd guess you need to escape the spaces in the original string? I dunno - I
don't have a Windows environment handy to test on.

A.

On Wed, Apr 18, 2018 at 6:28 AM, David Aldrich 
wrote:

> My declarative script contains:
>
>
>
> environment {
>
>   VSMSBUILDCMD_14_0 = 'C:\\Program Files (x86)\\Microsoft Visual
> Studio 14.0\\Common7\\Tools\\VsMSBuildCmd.bat'
>
> VSMSBUILDCMD_14_1 = 'C:\\Program Files (x86)\\Microsoft Visual
> Studio\\2017\\BuildTools\\Common7\\Tools\\VsMSBuildCmd.bat'
>
> }
>
>
>
> 
>
>
>
> steps {
>
> bat '''
>
> call "%VSMSBUILDCMD_14_1%"
>
> msbuild 
>
> '''
>
>
>
> This results in error:
>
>
>
> c:\jenkins\workspace\MyJob>call "%C:\Program Files (x86)\Microsoft Visual
> Studio\2017\BuildTools\Common7\Tools\VsMSBuildCmd.bat%"
>
> \Java\jre1.8.0_161\bin"" was unexpected at this time.
>
>
>
> I think I need to escape  ‘Program Files (x86)’.  What is the correct
> syntax for this please?
>
>
>
> Best regards
>
>
>
> David
>
>
>
> --
> 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/1780c53558db4c81b98ca30e74c2d4
> 0a%40EUX13SRV2.EU.NEC.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/CAPbPdOY_r3oGaNMaa9SRYFsSg4QNSPOfWyvA66LLXsQXGZUogA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Vulnerability Scan

[Eric Fetzer]

Sorry Mark, not sure if you see "SECURITY-624" in the Table I posted.
Here's the Jenkins Security Advisory:

https://jenkins.io/security/advisory/2017-12-05/

But then the Jenkins change log shows that with version 2.107, this was
addressed (more than just a work around):  https://jenkins.io/changelog/.
We are at 2.107.1, but the scan is still tagging us on this issue.

Thanks,
Eric

On Tue, Apr 17, 2018 at 2:36 PM, Mark Waite 
wrote:

> Your mail doesn't tell us what security vulnerability is believed to exist.
>
> Can you explain further what the report means and what you believe should
> be done?
>
> Mark Waite
>
> On Tue, Apr 17, 2018, 9:02 AM Eric Fetzer  wrote:
>
>> No one has any ideas about this at all?
>>
>>
>>
>> On Friday, April 13, 2018 at 12:21:36 PM UTC-6, Eric Fetzer wrote:
>>>
>>> We're getting gigged on a security scan that looking at Jenkins
>>> documentation, should not be happening.  The scan is turning up:
>>>
>>>
>>> *Vulnerability*
>>>
>>> *Host*
>>>
>>> *IP*
>>>
>>> *Port*
>>>
>>> *201701*
>>>
>>> *201702*
>>>
>>> *201703*
>>>
>>> *201704*
>>>
>>> *201705*
>>>
>>> *201706*
>>>
>>> *201707*
>>>
>>> Jenkins JDK / Ant Tools Job Configuration Stored XSS Vulnerability
>>> (SECURITY-624)
>>> 
>>>
>>> 
>>>
>>> TCP:8080
>>>
>>> NO
>>>
>>> NO
>>>
>>> NO
>>>
>>> NO
>>>
>>> NO
>>>
>>> NO
>>>
>>> NO
>>>
>>>
>>> In the documentation, I see 2 places where this could be turning up.
>>> Ant plugin prior to 1.8, and Jenkins version prior to 2.93.  Our Jenkins
>>> version is 2.107.1 and we just upgraded our Ant plugin to 1.8.  Anyone have
>>> an idea what's getting us here?
>>>
>>> Thanks,
>>> Eric
>>>
>> --
>> 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/58bf582a-a106-4f95-966a-
>> 07642c16e11c%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/fKY3_xmAPkk/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/CAO49JtH_8yxLHf2umcysCn1Wn7N248jMSyDXa-
> ybz%3D0fA6fBaw%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/CAByBicY5ssbsUW9QVUiKsRuqRKvc0LT8UapxRghJDo-5TOx%2B-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Remove Jenkins navigation links

[Sverre Moe]

Is it possible to remove the Jenkins navigation bar links? It is irrelevant 
for regular users/developers. Just us Jenkins admins need it, and we 
already have it by clicking on Jenkins> at top.
Ut just clutter up the UI for developers.



 



Tried the suggestion found 
here 
https://stackoverflow.com/questions/45280839/how-to-remove-the-navigation-bar-from-jenkins-pages

Configuration -> Theme -> Extra CSS: .Header{ Display:none }



-- 
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/9f5bb668-ca1a-4dbc-a1d0-93c0da2b6b3d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

How to get list of builds in queue that have offline slaves assigned to them

[Sunshine]

Hi all ,

I found options to get que length and que parameters ,

But is there a way to find builds in queues that are assigned to offline slaves 
?

Thankyou,

-- 
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/4a84ed24-33e8-4e3b-b958-b1bf60ea3100%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pipeline: BUILD_URL for Blue Ocean

[Sverre Moe]

We have the following content to mail notifications.
def content "Check console output at ${env.BUILD_URL} to view the results."

Where env.BUILD_URL has the following URL
https://build-ci.company.com:8443/job/projectA/job/user%252Fwork/115/

Is there an environment variable to get Blue Ocean build URL?
https://build-ci.compay.com:8443/blue/organizations/jenkins/projectA/detail/user%2Fwork/115/


A workaround would be to replace string values:
*Multibranch Pipeline*
def buildURL = env.BUILD_URL
def newBuildURL = buildURL.replace("job/${env.JOB_NAME}", 
"blue/organizations/jenkins/${env.JOB_NAME}")
newBuildURL = newBuildURL.replace("job/${env.BRANCH_NAME}", 
"detail/${env.BRANCH_NAME}")

*Pipeline*
def buildURL = env.BUILD_URL
def newBuildURL = buildURL.replace("job/${env.JOB_NAME}", 
"blue/organizations/jenkins/${env.JOB_NAME}/detail/${env.JOB_NAME}")

-- 
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/c7b463cd-f118-486d-9dfd-e2fad833712e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Blue Ocean: Jump to first error and use highlighting

[Sverre Moe]

When opening a pipeline build in Blue Ocean it scroll automatically down to 
the bottom of the last failed step.

If it is not possible it would be very helpful to control where it scrolls 
down to. For instance to scroll down to the first error in the failed step 
output.

[ 12%] Building CXX object src/CMakeFiles/connect.dir/actf_if.cpp.o
In file included from /usr/include/comp/base/debug_logger.h:20:0,
from 
/dev/shm/rpmroot-opensuse42.3_x86_64/BUILD/sys-server-4.2.107/plugins/connect_xml/xml_client.cpp:19:
/usr/include/comp/datestamp.h:11:11: *error:* This file needs C++17
M_REQUIRE_CXX17

..

Makefile:140: recipe for target 'all' failed
error: Bad exit status from 
/dev/shm/rpmroot-opensuse42.3_x86_64/tmp/rpm-tmp.FHrG8M (%build)
Bad exit status from 
/dev/shm/rpmroot-opensuse42.3_x86_64/tmp/rpm-tmp.FHrG8M (%build)

RPM build errors:
script returned exit code 1


In this case users have to scroll up to find the actually errors in the 
output. We have gotten some complaints from our developers that it is 
cumbersome to find the errors, without excessive scrolling or searching.

It would be a very welcoming feature to Blue Ocean to be able to choose 
where the automatic scrolling should stop.

Also if the output could highlight the errors and warnings
*error:* 
*warning:* 


We are using the AnsiColorBuildWrapper, but it doesn't highlight errors and 
warnings.
wrap([$class: 'AnsiColorBuildWrapper', 'colorMapName': 'XTerm']) {
Only outside of Blue Ocean I can see some coloring of test runs:

[r13-opensuse42.3-x86_64] 1: [--] 1 test from rules
[r13-opensuse42.3-x86_64] 1: [ RUN  ] rules.constructor
[r13-opensuse42.3-x86_64] 1: [   OK ] rules.constructor (5 ms)
[r13-opensuse42.3-x86_64] 1: [--] 1 test from rules (5 ms total)

[r13-opensuse42.3-x86_64] 1: [  PASSED  ] 4 tests.

-- 
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/d4193834-96ba-4301-a2c7-ebf3a1076094%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Declarative script: How to escape 'Program Files (x86)'?

[David Aldrich]

My declarative script contains:

environment {
  VSMSBUILDCMD_14_0 = 'C:\\Program Files (x86)\\Microsoft Visual Studio 
14.0\\Common7\\Tools\\VsMSBuildCmd.bat'
VSMSBUILDCMD_14_1 = 'C:\\Program Files (x86)\\Microsoft Visual 
Studio\\2017\\BuildTools\\Common7\\Tools\\VsMSBuildCmd.bat'
}



steps {
bat '''
call "%VSMSBUILDCMD_14_1%"
msbuild 
'''

This results in error:

c:\jenkins\workspace\MyJob>call "%C:\Program Files (x86)\Microsoft Visual 
Studio\2017\BuildTools\Common7\Tools\VsMSBuildCmd.bat%"
\Java\jre1.8.0_161\bin"" was unexpected at this time.

I think I need to escape  'Program Files (x86)'.  What is the correct syntax 
for this please?

Best regards

David

-- 
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/1780c53558db4c81b98ca30e74c2d40a%40EUX13SRV2.EU.NEC.COM.
For more options, visit https://groups.google.com/d/optout.

Blue Ocean: Last step always marked failed

[Sverre Moe]

In Blue Ocean the last step is marked failed.
The step that actually failed is a few steps earlier

I have deleteDir() at the very last in try-catch-finally on every parallel 
build node. This on order to clean up.

"Recursively delete the current directory from the workspace"
Blue Ocean has this step marked as failed.




It is always the last step that fails, in addition to the actually failed 
step.
If I remove deleteDir() it is the previous step that now fails.

-- 
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/8356fec3-d653-457b-8596-2cbb7ef86ea5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

setNextBuildNumber from upstream job

[Ewelina Wilkosz]

I have an upstream job that passes COPY_FROM_BUILD parameter containing the 
number of upstream job build (dummy name, but good enough for developers to 
understand what's happening...)
In downstream job I tried to use

nextBuildNumber($COPY_FROM_BUILD) 

and when creating the job my seed job complains

ERROR: (seed_leia.groovy, line 224) No such property: $COPY_FROM_BUILD for 
class: javaposse.jobdsl.dsl.helpers.properties.PropertiesContext


Either I'm doing something really stupid or nextBuildNumber won't work with 
upstream parameter... any idea anyone?

Build name setter won't be a good enough solution since I'm passing build 
namber, not name, to another tool I can't rally change :/

-- 
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/48b5b346-7812-4cc0-8a0a-4a5930c295e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Windows Desktop OS or Server OS is good for Jenkins master

[Simon Richter]

Hi,

On 16.04.2018 12:03, LnT wrote:

> Actually we will be providing Windows VMs. Not Linux.
> Hence looking for a piece of advice.  - *Desktop OS or ServerOS ?*

Desktop forces a reboot to install updates, which is not coordinated
with running services. Jenkins really doesn't handle shutdowns well if
you didn't make sure beforehand that no builds are running. Expect
spurious build failures, builds missing from the list and incomplete
artifact archives.

Server allows you to run updates manually, but someone needs to do that
and synchronize it with Jenkins, which is administration effort for
either you or your customers. This should be scriptable most likely, so
not all hope is lost.

If you really want to provide a turnkey solution, I hate to say it, but
Docker is the best idea, because it allows you to prepare an updated
base system image or Jenkins installation without affecting the running
instances, then you schedule a shutdown inside Jenkins and restart with
minimal downtime.

I'm not sure how far along Docker on Windows is these days though. MS
sells it as a solution so it's probably not all bad, but I know no one
actually using it.

   Simon

-- 
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/656bb959-438c-fb0d-ef92-a99412845552%40hogyros.de.
For more options, visit https://groups.google.com/d/optout.