RE: Jenkins Stickers

[Jason LeMauk]

Hi Alyssa!

I just saw some information on LinkedIn actually about Jenkins World. I wish I 
could be there, however I will not be attending this year.
I am located in the North-Eastern United States. Is there an email best to 
reach you at? We’d love to have some dev stickers!

Thank you for your help,
Jason


From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Alyssa Tong
Sent: Friday, July 14, 2017 12:15 PM
To: jenkinsci-users 
Subject: Re: Jenkins Stickers

Hi Jason,

can you let me know where you are located? Will you be at Jenkins 
World? If you are we'll have 
plenty of stickers ready for you.

thnx
alyssa

On Wed, Jul 12, 2017 at 9:42 AM, J0991 
> 
wrote:
hello!

I have been working these past few months to get Jenkins going for our
companies projects. I'd also love to get a few stickers for the team here.
If anybody else may have any stickers available my team would gladly take
them!

Thank you,
Jason



--
View this message in context: 
http://jenkins-ci.361315.n4.nabble.com/Jenkins-Stickers-tp4900135p4900450.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/1499877762688-4900450.post%40n4.nabble.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/CAMBsfbtsF9eWpRhTLgWdN83tzX5vdQO_iyZUXdsZd6Na80KB8Q%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/BY2PR12MB0599FD21EC5531E2299DEEE389AD0%40BY2PR12MB0599.namprd12.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins Distributed Builds: Permission tiers for project-based matrix authorization strategy

[Jason LeMauk]

Hello Jenkins Community!
I had some questions for those of you fairly experienced with administering / 
maintaining a Jenkins distributed build system.
I have a single Jenkins Master, and three or four Jenkins SSH Agents / Slaves 
running in VirtualBox (Jenkins host machine is running Ubuntu 14.04 LTS as well 
as the Jenkins Agents / Slave virtual machines).
The goal with the distributed build system is to achieve separate build / test 
/ deployment environments for each project. The concern that having all the 
software installed on the same machine (Jenkins host machine), could 
potentially pose issues for Jenkins Master's machine as well as software needed 
to build / test / deploy one team's applications could affect other teams and 
hold them up unnecessarily.

*My question is what is the best method for authorization strategy when 
dealing with multiple teams in a Jenkins Distributed Builds setup?
We are going to be using LDAP for our security realm (via the LDAP plugin), if 
that makes any difference. My obvious initial thoughts are to use the 
project-based matrix authorization strategy:

1.  Ideally I'd like to have our global Jenkins Administrators setup with 
permissions to perform any actions within Jenkins globally..

2.  I'd like to have a lower level administrator (Project Administrators, 
likely team leads), who are granted all permissions on a job / project basis. 
Jenkins Global Administrators decide the permissions for these users.

3.  The last tier of users are average Jenkins Users. The permissions for 
these users would be set by Project Administrators as they see fit. I believe 
Global Jenkins Administrators would need to add the users and then Jenkins 
Project Level Administrators can assign permissions for their team's project / 
job.
So in the Jenkins distributed build system we have three tiers of users, each 
with lesser permissions than the last:

1.  Global Jenkins Administrators: Manages Project Level Administrators and 
Average Jenkins Users

2.  Project Level Administrators Manages Average Jenkins Users for their 
project / job.

3.  Average Jenkins Users: Lowest level user with the most restrictive 
permissions. Doesn't not manage Jenkins for any other users.

-Is this a typical setup when administering Jenkins Distributed Build 
system with multiple teams involved?

-Am I understanding the user of the Project-based matrix authorization 
strategy correctly?

-Does anybody have any experience with a different access control 
approach?
Thank you to anyone who has any experience with maintaining a distributed build 
system involving several teams!

-J

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

Downstream jobs: You have no permission to build...

[Jason LeMauk]

Hello Jenkins Community!
I currently have an upstream job (Backup) triggering a downstream job 
(BackupCleanup).  The trigger is set as a post-build action of build other 
projects (on the upstream job).
However, when I select the project to build in the post-build action, I receive 
a warning that "You have no permission to build...". Please see below:
[cid:image001.png@01D2FBFB.CE7E9150]
It should be noted that the upstream job is able to be run successfully which 
triggers a successful run of the downstream job. It seems like my user has the 
correct permissions based on the job run results. What could be causing this?
Thank you guys for any help!

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

Jenkins downstream jobs not triggered after enabling security

[Jason LeMauk]

I currently have two jenkins freestyle jobs setup. One is titled 
AutomatedBackup, and the other AutomatedBackupCleanup. Upon successful 
completion of the AutomatedBackup job, the AutomatedBackupCleanup job is 
triggered.

I have recently enabled security on my Jenkins instance, which appears to have 
broken the trigger between the two jobs. The console output from the 
AutomatedBackup job looks like so:

Started by user Chuck Norris
Running as Chuck Norris
Building on master in workspace /var/lib/jenkins/jobs/AutomatedBackup/workspace
[workspace] $ /bin/sh -xe /tmp/hudson2315047344125249883.sh
+ cp -a /var/lib/jenkins /opt/jenkinsbackups
+ cd /opt/jenkinsbackups
+ date +%Y%m%d-%H%M%S
+ tar czf jenkinsBackup_20170712-151641.tar.gz jenkins/

+ rm -rf /opt/jenkinsbackups/jenkins/
+ git add --all

+ git commit -m Jenkins Automated Backup
[master 85151d9] Jenkins Automated Backup
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 jenkinsBackup_20170712-151641.tar.gz
+ git push

To ssh://git@191.55.63.157:7999/at/jenkinsbackup.git
   5fe7767..85151d9  master -> master
Running as anonymous cannot even see AutomatedBackup for trigger from 
AutomatedBackupCleanup
Finished: SUCCESS

Each job can be run with success, however the first job is no longer triggering 
the second job.
Any ideas?

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/BY2PR12MB0599553C844F30D4D71CA0C989AF0%40BY2PR12MB0599.namprd12.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins ACL matrix

[Jason LeMauk]

Hello Jenkins Community!
I am documenting our authorization strategy implemented for our Jenkins 
instance. We currently use a 'Project-Based' authorization strategy made 
available via the Matrix Authorization Strategy plugin for Jenkins. In the 
formal documentation (as well as the property notes within the Jenkins web UI), 
state that "This mode is an extension to "Matrix-based security" that allows 
additional ACL matrix to be defined for each project separately (which is done 
on the job configuration screen.)".
My question is; what exactly does ACL stand for? I understand the ACL is the 
permissions grid, however I'm unable to find exactly what this acronym stands 
for. 'Access Control... ?'.
Thanks in advance for any information!

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

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

[Jason LeMauk]

Thank you for the advice! I discovered the setting you mention yesterday: 
Configure Jenkins > Usage.
As you mentioned, the default setting is ‘use this node as much as possible’ 
for the ‘Usage’ property. Changing this value to ‘Only build jobs with label 
expressions matching this node’ does appear to be the solution I am looking for.
As my goal is to prevent a user from not setting a Jenkins Agent / Slave which 
would execute the job on Jenkins Master, the user will have to explicitly 
specify the ‘Master’ to build on, which will prevent jobs from defaulting to 
the Master for execution.
The job restrictions plugin does look like it does the trick as far as 
preventing users from specifying the Master to execute jobs on, however at this 
point it might be slightly more restrictive than I need at this moment in time. 
I also checked out the open 
issues<https://issues.jenkins-ci.org/browse/JENKINS-39373?jql=project%20%3D%20JENKINS%20AND%20status%20in%20(Open%2C%20%22In%20Progress%22%2C%20Reopened)%20AND%20component%20%3D%20%27job-restrictions-plugin%27>
 associated with the plugin, and it doesn’t look too buggy :D It’s also not up 
for adoption at this time. I’ll definitely consider this plugin in the future 
if an event prompts needing to completely restrict the Master from jobs being 
executed.

From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Michael Pailloncy
Sent: Tuesday, July 11, 2017 6:30 PM
To: jenkinsci-users@googlegroups.com
Subject: Re: Jenkins Distributed Builds: Restricting users from configuring 
jobs with Jenkins Master's executors

By default, the master is configured with "Use this node as much as possible" : 
http://${JENKINS_URL}/computer/(master)/configure<http://$%7bJENKINS_URL%7d/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 
<jason.lem...@csquaredsystems.com<mailto:jason.lem...@csquaredsystems.com>>:
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<mailto: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<https://groups.google.com/d/msgid/jenkinsci-users/BY2PR12MB059992ED76D9D6B99481DD7F89AE0%40BY2PR12MB0599.namprd12.prod.outlook.com?utm_medium=email_source=footer>.
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<mailto: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<https://groups.google.com/d/msgid/jenkinsci-users/CAPO77c2zEbVbJh6D8L1rZCNZ4sa%3Dz9cDFwjr4DEYc8fmTXk2tQ%40mail.gmail.com?utm_medium=email_source=footer>.
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/BY2PR12MB05999AA44A56EC04B933F69289AF0%40BY2PR12MB0599.namprd12.prod.outlook.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 
<jason.lem...@csquaredsystems.com<mailto: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?
•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<https://jenkins.io/changelog-stable/>.

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<mailto: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<https://groups.google.com/d/msgid/jenkinsci-users/BY2PR12MB0599BE30A44301EF9566D3A689AE0%40BY2PR12MB0599.namprd12.prod.outlook.com?utm_medium=email_source=footer>.
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<mailto: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<https://groups.google.com/d/msgid/jenkinsci-users/CAPiUgVc24MHXmheoGGze2xpjHzuzfTOAgiijtc9R75N%2Bc%3DdRuQ%40mail.gmail.com?utm_medium=email_source=footer>.
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.

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: 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 
<jason.lem...@csquaredsystems.com<mailto: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<mailto: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<https://groups.google.com/d/msgid/jenkinsci-users/BY2PR12MB0599526179AD04C5679959E489AE0%40BY2PR12MB0599.namprd12.prod.outlook.com?utm_medium=email_source=footer>.
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<mailto: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<https://groups.google.com/d/msgid/jenkinsci-users/CAArvnv22Md4_0YZdgOuAE%2BpZs9Vu3g0BdHJn5qm%2BnemwoAv5sg%40mail.gmail.com?utm_medium=email_source=footer>.
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.

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.

Distributed Builds: Software required to build only installed on build node?

[Jason LeMauk]

I have a distributed build system in place (1 Jenkins Master and several build 
nodes).

I have a piece of software required for a project's build whose licensing is 
tied to the MAC address of the machine which has the software installed 
(ioncube encoder).

Am I correct in assuming that when the project is built, the ioncube encoder 
will not need to be installed on the Jenkins Master machine but will need to be 
installed on the Jenkins Agent / Slave machine?

Thanks in advance for any advice / help!

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

Jenkins.log file location on Ubuntu

[Jason LeMauk]

Hello!

I am trying to access Jenkins logging outside of the web UI. The goal is to 
have a log available in the event that Jenkins web UI is inaccessible.

>From what I have seen, system logging is stored in a jenkins.log file.

I'm unable to locate this file on my system. It should be noted that my Jenkins 
host machine is an Ubuntu 14.04 desktop. I have tried using the find command, 
as well as searching using the Ubuntu file explorer.

I can see the system logs in the web UI, however I cannot search from command 
line or GUI to find the file. No results are returned.
When I check the /var/log/jenkins directory, I see a config file but nothing 
else: config -> /etc/sv/jenkins/log/config.

Does anybody know what I'm missing here? I would assume that if I can see 
Jenkins system logging in the web UI that there would be a jenkins.log file 
somewhere on the system.

Thanks in advance for any help!

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

RE: Jenkins LTS Release Line: Frequency / Process of Upgrading Jenkins on LTS release schedule

[Jason LeMauk]

If a renamed copy of the old WAR file exists in $JENKINS_HOME directory, 
wouldn’t it just be a matter of changing the previous jenkins war from 
jenkins.war.old to jenkins.war, and removing the newly copied Jenkins WAR from 
the $JENKINS_HOME directory? Isn’t that essentially the undo of the upgrade if 
a problem occurs?

And just to be clear, the previous Jenkins WAR file is never copied out of the 
$JENKINS_HOME directory; it always stays in the same directory and is just 
renamed. The copy to safety happens in my Jenkins job which copies and tars the 
$JENKINS_HOME directory to a local directory as well as source control.

I’m more trying to use that as a way to quickly rollback the upgrade (a matter 
of renaming the previous WAR file and deleting the new one), if anything 
problematic arises.

From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Mark Waite
Sent: Monday, July 03, 2017 4:54 PM
To: jenkinsci-users@googlegroups.com
Subject: Re: Jenkins LTS Release Line: Frequency / Process of Upgrading Jenkins 
on LTS release schedule

Replies inline for clarity.
On Mon, Jul 3, 2017 at 2:46 PM Jason LeMauk 
<jason.lem...@csquaredsystems.com<mailto:jason.lem...@csquaredsystems.com>> 
wrote:
Thank you for the information! As a matter of fact we are using Ubuntu.

As part of the upgrade process, I’ve seen Jenkins administrators do the 
following:

1.  Stop Jenkins running as a service.

2.  Rename Jenkins current WAR file to jenkins.war.old.

I didn't find a lot of value from a "rename to old" step, since an upgrade 
failure will likely force me to either press forward with a fix / work around, 
or that I undo the installation of the upgrade.  I don't remember the last time 
I had to undo, but 
https://askubuntu.com/questions/138284/how-to-downgrade-a-package-via-apt-get 
describes how you can use apt to install a specific version.  That should 
provide the equivalent of a "downgrade", without bothering with copying the 
file to safety.


3.  Copy the new WAR file into the $JENKINS_HOME directory.

4.  Start Jenkins running as a service.

5.  Verify Jenkins is working as expected.

6.  Remove the jenkins.war.old file from the $JENKINS_HOME directory.

I’d like to keep the old WAR file in the directory until we can verify the new 
WAR works as expected.
For this reason, I believe it may not be better to wipe out the original WAR 
file in $JENKINS_HOME with an apt upgrade.

Also, if the Jenkins package is installed from ‘apt’, wont a sudo apt get 
update / upgrade automatically upgrade my Jenkins instance?


Yes it will upgrade your Jenkins instance unless you pin that Jenkins version.

Mark Waite

Thank you again for your advice!
-Jason

From: jenkinsci-users@googlegroups.com<mailto:jenkinsci-users@googlegroups.com> 
[mailto:jenkinsci-users@googlegroups.com<mailto:jenkinsci-users@googlegroups.com>]
 On Behalf Of Mark Waite
Sent: Monday, July 03, 2017 4:34 PM
To: jenkinsci-users@googlegroups.com<mailto:jenkinsci-users@googlegroups.com>
Subject: Re: Jenkins LTS Release Line: Frequency / Process of Upgrading Jenkins 
on LTS release schedule

That is the technique I've used, though I've preferred to simplify the upgrade 
process by using either Debian or Ubuntu as the host operating system, then 
installing Jenkins  from the "apt" package manager.  That simplifies the 
"upgrade and copy the war" step.  It doesn't really remove any of the other 
steps.

If you're a Red Hat / CentOS type, then you'll use the rpm based distribution 
for the same benefit.

Mark Waite

On Mon, Jul 3, 2017 at 2:20 PM Jason LeMauk 
<jason.lem...@csquaredsystems.com<mailto:jason.lem...@csquaredsystems.com>> 
wrote:
I am currently working to setup a Jenkins server for continuous integration. 
One area of Jenkins maintenance I am looking at is Jenkins upgrades.

As gaining access to new Jenkins features is less important to our setup than 
receiving important bug fixes and general system stability, I am considering 
upgrading our Jenkins instance on the LTS release schedule. It should be noted 
that we are currently working with Jenkins version 2.46.3 and would start this 
schedule by upgrading to Jenkins version 2.60.1.

In looking at the documentation for [Jenkins LTS Release Line][1], it looks 
like this would involve upgrading our Jenkins from the previous LTS version to 
the new LTS version every 6 - 9 weeks:

> The cycle starts with picking an LTS baseline at week 0. Then, there
> is a two week period for backporting followed by two weeks for testing
> the release candidate resulting in the release of X.1. Backporting and
> RC testing is repeated twice, producing X.2 and X.3. This concludes
> the cycle for a given baseline and the new one is started immediately.
>
> The baseline release is typically between 2-5 weeks old when it is
> chosen, so X.1 LTS releases

RE: Jenkins LTS Release Line: Frequency / Process of Upgrading Jenkins on LTS release schedule

[Jason LeMauk]

Thank you for the information! As a matter of fact we are using Ubuntu.

As part of the upgrade process, I’ve seen Jenkins administrators do the 
following:

1.  Stop Jenkins running as a service.

2.  Rename Jenkins current WAR file to jenkins.war.old.

3.  Copy the new WAR file into the $JENKINS_HOME directory.

4.  Start Jenkins running as a service.

5.  Verify Jenkins is working as expected.

6.  Remove the jenkins.war.old file from the $JENKINS_HOME directory.

I’d like to keep the old WAR file in the directory until we can verify the new 
WAR works as expected.
For this reason, I believe it may not be better to wipe out the original WAR 
file in $JENKINS_HOME with an apt upgrade.

Also, if the Jenkins package is installed from ‘apt’, wont a sudo apt get 
update / upgrade automatically upgrade my Jenkins instance?

Thank you again for your advice!
-Jason

From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Mark Waite
Sent: Monday, July 03, 2017 4:34 PM
To: jenkinsci-users@googlegroups.com
Subject: Re: Jenkins LTS Release Line: Frequency / Process of Upgrading Jenkins 
on LTS release schedule

That is the technique I've used, though I've preferred to simplify the upgrade 
process by using either Debian or Ubuntu as the host operating system, then 
installing Jenkins  from the "apt" package manager.  That simplifies the 
"upgrade and copy the war" step.  It doesn't really remove any of the other 
steps.

If you're a Red Hat / CentOS type, then you'll use the rpm based distribution 
for the same benefit.

Mark Waite

On Mon, Jul 3, 2017 at 2:20 PM Jason LeMauk 
<jason.lem...@csquaredsystems.com<mailto:jason.lem...@csquaredsystems.com>> 
wrote:
I am currently working to setup a Jenkins server for continuous integration. 
One area of Jenkins maintenance I am looking at is Jenkins upgrades.

As gaining access to new Jenkins features is less important to our setup than 
receiving important bug fixes and general system stability, I am considering 
upgrading our Jenkins instance on the LTS release schedule. It should be noted 
that we are currently working with Jenkins version 2.46.3 and would start this 
schedule by upgrading to Jenkins version 2.60.1.

In looking at the documentation for [Jenkins LTS Release Line][1], it looks 
like this would involve upgrading our Jenkins from the previous LTS version to 
the new LTS version every 6 - 9 weeks:

> The cycle starts with picking an LTS baseline at week 0. Then, there
> is a two week period for backporting followed by two weeks for testing
> the release candidate resulting in the release of X.1. Backporting and
> RC testing is repeated twice, producing X.2 and X.3. This concludes
> the cycle for a given baseline and the new one is started immediately.
>
> The baseline release is typically between 2-5 weeks old when it is
> chosen, so X.1 LTS releases are published about 6-9 weeks after their
> baseline.

Am I correct in this understanding that if we were to keep up with the LTS 
release schedule we would be upgrading our Jenkins instance about every 6 - 9 
weeks?

Also, from what I have seen, if your Jenkins instance is installed via Jenkins 
WAR file, then the process for upgrading the Jenkins instance to the most 
recent Jenkins LTS version is:

1. Stop Jenkins running as a service.
2. Back up the Jenkins $HOME_DIRECTORY.
3. Download the latest LTS WAR file.
4. Replace the WAR file currently in $JENKINS_HOME directory with the
newest LTS WAR.
5. Start Jenkins running as a service.
6. Upgrade any plugins if necessary.
7. Restart Jenkins as a service if necessary for plugin installation.
7. Work out any Jenkins job issues caused by upgraded plugins.

Is there anything here I'm missing as far as getting our Jenkins instance onto 
the LTS release schedule? Is this generally best practice? Just wanted to get 
some input and advice from those with experience maintaining a Jenkins instance 
on the LTS release schedule.

  [1]: https://jenkins.io/download/lts/
--
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<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/BY2PR12MB0599FFD3DBC9C44D93D0E8C589D60%40BY2PR12MB0599.namprd12.prod.outlook.com<https://groups.google.com/d/msgid/jenkinsci-users/BY2PR12MB0599FFD3DBC9C44D93D0E8C589D60%40BY2PR12MB0599.namprd12.prod.outlook.com?utm_medium=email_source=footer>.
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

RE: Jenkins Distributed Builds: Parameterized Jobs and the Ansible Plugin for Jenkins

[Jason LeMauk]

Great thank you! That was exactly the information I was looking for.


From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Richard Ginga
Sent: Monday, July 03, 2017 1:39 PM
To: jenkinsci-users@googlegroups.com
Subject: Re: Jenkins Distributed Builds: Parameterized Jobs and the Ansible 
Plugin for Jenkins

Jason, all parameters are available in the environment of any slave/agent just 
like they were available when built on the master.

as far as ansible and python,  I would say you would need to install them on 
any build machine.

On Mon, Jul 3, 2017 at 11:26 AM, Jason LeMauk 
<jason.lem...@csquaredsystems.com<mailto:jason.lem...@csquaredsystems.com>> 
wrote:
I currently have a parameterized build setup on my Jenkins master. As these 
parameters are accessible as environment variables, I'm using them in an 
ansible script via the ansible plugin.

We also have a distributed build architecture in place.

With a distributed build system, if this project is built on an Agent node as 
oppose to the Master node, will my ansible scripts still have access to the 
environment variables exposed in the parameterized build?
Also, I believe that in order to do this we will need the ansible plugin, 
ansible and python installed on the Jenkins Master's machine (as we will need 
to configure ansible in Jenkins in order to use the ansible plugin).

Would ansible and python also need to be installed on the Jenkins Agent in 
order to carry out the job on the Agent?

Thanks for any help! I'm fairly new to distributed builds and appreciate your 
patience and advice.

- 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<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/BY2PR12MB0599D4A2431F622350938B9D89D60%40BY2PR12MB0599.namprd12.prod.outlook.com<https://groups.google.com/d/msgid/jenkinsci-users/BY2PR12MB0599D4A2431F622350938B9D89D60%40BY2PR12MB0599.namprd12.prod.outlook.com?utm_medium=email_source=footer>.
For more options, visit https://groups.google.com/d/optout.



--
Dick Ginga
Build Engineer
rgi...@disruptorbeam.com<mailto:rgi...@disruptorbeam.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<mailto:jenkinsci-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-users/CAL3PpaUza3g5ZHWrJAS_ZUes%3DQXJGaLvTVdk%3DEq8SzJeUm-fyw%40mail.gmail.com<https://groups.google.com/d/msgid/jenkinsci-users/CAL3PpaUza3g5ZHWrJAS_ZUes%3DQXJGaLvTVdk%3DEq8SzJeUm-fyw%40mail.gmail.com?utm_medium=email_source=footer>.
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/BY2PR12MB05993058E2C59E626A3EC45689D60%40BY2PR12MB0599.namprd12.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins LTS Release Line: Frequency / Process of Upgrading Jenkins on LTS release schedule

[Jason LeMauk]

I am currently working to setup a Jenkins server for continuous integration. 
One area of Jenkins maintenance I am looking at is Jenkins upgrades.

As gaining access to new Jenkins features is less important to our setup than 
receiving important bug fixes and general system stability, I am considering 
upgrading our Jenkins instance on the LTS release schedule. It should be noted 
that we are currently working with Jenkins version 2.46.3 and would start this 
schedule by upgrading to Jenkins version 2.60.1.

In looking at the documentation for [Jenkins LTS Release Line][1], it looks 
like this would involve upgrading our Jenkins from the previous LTS version to 
the new LTS version every 6 - 9 weeks:

> The cycle starts with picking an LTS baseline at week 0. Then, there
> is a two week period for backporting followed by two weeks for testing
> the release candidate resulting in the release of X.1. Backporting and
> RC testing is repeated twice, producing X.2 and X.3. This concludes
> the cycle for a given baseline and the new one is started immediately.
>
> The baseline release is typically between 2-5 weeks old when it is
> chosen, so X.1 LTS releases are published about 6-9 weeks after their
> baseline.

Am I correct in this understanding that if we were to keep up with the LTS 
release schedule we would be upgrading our Jenkins instance about every 6 - 9 
weeks?

Also, from what I have seen, if your Jenkins instance is installed via Jenkins 
WAR file, then the process for upgrading the Jenkins instance to the most 
recent Jenkins LTS version is:

1. Stop Jenkins running as a service.
2. Back up the Jenkins $HOME_DIRECTORY.
3. Download the latest LTS WAR file.
4. Replace the WAR file currently in $JENKINS_HOME directory with the
newest LTS WAR.
5. Start Jenkins running as a service.
6. Upgrade any plugins if necessary.
7. Restart Jenkins as a service if necessary for plugin installation.
7. Work out any Jenkins job issues caused by upgraded plugins.

Is there anything here I'm missing as far as getting our Jenkins instance onto 
the LTS release schedule? Is this generally best practice? Just wanted to get 
some input and advice from those with experience maintaining a Jenkins instance 
on the LTS release schedule.

  [1]: https://jenkins.io/download/lts/

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

Jenkins Distributed Builds: Parameterized Jobs and the Ansible Plugin for Jenkins

[Jason LeMauk]

I currently have a parameterized build setup on my Jenkins master. As these 
parameters are accessible as environment variables, I'm using them in an 
ansible script via the ansible plugin.

We also have a distributed build architecture in place.

With a distributed build system, if this project is built on an Agent node as 
oppose to the Master node, will my ansible scripts still have access to the 
environment variables exposed in the parameterized build?
Also, I believe that in order to do this we will need the ansible plugin, 
ansible and python installed on the Jenkins Master's machine (as we will need 
to configure ansible in Jenkins in order to use the ansible plugin).

Would ansible and python also need to be installed on the Jenkins Agent in 
order to carry out the job on the Agent?

Thanks for any help! I'm fairly new to distributed builds and appreciate your 
patience and advice.

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