Re: GitHub and Bitbucket branch source UI refactoring

[Michael Kobit]

Finally got some time to try it out (sorry!) and I know the PR has already
been merged, but UI looks great, and the contextual help menus make it easy
to pick up. Awesome job!

Only thing I noticed is no built-in Job DSL support - we use the Job DSL
entirely to create and setup all of our Organization folders, and I didn't
see any generated DSL methods under
*/plugin/job-dsl/api-viewer/index.html#path/organizationFolder-organizations-bitbucket*
.

On Thu, Jun 29, 2017 at 9:43 AM Mark Waite 
wrote:

> I think I have detected the difference between by multi-branch pipelines
> with GitHub branch sources.
>
> The problem job is a GitHub private repository (
> https://github.com/MarkEWaite/jenkins-bugs-private), while the working
> job is a GitHub public repository (
> https://github.com/MarkEWaite/jenkins-bugs) .
>
> When I configure the private repository job, it presents the list of
> repositories but only includes public repositories in the list.  The
> credentials are valid and are used in other jobs, but it is as though the
> list of repositories is not being refreshed with the credentials.
>
> Mark Waite
>
> On Thu, Jun 29, 2017 at 8:27 AM Mark Waite 
> wrote:
>
>> I'm using latest betas (as far as I can tell).  The GitHub source is now
>> working in the cases that were failing previously.  Thanks very much for
>> that!
>>
>> Unfortunately, when I open the "Configure" page for one of my
>> multi-branch pipeline job that is using GitHub as a branch source, it
>> reverts the repository choice to the top of the list, instead of showing
>> the originally selected repository.
>>
>> When I open the "Configure" page for another of my multi-branch pipeline
>> jobs that is using GitHub as a branch source, it retains the repository
>> choice.
>>
>> Unfortunately, I don't know what is different between those two cases of
>> a GitHub branch source for a multi-branch pipeline.
>>
>> I'll let you know if I identify key attributes which make the two cases
>> behave differently.
>>
>> Mark Waite
>>
>>
>> On Monday, June 26, 2017 at 10:04:00 PM UTC-6, Michael Neale wrote:
>>>
>>> I retested with latest betas and looking good (binary compat, migration
>>> etc).
>>>
>>> On Monday, June 26, 2017 at 11:46:49 PM UTC+10, Stephen Connolly wrote:



 On 26 June 2017 at 06:13, Kevin Burnett 
 wrote:

> This is so good. :)
>

 Great to hear it. I love feedback (+ve or -ve beats none)


>
> The pre and post diffs looked right, and the new UI and functionality
> gives me everything that I was hoping for.
>

 w00t


>
> I'm going to remove the "discover pull requests from [everywhere]"
> behaviors and select "Only branches that are also filed as PRs" on
> production as soon as possible.
>
> Michael Neale mentioned that one issue he had seen "does look better
> now with the new version." I used the plugin versions that Stephen
> originally posted on June 20, but I take Michael's comment to mean there
> might be newer versions. Please make this irrelevant by issuing release
> versions of these plugins this week. :)
>
> Thanks a ton!
> -KB
>
> On Friday, June 23, 2017 at 12:45:44 PM UTC-4, Stephen Connolly wrote:
>>
>>
>>
>> On 23 June 2017 at 17:24, Mark Waite  wrote:
>>
>>> I see duplicate entries in the "Add' configuration of the Bitbucket
>>> source for "Checkout over ssh".  Let me know if you need steps to see 
>>> that.
>>>
>>
>> Shouldn't... may just be a bug in the drop down populator when you
>> have GitHub and Bitbucket
>>
>>
>>>
>>> I also wonder if the text "General", "Git" and "Bitbucket" should be
>>> italicized, or bold, or separated with dashes, or something, so that the
>>> user has a concept that things will be appearing under them.  They seem 
>>> to
>>> be standard text currently, and it wasn't obvious to me that they were
>>> categories into which settings would be placed.
>>>
>>
>> Cannot style the drop-down menu without significant JS changes that
>> risk affecting form binding.
>>
>>
>>>
>>> Mark Waite
>>>
>>>
>>> On Friday, June 23, 2017 at 9:58:52 AM UTC-6, Mark Waite wrote:

 The UI experience has been great for me in the two or three places
 where I've used it.  I was a little surprised (and pleased) with the
 adaptation that the local branch setting is now a toggle.  I think 
 that's
 the right approach, since (as far as I can tell) that is the 99% use 
 case.

 Earlier I reported an NPE when configuring a multi-branch pipeline
 that uses GitHub as source instead of Git as source.  The NPE was 
 resolved
 by removing the multiple-scms plugin.  

Re: Jenkins Distributed Builds: Restricting users from configuring jobs with Jenkins Master's executors

[Michael Pailloncy]

By default, the master is configured with "Use this node as much as
possible" : http://${JENKINS_URL}/computer/(master)/configure
You can change this behavior with "Only build jobs with label expressions
matching this node". In this way, the master can only be used if an
explicit allocation (using 'master' label) is done.

No sure that it's an ideal solution in your case, since team member can
still force the execution on master, but it can prevent accidental/unwanted
execution and it's anyway a good idea to avoid build on master.

There is also this plugin :
https://wiki.jenkins.io/display/JENKINS/Job+Restrictions+Plugin
Seems to fit your needs, but personally not tested.

Hope it helps.


2017-07-11 20:41 GMT+02:00 Jason LeMauk :

> I currently have a distributed build system in place (1 Jenkins master and
> several Jenkins Agents). I have an automated backup / backup cleanup job
> that runs on Jenkins Master. For this reason I need to keep my executors on
> the Jenkins Master. The rest of my jobs run on specific Jenkins Agents.
>
> As I cannot remove my executors from the Jenkins Master, what is the best
> way to ensure that no other jobs can be built on Jenkins Master? I am using
> project-based authorization strategy, and I don’t want a team member who
> may configure a job selecting the Jenkins Master to build on.
>
> What is the best way to go about achieving this?
>
> Thanks in advance for any guidance and advice!
>
> --
> 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/BY2PR12MB059992ED76D9D6B99481D
> D7F89AE0%40BY2PR12MB0599.namprd12.prod.outlook.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/CAPO77c2zEbVbJh6D8L1rZCNZ4sa%3Dz9cDFwjr4DEYc8fmTXk2tQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Build time trend - Pipeline

[Michael Pailloncy]

Pipeline jobs are not limited to a specific agent, that's why this
information is not displayed on the build time trend page.

But as usual you are able to see on which agent a particular step has been
executed on the build logs (Running on ... in /var/lib/jenkins/...), or by
navigating to the buid page > Pipeline Steps > and then find the console
output associated with "Allocate node : Start  ..." step.

2017-07-11 22:17 GMT+02:00 Esdras Neto :

> Good afternoon,
>
> I am new to use Pipeline jobs, I would appreciate if someone could point
> me towards the right direction here.
>
>
> On the build time trend for my pipeline job I don's see the Agent
> information, any ideas why this is happening? I only see the columns
> "Build" and "Duration".
>
> Thanks!
> Esdras
>
> --
> 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/b691fb8e-b450-49b7-92c9-f1eaa0a87f97%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/CAPO77c1rM2sf5-fkmGeS60JPPEK2o-1XqJ-ew6ZebafdBHgDnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

RE: Installing / maintaining Jenkins on a Linux host machine

[Chanda Unmack]

In my experience, I have been having a miserable time with Jenkins on RHEL, 
where I have to either restart it or reboot the machine at least once a day. We 
had to move off of Ubuntu in order for our IT to support us, but are seriously 
considering moving back.
I have run Jenkins on Ubuntu at several companies previously with no major 
issues, but I generally stick to the LTS version.

From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Jason LeMauk
Sent: Tuesday, July 11, 2017 10:06 AM
To: jenkinsci-users@googlegroups.com
Subject: RE: Installing / maintaining Jenkins on a Linux host machine

Great! All this information has been extremely helpful.

If anybody else has any experience with any other flavors of Linux, please let 
me know what your experiences are.

From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Slide
Sent: Tuesday, July 11, 2017 12:52 PM
To: jenkinsci-users@googlegroups.com
Subject: Re: Installing / maintaining Jenkins on a Linux host machine

Just as a note, the WAR is not an installable thing. It's similar to a Java JAR 
file, you "execute" the WAR file to run Jenkins. You can run the WAR on any OS 
that has Java simply by doing java -jar PATH/TO/jenkins.war. There are some 
command line options you can provide, but in general you are just running the 
WAR file.

On Tue, Jul 11, 2017 at 9:44 AM Jason LeMauk 
> 
wrote:

We are currently provisioning a physical server as our automation server. We 
are making considerations as far as what our native operating system should be 
on this physical machine.

We are going to use a Linux OS as our operating system. From the Jenkins 
download 
page,
 I can see that Jenkins’ package distribution is available to Red Hat / Fedora 
/ CentOS (which we will not be using), as well as Ubuntu / Debian. I also 
notice that a Generic Java package (WAR) distribution is available.
•Am I correct in assuming that if we use a non-Ubuntu / non-Debian 
operating system, we can still install Jenkins via the WAR distribution without 
issue?
•If we are not able to install via WAR without issue, are we relegated 
to using Debian / Ubuntu if we’re going to install Jenkins on a Linux machine 
(with the possibility of Red Hat / Fedora / CentOS ruled out)?

It should probably be noted that we will likely install / upgrade on the 
Jenkins LTS release 
schedule.

Thanks for any guidance from anybody who may have experience installing / 
maintaining a Jenkins instance on a Linux machine!
Jason
--
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/BY2PR12MB0599BE30A44301EF9566D3A689AE0%40BY2PR12MB0599.namprd12.prod.outlook.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: Can I use the multibranch pipeline plugin that interacts with a user at a stage

[Michael Pailloncy]

The "*agent any*" declaration at the top level of your pipeline indeed
allocates an executor for the whole pipeline.
You can avoid this allocation with something like :

pipeline {
agent none
parameters {
choice(choices: 'SIT\nUAT', description: 'What environment?', name:
'environment')
}
stages {
stage ('build') {
agent any
tools {
maven 'm3'
}
steps {
echo 'build it.'
sh "mvn --version"
}
}
stage ('test') {
steps {
echo 'test it.'
input 'Ready to go?'
}
}
stage('deploy to sit') {
steps {
echo 'push it to dev.'
}
}
stage("deploy to uat") {
steps {
echo 'push it to uat.'
}
}
}
}

Or instead of *tools* section, you may prefer the *withMaven* syntax :

...
stage ('build') {
agent any
steps {
echo 'build it.'
withMaven(maven: 'm3') {
sh "mvn --version"
}
}
}
...

See https://wiki.jenkins.io/display/JENKINS/Pipeline+Maven+Plugin


2017-07-04 11:56 GMT+02:00 paul b :

> Yeah.  Thats right.  Not tied to using that though.  Not sure why I need
> to push to using it yet though.
>
> pipeline {
> agent any
> parameters {
> choice(choices: 'SIT\nUAT', description: 'What environment?',
> name: 'environment')
> }
> tools {
> maven 'maven 3.3.9'
> //jdk 'jdk8'
> }
> stages {
> stage ('build') {
> steps {
> echo 'build it.'
> }
> }
> stage ('test') {
> steps {
> echo 'test it.'
> input 'Ready to go?'
> }
> }
> stage('deploy to sit') {
> steps {
> echo 'push it to dev.'
> }
> }
> stage("deploy to uat") {
> steps {
> echo 'push it to uat.'
> }
> }
> }
> }
>
> On Tuesday, 4 July 2017 10:41:27 UTC+1, mpapo - Michael Pailloncy wrote:
>>
>> It seems like you are using the Declarative way to write your pipeline
>> right ? Can you share the full script please. I guess that you are
>> allocating an agent at the top level.
>>
>> 2017-07-04 11:06 GMT+02:00 paul b :
>>
>>> Brill.  I have managed to get that to work. I have the following stage
>>>
>>>stage ('test') {
>>> steps {
>>> echo 'test it.'
>>> input 'Ready to go?'
>>> }
>>> }
>>>
>>> The problem we have now is that the build consumes one of the
>>> executors.  I guess I can farm that off somehow???
>>>
>>> On Tuesday, 4 July 2017 09:34:51 UTC+1, paul b wrote:

 Brill.  Thanks. I will look into it.

 On Tuesday, 4 July 2017 08:59:13 UTC+1, mpapo - Michael Pailloncy wrote:
>
> Yeah, seems like you want to use the *input* step (interaction
> through Jenkins) : https://jenkins.io/doc/pipel
> ine/steps/pipeline-input-step/
> You can find a simple example here with some explanations :
> https://github.com/jenkinsci/pipeline-plugin/blob/master/
> TUTORIAL.md#pausing-flyweight-vs-heavyweight-executors
>
> 2017-07-04 9:49 GMT+02:00 paul b :
>
>> I would like to use the multibranch pipeline plugin and wondered if
>> it can be configured such that when it gets to a stage, lets says 
>> deploying
>> to environment, it then interacts with a user.  That interaction being a
>> through the jenkins, email or even jira!  Then after the user interaction
>> response, I would expect it to push it onto the next stage!  Then 
>> possibly
>> with further interactions at further stages.  Not sure if the plugin has
>> this capability or even if it is good practice???
>>
>> Furthermore I would expect, when the branch is paused at a stage, I
>> would expect that further branches can be pushed on too!
>>
>> Hope all this makes sense.
>>
>> --
>> 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/1ad0acac-
>> 8a06-4ea8-84a0-d0de30c112b4%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-use...@googlegroups.com.
>>> To view this discussion on the web visit 

Re: Is pipeline timeout suppose to work?

[jerome]

This is Declarative pipeline syntax (which I don't use), for non 
Declarative pipeline (which is what I have), I wonder if this work the same 
or where it can be used?

On Tuesday, July 11, 2017 at 5:31:08 AM UTC-4, Jakub Pawlinski wrote:
>
> I use this on pipeline level and it works fine there, haven't tried on 
> stage level tho.
>
> pipeline {
> options {
> timeout(time: 12, unit: 'HOURS')
> timestamps()
> }
> ...
> }
>

-- 
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/8e3e104b-9cf2-49b0-bdc2-572865691d8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Build time trend - Pipeline

[Esdras Neto]

Good afternoon,

I am new to use Pipeline jobs, I would appreciate if someone could point me 
towards the right direction here.


On the build time trend for my pipeline job I don's see the Agent 
information, any ideas why this is happening? I only see the columns 
"Build" and "Duration".

Thanks!
Esdras

-- 
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/b691fb8e-b450-49b7-92c9-f1eaa0a87f97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Proxy server between Jenkins and the Internet

[Curtis Kline]

Hello all,

I am setting up a new Jenkins server and some build nodes to replace an old
one. The cloud instances running Jenkins jobs are behind a Squid proxy and
cannot access the Internet directly. The initial problem of not being able
to download any plugins was easily resolved by entering proxy settings in
the Jenkins admin UI. I was able to get Linux shell commands working with a
http_proxy environment variable. It's gotten pretty ugly from there, though.

The Android SDK and Gradle build tools each had proxy settings. Docker
containers need to be started with proxy settings. Java and SBT each have
proxy settings. The HockeyApp plugin has a bug preventing use with a proxy.
And it continues...

Does anyone else run Jenkins behind a proxy server? Is it a maintenance
nightmare? I'm beginning to think we are going to have to get the Jenkins
instances out from behind the proxy or face ongoing maintenance headaches.

Thanks,
Curtis

-- 
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/CAGkg-e%3D_Qb89DiJpVALePvRV2hnBdQaS-LwSr%2Bk0%2B26r8K1r0Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline powershell

[jerome]

Hi James, 
I will try to install the plugin and provide more information (I was giving 
the dump and the system info, but I may generate even more with this it 
seem).

As for JENKINS-34150  goes 
it definitely did not fix everything, since many bug were open since then 
with up to date configuration. So you can assume there still is something 
wrong there without a doubt.

As for giving a working example, I wonder how I can manage to do this 
properly. I need a master and a slave to do so, I cannot provide the whole 
System image (there is confidential data and configuration won't work else 
where with network drive).

I can provide most of the build script, but I cannot give access to the 
real .sln and .vxcproj files and sources. If you have an idea how I could 
do the reproduction master/slave setup and all data for reproduction that 
could be used. This doesn't show up when master/salve was a single Windows 
node, this only show up with my Linux master inside a Hyper-V and Windows 
slave Desktop normally installed. I haven't test any other master/node 
configuration so far. If you have any wish list or way I could give you 
back the proper usable information to reproduce this that you could use let 
me know.

I wonder if you could provide a jenkins.war with more debug trace I could 
try to reproduce the bug on my side (probably not, but worth a try to ask 
for it)?

Else I will try the following:

   1. Make a dummy project
   2. make a strip down jenkinsfile script
   3. try to run it until it hang
   4. make a dummy msbuild .sln, .vcxproj compilation
   5. drop the information with the plugin above
   6. Submit all this.

The #2 and especially #4 can be a headache to make something that look like 
the real deal and can reproduce the problems since it seem to occur when 
the bat command is really long. But if this can reproduce it, I will post 
it for both bat and powershell.

Will give some feedback as soon as I can.
Jerome

-- 
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/450c0b7e-bf50-4573-b3e0-c191d5a2a864%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins Distributed Builds: Restricting users from configuring jobs with Jenkins Master's executors

[Jason LeMauk]

I currently have a distributed build system in place (1 Jenkins master and 
several Jenkins Agents). I have an automated backup / backup cleanup job that 
runs on Jenkins Master. For this reason I need to keep my executors on the 
Jenkins Master. The rest of my jobs run on specific Jenkins Agents.
As I cannot remove my executors from the Jenkins Master, what is the best way 
to ensure that no other jobs can be built on Jenkins Master? I am using 
project-based authorization strategy, and I don't want a team member who may 
configure a job selecting the Jenkins Master to build on.
What is the best way to go about achieving this?
Thanks in advance for any guidance and advice!

-- 
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/BY2PR12MB059992ED76D9D6B99481DD7F89AE0%40BY2PR12MB0599.namprd12.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins Distributed Builds: Project-Based Matrix Authorization Strategy

[Jason LeMauk]

Hello Jenkins Community!

I am currently doing some preemptive planning for setting up our Jenkins 
instance.
We are going to use LDAP (Jenkins LDAP 
plugin), as our security 
realm, and project-based matrix authorization strategy (Matrix Authorization 
Strategy 
plugin),
 as our authorization strategy.
It should also be noted that we have a distributed build system in place (1 
Jenkins Master and several Jenkins Agents (virtual machine's running on Jenkins 
host via VirtualBox)). The goal of the distributed build system is to separate 
build / project environments on a per project basis.

As far as using a project-based matrix authorization strategy, I envision the 
permissions working like so:
1. Global Administrators:
   - Access to everything within Jenkins (all projects / jobs, 
configuration settings, plugins, etc.).
   - Access to all Jenkins Agents / Build Nodes (provide with 
virtual machine credentials for login).
   - Can configure / modify all project's Jenkins Agents / Slaves.
2. Project Administrators:
   - Access as an administrator to specific project's / job's 
configurations.
   - Access to team's / project's specific Jenkins Agents / Build 
Nodes (provide with virtual machine credentials for login).
   - Can configure / modify project specific Jenkins Agents / 
Slaves.
3. Jenkins Users
   - Low level users added by project level administrators.
   - Project level administrators have the ability to add users to 
their project / job and grant permissions to those users as they see fit.
   - Cannot directly configure / modify Jenkins Agents / Slaves 
(Jenkins Agent / Slave credentials for login are not provided to low level 
users).
   - Could possibly modify job configurations for their project if 
granted the right by a project administrator.

Is there anything I'm missing here as far as defining our authorization 
strategy? From everything I've read on the Jenkins wiki about the plugins as 
well as Jenkins itself, this appears to be a viable approach for giving teams 
as much control over their builds / projects as possible.
Thanks to anyone who has any experience setting up a Jenkins Distributed Build 
system using project-based authorization!

-Jason

-- 
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/BY2PR12MB0599349B594D500AE8612BFA89AE0%40BY2PR12MB0599.namprd12.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

RE: Installing / maintaining Jenkins on a Linux host machine

[Jason LeMauk]

Great! All this information has been extremely helpful.

If anybody else has any experience with any other flavors of Linux, please let 
me know what your experiences are.

From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Slide
Sent: Tuesday, July 11, 2017 12:52 PM
To: jenkinsci-users@googlegroups.com
Subject: Re: Installing / maintaining Jenkins on a Linux host machine

Just as a note, the WAR is not an installable thing. It's similar to a Java JAR 
file, you "execute" the WAR file to run Jenkins. You can run the WAR on any OS 
that has Java simply by doing java -jar PATH/TO/jenkins.war. There are some 
command line options you can provide, but in general you are just running the 
WAR file.

On Tue, Jul 11, 2017 at 9:44 AM Jason LeMauk 
> 
wrote:

We are currently provisioning a physical server as our automation server. We 
are making considerations as far as what our native operating system should be 
on this physical machine.

We are going to use a Linux OS as our operating system. From the Jenkins 
download page, I can see that Jenkins’ package 
distribution is available to Red Hat / Fedora / CentOS (which we will not be 
using), as well as Ubuntu / Debian. I also notice that a Generic Java package 
(WAR) distribution is available.
•Am I correct in assuming that if we use a non-Ubuntu / non-Debian 
operating system, we can still install Jenkins via the WAR distribution without 
issue?
•If we are not able to install via WAR without issue, are we relegated 
to using Debian / Ubuntu if we’re going to install Jenkins on a Linux machine 
(with the possibility of Red Hat / Fedora / CentOS ruled out)?

It should probably be noted that we will likely install / upgrade on the 
Jenkins LTS release schedule.

Thanks for any guidance from anybody who may have experience installing / 
maintaining a Jenkins instance on a Linux machine!
Jason
--
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/BY2PR12MB0599BE30A44301EF9566D3A689AE0%40BY2PR12MB0599.namprd12.prod.outlook.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/CAPiUgVc24MHXmheoGGze2xpjHzuzfTOAgiijtc9R75N%2Bc%3DdRuQ%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/BY2PR12MB059930D01F2415583EF8CFA489AE0%40BY2PR12MB0599.namprd12.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

Re: Installing / maintaining Jenkins on a Linux host machine

[Mark Waite]

On Tue, Jul 11, 2017 at 10:54 AM John Mellor 
wrote:

> There are competing update philosophies to consider:
> Ubuntu ships the latest (unstable) release of Jenkins all the time, while
> RedHat/CentOS/etc ships the stable version. I host on a Ubuntu VM, but
> definitely wish it was better tested. If stability is key, then Ubuntu may
> not be your best choice.
>
> Personally, I would choose the Jenkins provided operating system specific
installer (deb for Ubuntu, deb for Debian, rpm for CentOS, rpm for Red Hat,
rpm for OpenSUSE) rather than the operating system vendor's bundled Jenkins
(if they choose to bundle it).  The operating system version is either too
outdated (as was the case in Debian some years ago), or is based on weekly,
when I want the long term support release.

The advice from jieryn (use the Jenkins repository flavor) works for
Debian, Ubuntu, Red Hat, CentOS, OpenSUSE, and likely FreeBSD.  The OpenBSD
specific package seems quite far out of date, so there you'd need the war
file rather than using the operating system specific installer.

Mark Waite


>
> On Tue, 2017-07-11 at 16:44 +, Jason LeMauk wrote:
>
> We are currently provisioning a physical server as our automation server.
> We are making considerations as far as what our native operating system
> should be on this physical machine.
>
> We are going to use a Linux OS as our operating system. From the Jenkins
> download page , I can see that Jenkins’
> package distribution is available to Red Hat / Fedora / CentOS (which we
> will not be using), as well as Ubuntu / Debian. I also notice that a
> Generic Java package (WAR) distribution is available.
>
> ·Am I correct in assuming that if we use a non-Ubuntu /
> non-Debian operating system, we can still install Jenkins via the WAR
> distribution without issue?
>
> ·If we are not able to install via WAR without issue, are we
> relegated to using Debian / Ubuntu if we’re going to install Jenkins on a
> Linux machine (with the possibility of Red Hat / Fedora / CentOS ruled out)?
>
> It should probably be noted that we will likely install / upgrade on the 
> Jenkins
> LTS release schedule .
>
> Thanks for any guidance from anybody who may have experience installing /
> maintaining a Jenkins instance on a Linux machine!
>
> Jason
>
> --
> 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/1499792036.3165.5.camel%40esentire.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/CAO49JtHEhVCYhefrXqwbTC63VhgjoOrEs_X%2BusOeGwKfjd9diA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Installing / maintaining Jenkins on a Linux host machine

[jieryn]

RedHat user here.. Or you can just install Jenkins' repository flavor
of your choice without waiting for upstream:

https://pkg.jenkins.io/redhat/
https://pkg.jenkins.io/redhat-stable/

Jenkins really has lead the way and set the bar quite high for open
source projects and making itself available for users of all types and
risk level willingness.


On Tue, Jul 11, 2017 at 12:54 PM, John Mellor  wrote:
> There are competing update philosophies to consider:
> Ubuntu ships the latest (unstable) release of Jenkins all the time, while
> RedHat/CentOS/etc ships the stable version. I host on a Ubuntu VM, but
> definitely wish it was better tested. If stability is key, then Ubuntu may
> not be your best choice.
>
>
> On Tue, 2017-07-11 at 16:44 +, Jason LeMauk wrote:
>
> We are currently provisioning a physical server as our automation server. We
> are making considerations as far as what our native operating system should
> be on this physical machine.
>
> We are going to use a Linux OS as our operating system. From the Jenkins
> download page, I can see that Jenkins’ package distribution is available to
> Red Hat / Fedora / CentOS (which we will not be using), as well as Ubuntu /
> Debian. I also notice that a Generic Java package (WAR) distribution is
> available.
>
> ·Am I correct in assuming that if we use a non-Ubuntu / non-Debian
> operating system, we can still install Jenkins via the WAR distribution
> without issue?
>
> ·If we are not able to install via WAR without issue, are we
> relegated to using Debian / Ubuntu if we’re going to install Jenkins on a
> Linux machine (with the possibility of Red Hat / Fedora / CentOS ruled out)?
>
> It should probably be noted that we will likely install / upgrade on the
> Jenkins LTS release schedule.
>
> Thanks for any guidance from anybody who may have experience installing /
> maintaining a Jenkins instance on a Linux machine!
>
> Jason
>
> --
> 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/1499792036.3165.5.camel%40esentire.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/CAArU9iaceViyKf1bXt85WKi4M0aAyw5TQqOax5e5PB_vcebTaA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Installing / maintaining Jenkins on a Linux host machine

[John Mellor]

There are competing update philosophies to consider:
Ubuntu ships the latest (unstable) release of Jenkins all the time, while 
RedHat/CentOS/etc ships the stable version. I host on a Ubuntu VM, but 
definitely wish it was better tested. If stability is key, then Ubuntu may not 
be your best choice.


On Tue, 2017-07-11 at 16:44 +, Jason LeMauk wrote:

We are currently provisioning a physical server as our automation server. We 
are making considerations as far as what our native operating system should be 
on this physical machine.

We are going to use a Linux OS as our operating system. From the Jenkins 
download page, I can see that Jenkins’ package 
distribution is available to Red Hat / Fedora / CentOS (which we will not be 
using), as well as Ubuntu / Debian. I also notice that a Generic Java package 
(WAR) distribution is available.
·Am I correct in assuming that if we use a non-Ubuntu / non-Debian 
operating system, we can still install Jenkins via the WAR distribution without 
issue?
·If we are not able to install via WAR without issue, are we relegated 
to using Debian / Ubuntu if we’re going to install Jenkins on a Linux machine 
(with the possibility of Red Hat / Fedora / CentOS ruled out)?

It should probably be noted that we will likely install / upgrade on the 
Jenkins LTS release schedule.

Thanks for any guidance from anybody who may have experience installing / 
maintaining a Jenkins instance on a Linux machine!
Jason

-- 
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/1499792036.3165.5.camel%40esentire.com.
For more options, visit https://groups.google.com/d/optout.

Re: Installing / maintaining Jenkins on a Linux host machine

[Slide]

Just as a note, the WAR is not an installable thing. It's similar to a Java
JAR file, you "execute" the WAR file to run Jenkins. You can run the WAR on
any OS that has Java simply by doing java -jar PATH/TO/jenkins.war. There
are some command line options you can provide, but in general you are just
running the WAR file.

On Tue, Jul 11, 2017 at 9:44 AM Jason LeMauk <
jason.lem...@csquaredsystems.com> wrote:

> We are currently provisioning a physical server as our automation server.
> We are making considerations as far as what our native operating system
> should be on this physical machine.
>
> We are going to use a Linux OS as our operating system. From the Jenkins
> download page , I can see that Jenkins’
> package distribution is available to Red Hat / Fedora / CentOS (which we
> will not be using), as well as Ubuntu / Debian. I also notice that a
> Generic Java package (WAR) distribution is available.
>
> ·Am I correct in assuming that if we use a non-Ubuntu /
> non-Debian operating system, we can still install Jenkins via the WAR
> distribution without issue?
>
> ·If we are not able to install via WAR without issue, are we
> relegated to using Debian / Ubuntu if we’re going to install Jenkins on a
> Linux machine (with the possibility of Red Hat / Fedora / CentOS ruled out)?
>
> It should probably be noted that we will likely install / upgrade on the 
> Jenkins
> LTS release schedule .
>
> Thanks for any guidance from anybody who may have experience installing /
> maintaining a Jenkins instance on a Linux machine!
>
> Jason
>
> --
> 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/BY2PR12MB0599BE30A44301EF9566D3A689AE0%40BY2PR12MB0599.namprd12.prod.outlook.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/CAPiUgVc24MHXmheoGGze2xpjHzuzfTOAgiijtc9R75N%2Bc%3DdRuQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Installing / maintaining Jenkins on a Linux host machine

[Jason LeMauk]

We are currently provisioning a physical server as our automation server. We 
are making considerations as far as what our native operating system should be 
on this physical machine.

We are going to use a Linux OS as our operating system. From the Jenkins 
download page, I can see that Jenkins' package 
distribution is available to Red Hat / Fedora / CentOS (which we will not be 
using), as well as Ubuntu / Debian. I also notice that a Generic Java package 
(WAR) distribution is available.
*Am I correct in assuming that if we use a non-Ubuntu / non-Debian 
operating system, we can still install Jenkins via the WAR distribution without 
issue?
*If we are not able to install via WAR without issue, are we relegated 
to using Debian / Ubuntu if we're going to install Jenkins on a Linux machine 
(with the possibility of Red Hat / Fedora / CentOS ruled out)?

It should probably be noted that we will likely install / upgrade on the 
Jenkins LTS release schedule.

Thanks for any guidance from anybody who may have experience installing / 
maintaining a Jenkins instance on a Linux machine!
Jason

-- 
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/BY2PR12MB0599BE30A44301EF9566D3A689AE0%40BY2PR12MB0599.namprd12.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

Re: more meaningful description of a step

[Samuel Van Oort]

Hi Jakub, 
Custom captions (or more accurately, custom step argument descriptions) are 
supported on a per-Step type basis, so if your plugin is defining a new 
Step type, you can define how to display its inputs. There isn't anything 
coming immediately to allow you to customize captions individually -- 
though there is a future enhancement to allow attaching metadata to a step 
that might be displayed in some fashion.  But I assume that would be in 
addition to the caption, not in place of it.  Apologies for any confusion 
from the demos.

Cheers, 
Sam

On Tuesday, July 11, 2017 at 3:51:55 AM UTC-4, Jakub Pawlinski wrote:
>
> Hi, 
>
> Recently https://issues.jenkins-ci.org/browse/JENKINS-37324 was solved. 
>
> In sprint review Sam Van Oort 
>  
> demonstrated 
> the foundation for this https://www.youtube.com/watch?v=HhiUY70RVJY=510 
>
> He mentions there possibility of having custom caption but I have found no 
> way to actually achieve it.
>
> Maybe you know how I could make a custom description of step in 
> declarative pipeline, far too simple example:
>
> stages {
>   stage('A') { 
> steps {
>   bat "@echo Hello World"
>
> }
> }
> }
>
>
> How can I make it appear as "Hello World Step — Windows Batch Script" 
> instead of "@echo Hello World — Windows Batch Script" that I'm getting now.
>
>
> Thanks
>
> Jakub
>
>

-- 
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/e3a99fdb-d38b-4140-b035-c85a97a7b217%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Installing / maintaining Jenkins on a Linux host machine

[Peter Berghold]

My first two installations of Jenkins were on RHEL 6.x (old company
standard image) and the issues I used to have there is why I moved to
Ubuntu. (future company standard image)

On Tue, Jul 11, 2017 at 10:37 AM Jason LeMauk <
jason.lem...@csquaredsystems.com> wrote:

> Thank you for sharing your experience!
>
>
>
> The company is leaning towards not using Ubuntu / Debian, however we can
> still use it as our native operating system hosting our Jenkins instance if
> it is best practice / required. I have my own personal Jenkins instance
> setup on an Ubuntu machine and agree that the Ubuntu approach has been
> pretty straight forward.
>
>
>
> Does anybody have any experience installing / maintaining Jenkins on a
> non-Debian / non-Ubuntu Linux operating system (with Red Hat / Fedora /
> CentOS ruled out)?
>
> I am trying to discern whether or not we are relegated to a Debian /
> Ubuntu base operating system to host our Jenkins instance on (keeping in
> mind that Red Hat / Fedora / CentOS is ruled out). It should probably be
> noted that we will likely install / upgrade on the Jenkins LTS release
> schedule.
>
> Thanks again for any advice or guidance!
>
> -Jason
>
>
>
> *From:* jenkinsci-users@googlegroups.com [mailto:
> jenkinsci-users@googlegroups.com] *On Behalf Of *Peter Berghold
> *Sent:* Tuesday, July 11, 2017 10:28 AM
> *To:* jenkinsci-users@googlegroups.com
> *Subject:* Re: Installing / maintaining Jenkins on a Linux host machine
>
>
>
> I migrated my Jenkins installation over to Ubuntu from RHEL and haven't
> looked back.  My drivers may be different than yours and my reason was I am
> using Jenkins to perform CI on my Puppet environment.  Part of that is
> running some tests on the Puppet code before it is deployed and this works
> *much* better on Ubuntu that Red Hat which was getting rather McGiverish
> given all the hacks I did to get it to work.
>
>
>
> So I guess YMMV depending on what you are trying to accomplish.   If you
> are doing this in a corporate environment make sure with the powers that be
> whatever solution you pick meets with your list of acceptable solutions.
>
>
>
> On Tue, Jul 11, 2017 at 10:18 AM Jason LeMauk <
> jason.lem...@csquaredsystems.com> wrote:
>
> We are currently provisioning a physical server as our automation server.
> We are making considerations as far as what our native operating system
> should be on this physical machine.
>
>
>
> We are going to use a Linux OS as our operating system. From the Jenkins
> download page, https://jenkins.io/download/, I can see that Jenkins’
> package distribution is available to Red Hat / Fedora / CentOS (which we
> will not be using), as well as Ubuntu / Debian. I also notice that a
> Generic Java package (WAR) distribution is available.
>
>
>
> Am I correct in assuming that if we use a non-Ubuntu / non-Debian
> operating system, we can still install Jenkins via the WAR distribution
> without issue?
>
> Are we relegated to using Debian / Ubuntu if we’re going to install
> Jenkins on a Linux machine (with the possibility of Red Hat / Fedora /
> CentOS ruled out)?
>
>
>
> Thanks for any guidance from anybody who may have experience installing /
> maintaining a Jenkins instance on a Linux machine!
>
>
>
> -Jason
>
> --
> 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/BY2PR12MB0599526179AD04C5679959E489AE0%40BY2PR12MB0599.namprd12.prod.outlook.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/CAArvnv22Md4_0YZdgOuAE%2BpZs9Vu3g0BdHJn5qm%2BnemwoAv5sg%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/BY2PR12MB0599FD755ED454A44A65580589AE0%40BY2PR12MB0599.namprd12.prod.outlook.com
> 

Re: Unit Testing problem

[levan_taktakishvili]

Thanks a lot!! I will look into it. I just want to make it clear I am 
running Unit Test coded in c#. I am just building and executing test via 
Jenkins using MSbuild and running vstest.console.exe via windows batch 
command. 

On Friday, July 7, 2017 at 5:33:51 PM UTC-4, slide wrote:
>
> I would start on this wiki page 
> https://wiki.jenkins.io/display/JENKINS/Distributed+builds#Distributedbuilds-LaunchslaveagentviaJavaWebStart
> . 
>
> On Fri, Jul 7, 2017 at 2:27 PM  > wrote:
>
>> Thanks a lot! Could you please elaborate what do you mean under: "You 
>> would want to have a build agent running on the desktop using JNLP as a 
>> normal user that runs these tests."
>>
>> I am new to Jenkins..
>>
>> On Friday, July 7, 2017 at 2:15:00 PM UTC-4, slide wrote:
>>
>>> If you are running Jenkins as a service, it can't do stuff that 
>>> interacts with the desktop, e.g., Windows forms applications. You would 
>>> want to have a build agent running on the desktop using JNLP as a normal 
>>> user that runs these tests.
>>>
>>> On Fri, Jul 7, 2017 at 10:40 AM  
>>> wrote:
>>>
>> Dear All,

 I am running c# Unit Tests through Windows Jenkins and while executing 
 tests console output window shows me same error for all the tests:

 Error Message:
Test method Levan_Test threw exception: 

 System.ComponentModel.Win32Exception: Access is denied
 Stack Trace:
 at System.Windows.Forms.SendKeys.SendInput(Byte[] oldKeyboardState, 
 Queue previousEvents)
at System.Windows.Forms.SendKeys.Send(String keys, Control control, 
 Boolean wait)
at System.Windows.Forms.SendKeys.SendWait(String keys)


 cs:line 134



 It looks like there is some problem with permissions or power shell 
 command execution.


 Any tips, advise and recommendations will be much appreciated!!


 Thanks in advance,


 Levan

 -- 
 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/674a247d-2bad--bf95-afcbf6da4b77%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-use...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/1b4f3d7e-699b-4d79-92ef-92b6997d92c6%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/7617010b-3cd2-42be-bd9e-641dde441f44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub Branch Source: Configuring branch include/exclude from Jenkinsfile

[Stephen Connolly]

Oh but, with the JENKINS-43507 refactoring that is landing on Monday
(current ETA, my plan of tomorrow was rejected as not giving admins enough
time to upgrade easily for the security fixes only) you would be able to
write a custom behaviour in an extension plugin and that custom behaviour
would be able to tweak the include / exclude rules as you see fit

On 11 July 2017 at 07:46, Stephen Connolly 
wrote:

> Currently I recommend either using multiple org folders or just using
> multibranch projects directly.
>
> There is some embryonic discussion about how to pull configuration as code
> up from just the "branch" level to the "repository" and even the "group of
> repositories" levels... but nothing I would hold my breath waiting on
>
> On 11 July 2017 at 03:25, Leandro Lucarella  sociomantic.com> wrote:
>
>> Hi, I'm using the GitHub Branch Source plugin to setup an organization
>> folder. The organization is big and have different kind of projects
>> with different needs.
>>
>> Because of this, I need to override global organization configuration
>> (like include/exclude branches) in a per-project basis, so I was
>> wondering if there is any way to control this via the Jenkinsfile.
>>
>> If you know any other methods to deal with this, I'm more than
>> interested to hear about them.
>>
>> Thanks!
>>
>> --
>> Leandro Lucarella
>> Technical Development Lead
>> Sociomantic Labs GmbH 
>>
>> --
>> 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/ms
>> gid/jenkinsci-users/20170711122529.35356669%40labs-064.localdomain.
>> 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/CA%2BnPnMwvRyndTkUiJt5oDwUuc-OOxJ84X3j%3DvpQ2cDw8hkgMFA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub Branch Source: Configuring branch include/exclude from Jenkinsfile

[Stephen Connolly]

Currently I recommend either using multiple org folders or just using
multibranch projects directly.

There is some embryonic discussion about how to pull configuration as code
up from just the "branch" level to the "repository" and even the "group of
repositories" levels... but nothing I would hold my breath waiting on

On 11 July 2017 at 03:25, Leandro Lucarella <
leandro.lucare...@sociomantic.com> wrote:

> Hi, I'm using the GitHub Branch Source plugin to setup an organization
> folder. The organization is big and have different kind of projects
> with different needs.
>
> Because of this, I need to override global organization configuration
> (like include/exclude branches) in a per-project basis, so I was
> wondering if there is any way to control this via the Jenkinsfile.
>
> If you know any other methods to deal with this, I'm more than
> interested to hear about them.
>
> Thanks!
>
> --
> Leandro Lucarella
> Technical Development Lead
> Sociomantic Labs GmbH 
>
> --
> 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/20170711122529.35356669%40labs-064.localdomain.
> 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/CA%2BnPnMwG_A%2B9PSZ4sw-Xjq0ggTohmioAna8PnP_H9ezVgqZ7Qg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

RE: Installing / maintaining Jenkins on a Linux host machine

[Jason LeMauk]

Thank you for sharing your experience!

The company is leaning towards not using Ubuntu / Debian, however we can still 
use it as our native operating system hosting our Jenkins instance if it is 
best practice / required. I have my own personal Jenkins instance setup on an 
Ubuntu machine and agree that the Ubuntu approach has been pretty straight 
forward.

Does anybody have any experience installing / maintaining Jenkins on a 
non-Debian / non-Ubuntu Linux operating system (with Red Hat / Fedora / CentOS 
ruled out)?
I am trying to discern whether or not we are relegated to a Debian / Ubuntu 
base operating system to host our Jenkins instance on (keeping in mind that Red 
Hat / Fedora / CentOS is ruled out). It should probably be noted that we will 
likely install / upgrade on the Jenkins LTS release schedule.
Thanks again for any advice or guidance!

-Jason

From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Peter Berghold
Sent: Tuesday, July 11, 2017 10:28 AM
To: jenkinsci-users@googlegroups.com
Subject: Re: Installing / maintaining Jenkins on a Linux host machine

I migrated my Jenkins installation over to Ubuntu from RHEL and haven't looked 
back.  My drivers may be different than yours and my reason was I am using 
Jenkins to perform CI on my Puppet environment.  Part of that is running some 
tests on the Puppet code before it is deployed and this works *much* better on 
Ubuntu that Red Hat which was getting rather McGiverish given all the hacks I 
did to get it to work.

So I guess YMMV depending on what you are trying to accomplish.   If you are 
doing this in a corporate environment make sure with the powers that be 
whatever solution you pick meets with your list of acceptable solutions.

On Tue, Jul 11, 2017 at 10:18 AM Jason LeMauk 
> 
wrote:
We are currently provisioning a physical server as our automation server. We 
are making considerations as far as what our native operating system should be 
on this physical machine.

We are going to use a Linux OS as our operating system. From the Jenkins 
download page, https://jenkins.io/download/, I can see that Jenkins’ package 
distribution is available to Red Hat / Fedora / CentOS (which we will not be 
using), as well as Ubuntu / Debian. I also notice that a Generic Java package 
(WAR) distribution is available.

Am I correct in assuming that if we use a non-Ubuntu / non-Debian operating 
system, we can still install Jenkins via the WAR distribution without issue?
Are we relegated to using Debian / Ubuntu if we’re going to install Jenkins on 
a Linux machine (with the possibility of Red Hat / Fedora / CentOS ruled out)?

Thanks for any guidance from anybody who may have experience installing / 
maintaining a Jenkins instance on a Linux machine!


-Jason
--
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/BY2PR12MB0599526179AD04C5679959E489AE0%40BY2PR12MB0599.namprd12.prod.outlook.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/CAArvnv22Md4_0YZdgOuAE%2BpZs9Vu3g0BdHJn5qm%2BnemwoAv5sg%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/BY2PR12MB0599FD755ED454A44A65580589AE0%40BY2PR12MB0599.namprd12.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

Re: Installing / maintaining Jenkins on a Linux host machine

[Peter Berghold]

I migrated my Jenkins installation over to Ubuntu from RHEL and haven't
looked back.  My drivers may be different than yours and my reason was I am
using Jenkins to perform CI on my Puppet environment.  Part of that is
running some tests on the Puppet code before it is deployed and this works
*much* better on Ubuntu that Red Hat which was getting rather McGiverish
given all the hacks I did to get it to work.

So I guess YMMV depending on what you are trying to accomplish.   If you
are doing this in a corporate environment make sure with the powers that be
whatever solution you pick meets with your list of acceptable solutions.

On Tue, Jul 11, 2017 at 10:18 AM Jason LeMauk <
jason.lem...@csquaredsystems.com> wrote:

> We are currently provisioning a physical server as our automation server.
> We are making considerations as far as what our native operating system
> should be on this physical machine.
>
>
>
> We are going to use a Linux OS as our operating system. From the Jenkins
> download page, https://jenkins.io/download/, I can see that Jenkins’
> package distribution is available to Red Hat / Fedora / CentOS (which we
> will not be using), as well as Ubuntu / Debian. I also notice that a
> Generic Java package (WAR) distribution is available.
>
>
>
> Am I correct in assuming that if we use a non-Ubuntu / non-Debian
> operating system, we can still install Jenkins via the WAR distribution
> without issue?
>
> Are we relegated to using Debian / Ubuntu if we’re going to install
> Jenkins on a Linux machine (with the possibility of Red Hat / Fedora /
> CentOS ruled out)?
>
>
>
> Thanks for any guidance from anybody who may have experience installing /
> maintaining a Jenkins instance on a Linux machine!
>
>
>
> -Jason
>
> --
> 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/BY2PR12MB0599526179AD04C5679959E489AE0%40BY2PR12MB0599.namprd12.prod.outlook.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/CAArvnv22Md4_0YZdgOuAE%2BpZs9Vu3g0BdHJn5qm%2BnemwoAv5sg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Installing / maintaining Jenkins on a Linux host machine

[Jason LeMauk]

We are currently provisioning a physical server as our automation server. We 
are making considerations as far as what our native operating system should be 
on this physical machine.

We are going to use a Linux OS as our operating system. From the Jenkins 
download page, https://jenkins.io/download/, I can see that Jenkins' package 
distribution is available to Red Hat / Fedora / CentOS (which we will not be 
using), as well as Ubuntu / Debian. I also notice that a Generic Java package 
(WAR) distribution is available.

Am I correct in assuming that if we use a non-Ubuntu / non-Debian operating 
system, we can still install Jenkins via the WAR distribution without issue?
Are we relegated to using Debian / Ubuntu if we're going to install Jenkins on 
a Linux machine (with the possibility of Red Hat / Fedora / CentOS ruled out)?

Thanks for any guidance from anybody who may have experience installing / 
maintaining a Jenkins instance on a Linux machine!


-Jason

-- 
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/BY2PR12MB0599526179AD04C5679959E489AE0%40BY2PR12MB0599.namprd12.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

Declarative parallel stages

[Jakub Pawlinski]

In Blue Ocean 1.1.4 I have tried everything from and some own ideas, 
nothing seems to work:

stages {
  stage('Parallel1') { 
parallel 'branch1': {
  node('n1') { stage('Unit 1') { echo "1" } }
}, 'branch2': {
  node('n2') { stage('Unit 2') { echo "2" } }
}
  }
}
* Result: *Starting with version 0.5, steps in a stage must be in a steps 
block*

stages {
  steps {
parallel 'branch1': { 
  node('n1') { stage('Unit 1') { echo "1" } } 
}, 'branch2': {
  node('n2') { stage('Unit 2') { echo "2" } }
}
  }
}
* Result: *Invalid step "stage" used - not allowed in this context - The 
stage step cannot be used in Declarative Pipelines*

The only working version I have is:
stage ('Parallel1') {
steps {
parallel ("TEST A" : {
echo "TEST A"
},"TEST A" : {
echo "TEST B"
})
}
}

but this gives parallel steps not stages -- less readability and lack of 
control like:
stage ('TEST A') {
when {
expression { params.DO_TEST_A == true }
}
steps {
echo "TEST A"
}
}

Any ideas how to make it 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 jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/dfd80285-74d5-414a-9018-63b40328cd20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins supported branch

[Paolo Franchini]

I have done a yum update of 2.60.1-1.1 and had to commented on 
/etc/sysconfig/jenkins
##JENKINS_AJP_PORT="8009"

to have it run again. The node had to be updated to Java 1.8 because the 
slave.jar was not running on 1.6.



Il giorno lunedì 3 luglio 2017 10:53:36 UTC+1, Paolo Franchini ha scritto:
>
> Hi,
>
> is 1.651.1 a supported branch with security updates? Or is it and 
> end-of-life one? Couldn't find a page...
>
> cheers,
>
> Paolo
>
>  
>

-- 
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/f0711f19-f71b-4599-8465-0df84b02f0b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline powershell

[James Nord]

Given you can reliably reproduce if can you open a new ticket with the 
minimum steps to reproduce (this likely includes an msbuild project) and 
include your plugin versions, build logs and a stack trace then it is more 
likely to get fixed - if you can attach a support bundle 
 to the JIRA 
that will also go a long way in helping the dignosis

Many of the issues have no steps to reproduce and when we try to reproduce 
the issue we just can not, some of them we believe are just duplicates of 
JENKINS-34150  (fixed) 
but when the reporters neither confirm or deny this the issue can stay in 
limbo.  



On Tuesday, July 4, 2017 at 7:21:46 PM UTC+1, jer...@bodycad.com wrote:
>
> I'm not alone into this situation and this have been a problems for many 
> times for some:
>
>- https://issues.jenkins-ci.org/browse/JENKINS-28759 
>
> 
>- https://issues.jenkins-ci.org/browse/JENKINS-33164
>- https://issues.jenkins-ci.org/browse/JENKINS-42988
>
> And I probably miss some other, but some are open since 2015 and still are 
> unresolved. I was told this won't be fix and I should look forward to 
> powershell api instead that should not have this :-(
>
> I try to offer to test it, even gave an article that IMO seem to point to 
> a probable problems with the way the process is spawn and check, but seem 
> like I was lost and it was irrelevant. 
>
> http://www.javaworld.com/article/2071275/core-java/when-runtime-exec---won-t.html
>
> Looking at the source, this seem like the pitfall of Java process reading 
> was not avoid, might be at a lower level into CommandInterpreter but 
> since I'm no Java expert (more a C/C++/Python/Bash dev):
>
> https://github.com/jenkinsci/jenkins/blob/d111e2ac1658c8fa5fb768e7d1233613b4b9992d/core/src/main/java/hudson/tasks/BatchFile.java
>
> We have a broken CI for months now (ever since the master is no more a 
> single Windows machine master/slave, now we have a Linux Master and a 
> Windows slave, this behavior is appearing nearly every day, have to restart 
> the Jenkins service, cannot even cancel it via the web GUI). I now need the 
> multiple slave and my master on Linux and it ain't working with msbuild 
> batch nor powershell.
>
> I don't really have time to do this migration, but at some point my team 
> and I need my CI to be reliable, not something that hang every day where I 
> need an admin to log on the machine and restart Jenkins service since we 
> have a master and a slave hang. Really wish this would be resolved by now, 
> but I'm no longer holding my breath and it's a show stopper for us.
>
> Thanks,
> regards,
> Jerome
>

-- 
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/60131bf5-007c-495e-b197-909634ecf1ed%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

GitHub Branch Source: Configuring branch include/exclude from Jenkinsfile

[Leandro Lucarella]

Hi, I'm using the GitHub Branch Source plugin to setup an organization
folder. The organization is big and have different kind of projects
with different needs.

Because of this, I need to override global organization configuration
(like include/exclude branches) in a per-project basis, so I was
wondering if there is any way to control this via the Jenkinsfile.

If you know any other methods to deal with this, I'm more than
interested to hear about them.

Thanks!

-- 
Leandro Lucarella
Technical Development Lead
Sociomantic Labs GmbH 

-- 
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/20170711122529.35356669%40labs-064.localdomain.
For more options, visit https://groups.google.com/d/optout.


pgpgd5AXxB1vz.pgp
Description: OpenPGP digital signature

ParentJob and ParentBuild as properties

[Jakub Pawlinski]

Hi, 

In my declarative pipeline I'm using some data from parent job, till now I 
was processing those in single script clause and setting :

String ParentJobName = ""
String ParentBuildNumber = ""

pipeline {
stages {
stage ('Read Parameters') {
steps {
script {
def parentJob = GetParentJob(params.VERBOSE)
ParentJobName = parentJob.getName()

def parentBuild = GetParentBuild(parentJob, params.VERBOSE)
ParentBuildNumber = parentBuild.getNumber()
...

this was working fine, and both ParentJobName and ParentBuildNumer were 
populated fine, 

as I now wanted to do more than just getting single string I tried to 
declare

import org.jenkinsci.plugins.workflow.job.WorkflowJob
import org.jenkinsci.plugins.workflow.job.WorkflowRun

WorkflowJob ParentJob
WorkflowRun ParentBuild

outside of pipeline (like Strings previously)

but this ends up with java.io.NotSerializableException: 
org.jenkinsci.plugins.workflow.job.WorkflowJob exception

wonder if there is a way to achieve it, so I want have to evaluate those 
every time I want to use them.

thanks
Jakub

-- 
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/dad15c83-74c5-4803-ae78-91275a1fb130%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is pipeline timeout suppose to work?

[Jakub Pawlinski]

I use this on pipeline level and it works fine there, haven't tried on 
stage level tho.

pipeline {
options {
timeout(time: 12, unit: 'HOURS')
timestamps()
}
...
}

-- 
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/b0379985-baa7-4201-9b4f-5a19636151f1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: jenkins pipeline script params not recognized, bad substitution error

[Jakub Pawlinski]

try using double quote:

sh "python deploy.py ${params.version}"

I think single quotes do not evaluate strings

-- 
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/ee254c70-8c73-4a77-bf55-4c20e9613cfa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Safe to remove Server Sent Events (SSE) Gateway Plugin + its dependency??

[Baptiste Mathus]

In general, if Jenkins allows you to disable/remove it from the UI, it
should be safe. And now on /recent/ versions if you hover over it, you
should see the dependencies/dependents.

2017-07-07 11:59 GMT+02:00 Dan Tran :

> Make sense, i just removed Blue Ocean from a couple of my Jenkins
>
> -D
>
>
>
> On Friday, July 7, 2017 at 12:45:56 AM UTC-7, Stephen Connolly wrote:
>>
>> Iirc that is used by blue ocean
>>
>> On Fri 7 Jul 2017 at 08:33, Dan Tran  wrote:
>>
>>>
>>>
>>> Hi,
>>>
>>> I tend to remove those plugins that i dont use.   However the name of
>>> this plugin sounds like a infra type,  do i really need it?
>>>
>>> Thanks
>>>
>>> -Dan
>>>
>>> --
>>> 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/ms
>>> gid/jenkinsci-users/14c7fbe9-3483-43ac-af2d-1187fb6887f6%
>>> 40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> Sent from my phone
>>
> --
> 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/0992eed5-bb9d-4840-9a81-7b873d8690d0%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/CANWgJS7DMyc_TQwT8XNqHfDWhSpU3qNb_E9kWzVUnWW2nuRVoA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins cookies vulnerabilities

[lea.i.abrugena]

Hi Everyone, 

Our Jenkins has cookies security vulnerabilities, please see below. Does
anyone of you experience the same thing? Any idea how to fix it? 

The set cookie for these 3 are not secured: 
  -ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE 
  -iconSize 
  -hudson_auto_refresh 


Set-Cookie:hudson_auto_refresh=false;Path=/;Expires=Thu, 10-Aug-2017
04:05:22 GMT;Max-Age=2592000 



--
View this message in context: 
http://jenkins-ci.361315.n4.nabble.com/Jenkins-cookies-vulnerabilities-tp4900241.html
Sent from the Jenkins users mailing list archive at Nabble.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/1499745878805-4900241.post%40n4.nabble.com.
For more options, visit https://groups.google.com/d/optout.

Re: Credentialid with github is not working in pipeline script on jenkins slave

[Hound G]

I am observing this issue with  freestyle job as well. Username & password 
(provided through credentials plugin) is not working with github git 
cloning.
Any help will be highly appreciated.

Thanks,
Hound 


On Friday, July 7, 2017 at 5:48:19 PM UTC-7, Hound G wrote:
>
> I am testing pipeline configuration script with below code, 
>
> #!groovy
>
> node("jenkins-slave") {
>   try {
> stage("Checkout") {  
>  checkout([$class: 'GitSCM',
>  branches: [[name: 'test']], 
>  doGenerateSubmoduleConfigurations: false, 
>  userRemoteConfigs: [[
>  credentialsId: '6ad7b0af-30fd-4ca6-a80e-e629b5d7f212', 
>  url: 'https://githubent.abc.com/test/ops.git'
>  ]]]
>  )
> }
>   } catch (error) {
> throw error
>   }
>
>
> But I am getting the below error . I have configured credentials 
> correctly(attached)
>
>
> > git rev-parse --is-inside-work-tree # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url https://githubent.abc.com/test/ops.git # 
> timeout=10
> Fetching upstream changes from https://githubent.abc.com/test/ops.git
>  > git --version # timeout=10
> using GIT_ASKPASS to set credentials cso-cv-tools
>  > git fetch --tags --progress https://githubent.abc.com/test/ops.git 
> +refs/heads/*:refs/remotes/origin/*
> ERROR: Error fetching remote repo 'origin'
> hudson.plugins.git.GitException: Failed to fetch from 
> https://githubent.abc.com/test/ops.git
> at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:809)
> at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1076)
> at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1107)
> at 
> org.jenkinsci.plugins.workflow.steps.scm.SCMStep.checkout(SCMStep.java:109)
> at 
> org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:83)
> at 
> org.jenkinsci.plugins.workflow.steps.scm.SCMStep$StepExecutionImpl.run(SCMStep.java:73)
> at 
> org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1$1.call(AbstractSynchronousNonBlockingStepExecution.java:47)
> at hudson.security.ACL.impersonate(ACL.java:260)
> at 
> org.jenkinsci.plugins.workflow.steps.AbstractSynchronousNonBlockingStepExecution$1.run(AbstractSynchronousNonBlockingStepExecution.java:44)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: hudson.plugins.git.GitException: Command "git fetch --tags 
> --progress https://githubent.abc.com/test/ops.git 
> +refs/heads/*:refs/remotes/origin/*" returned status code 128:
> stdout: 
> stderr: error: The requested URL returned error: 403 Forbidden while 
> accessing https://githubent.abc.com/test/ops.git/info/refs
>
> fatal: HTTP request failed
>
> at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1903)
> at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandWithCredentials(CliGitAPIImpl.java:1622)
> at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl.access$300(CliGitAPIImpl.java:71)
> at 
> org.jenkinsci.plugins.gitclient.CliGitAPIImpl$1.execute(CliGitAPIImpl.java:348)
> at 
> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
> at 
> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
> at hudson.remoting.UserRequest.perform(UserRequest.java:153)
> at hudson.remoting.UserRequest.perform(UserRequest.java:50)
> at hudson.remoting.Request$2.run(Request.java:336)
> at 
> hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:748)
> at ..remote call to jenkins-slave(Native Method)
> at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1545)
> at hudson.remoting.UserResponse.retrieve(UserRequest.java:253)
> at hudson.remoting.Channel.call(Channel.java:830)
> at 
> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
> at com.sun.proxy.$Proxy81.execute(Unknown Source)
> at 

more meaningful description of a step

[Jakub Pawlinski]

Hi, 

Recently https://issues.jenkins-ci.org/browse/JENKINS-37324 was solved. 

In sprint review Sam Van Oort 
 
demonstrated 
the foundation for this https://www.youtube.com/watch?v=HhiUY70RVJY=510 

He mentions there possibility of having custom caption but I have found no 
way to actually achieve it.

Maybe you know how I could make a custom description of step in declarative 
pipeline, far too simple example:

stages {
  stage('A') { 
steps {
  bat "@echo Hello World"

}
}
}


How can I make it appear as "Hello World Step — Windows Batch Script" 
instead of "@echo Hello World — Windows Batch Script" that I'm getting now.


Thanks

Jakub

-- 
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/bb2c89c5-4971-432d-b442-885b34951139%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.