RE: Discard old build artifacts?

2017-07-20 Thread Breitbach, Steffen
My bad. So it's actually a little different:

https://github.com/jenkinsci/pipeline-model-definition-plugin/wiki/Pipeline-properties


From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Dirk Heinrichs
Sent: Friday, July 21, 2017 8:09 AM
To: jenkinsci-users@googlegroups.com
Subject: Re: Discard old build artifacts?

On 21.07.2017 08:05, Breitbach, Steffen wrote:
I think the Log Rotator Plugin does what you're looking for. Check out 
https://github.com/jenkinsci/job-dsl-plugin/wiki/The-Configure-Block

From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of James Green
Subject: Discard old build artifacts?

But I'm generating gigs of artifacts that I don't need. Is there a way of 
discarding these within a Jenkinsfile?

JobDSL != Jenkinsfile

Bye...

Dirk
--
Dirk Heinrichs
Senior Systems Engineer, Delivery Pipeline
OpenTextTM Discovery | Recommind
Email: dhein...@opentext.com
Website: www.recommind.de

Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach

Vertretungsberechtigte Geschäftsführer John Marshall Doolittle, Gordon Davies, 
Roger Illing, Registergericht Amtsgericht Bonn, Registernummer HRB 10646

This e-mail may contain confidential and/or privileged information. If you are 
not the intended recipient (or have received this e-mail in error) please 
notify the sender immediately and destroy this e-mail. Any unauthorized 
copying, disclosure or distribution of the material in this e-mail is strictly 
forbidden

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. 
Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten 
haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. 
Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail sind nicht 
gestattet.
--
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/058618bc-f884-fff1-d3bd-e0703e0b7968%40opentext.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/5E63738AB9896844AF1601A1D094677317A71A45%40SMBXKO1.cgm.ag.
For more options, visit https://groups.google.com/d/optout.


Re: Discard old build artifacts?

2017-07-20 Thread Dirk Heinrichs
On 21.07.2017 08:05, Breitbach, Steffen wrote:

> I think the Log Rotator Plugin does what you're looking for. Check out
> https://github.com/jenkinsci/job-dsl-plugin/wiki/The-Configure-Block
> 
>  
> *From:*jenkinsci-users@googlegroups.com
> [mailto:jenkinsci-users@googlegroups.com] *On Behalf Of *James Green
> *Subject:* Discard old build artifacts?
>  
> But I'm generating gigs of artifacts that I don't need. Is there a way
> of discarding these within a Jenkinsfile?

JobDSL != Jenkinsfile

Bye...

Dirk
-- 
*Dirk Heinrichs*
Senior Systems Engineer, Delivery Pipeline
OpenText^TM Discovery | Recommind
*Email*: dhein...@opentext.com 
*Website*: www.recommind.de 

Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach

Vertretungsberechtigte Geschäftsführer John Marshall Doolittle, Gordon
Davies, Roger Illing, Registergericht Amtsgericht Bonn, Registernummer
HRB 10646

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail sind nicht gestattet.

-- 
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/058618bc-f884-fff1-d3bd-e0703e0b7968%40opentext.com.
For more options, visit https://groups.google.com/d/optout.


RE: Discard old build artifacts?

2017-07-20 Thread Breitbach, Steffen
Hi James,

I think the Log Rotator Plugin does what you're looking for. Check out 
https://github.com/jenkinsci/job-dsl-plugin/wiki/The-Configure-Block

Steffen

From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of James Green
Sent: Thursday, July 20, 2017 6:38 PM
To: jenkinsci-users@googlegroups.com
Subject: Discard old build artifacts?

I don't want to remove the entire job - having the logs of what the SCM commit 
was and build output logs is really useful alongside the Jenkins build number.

But I'm generating gigs of artifacts that I don't need. Is there a way of 
discarding these within a Jenkinsfile?

Thanks,

James

--
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/CAMH6%2BawDBdLSg4x7k4BhF--sFDHMMxx%2Ba%2BNyx79a-qkzwgZC8A%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/5E63738AB9896844AF1601A1D094677317A719F6%40SMBXKO1.cgm.ag.
For more options, visit https://groups.google.com/d/optout.


RE: How to get a Second Instance of Jenkins Running with the latest release and the Backup Strategy to Incorporate

2017-07-20 Thread Palanilkunnathil Melemuriyil, Vinod P
Thanks a lot Artur for your valuable inputs. 

Thank You

-Original Message-
From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Artur Szostak
Sent: Thursday, July 20, 2017 6:07 PM
To: jenkinsci-users@googlegroups.com
Subject: Re: How to get a Second Instance of Jenkins Running with the latest 
release and the Backup Strategy to Incorporate

Jenkins has no built in enterprise grade backup or migration strategy. You have 
to deal with all of this yourself.

With regards to migration, for small Jenkins instances you should be OK with:
1) Stopping the new Jenkins instance.
2) Copying the XML configuration files and job directory from $JENKINS_HOME 
from the old instance to the new instance.
3) Start the new instance up.
For larger and more complex setups the probability of this working tends 
towards zero. In that case the better strategy is copying the configuration and 
jobs over one at a time while going through a stop, copy, start and verify 
cycle each time. This is extremely painful though. If you can it is better to 
script migration of the jobs through the REST APIs, while both instances are up 
and running. You will still need to consider how to verify your migration.
If you do have a large setup and have not done so already you might want to 
take this opportunity to put in the effort and build your new instance so that 
the whole configuration is created automatically (ideally in a virtualised 
server). You will again have to use the REST APIs and tools like 
jenkins-job-builder. For larger setups I think this becomes a must, since the 
default Jenkins GUI is not scalable for administrative tasks. Try maintain >60 
build nodes and >1000 jobs with the existing Jenkins GUI and you will know what 
I mean.

With regards to backup, if you want a true and full backup strategy then I am 
not aware of any built in facility or plugin that can help. There are a few 
that will skim the XML configs of the jobs and a few other bits and pieces, but 
nothing that will restore a server to its original state if the whole thing 
burns down.
When I first setup our Jenkins server a few years ago the best option I could 
come up with was using 
https://wiki.jenkins.io/display/JENKINS/Exclusive+Execution+Plugin and rsync 
within an exclusive job to snapshot $JENKINS_HOME (in our case excluding any 
job workspaces, just keeping their configs and build logs). The snapshot itself 
can then be backed up properly in the background while Jenkins returns to work.
This worked OK, but it is not very scalable. At some point the snapshot starts 
taking way too long. An improved strategy I plan to implement on our next 
upgrade is to use Btrfs (ZFS can work also) as the underlying data store for 
#JENKINS_HOME. This will allow to perform copy on write snapshots which are 
very quick.
I will also switch to using 
https://wiki.jenkins.io/display/JENKINS/Build+Blocker+Plugin rather than 
https://wiki.jenkins.io/display/JENKINS/Exclusive+Execution+Plugin.
Note that I am relying on the fact that Jenkins does not do any serious I/Os 
while the snapshotting is taking place. Otherwise the backup will never be 
consistent. This is a major pitfall and until Jenkins provides a real quiescing 
infrastructure ,100% safe online backups will never be possible. However, I 
believe that with Btrfs one can mitigate this by performing 2 COW snapshots 
with a small interval of time between them and see if there is any difference 
between those snapshots. If not then there is a high probability that you have 
a consistent backup.
If you do not care for online backups then you can of course avoid the 
consistency problem by shutting down Jenkins, doing the backup and then 
starting it up again. But our Jenkins instance takes > 40min to start, so I 
stick to online backups, since I want to do them regularly.

Hope you find some of this useful.

Cheers

Artur

From: jenkinsci-users@googlegroups.com  on 
behalf of Palanilkunnathil Melemuriyil, Vinod P 

Sent: 17 July 2017 17:40:20
To: jenkinsci-users@googlegroups.com
Subject: How to get a Second Instance of Jenkins Running with the latest 
release and the Backup Strategy to Incorporate

Hi All,

We have an old version (1.651.3) of Jenkins running on a server (RHEL) with 
many jobs configured to automate our day to day activities.
I would like to migrate to the latest stable release of Jenkins.

For that, I would want to have a second instance of Jenkins running (with the 
latest stable release of Jenkins) on the same server and slowly migrate all the 
jobs and users to the new jenkins instance after thorough testing.

Can anyone guide me on how all the jobs and all the configurations which I have 
already in place in the old instance can be migrated in one go (maybe by 
copying some directories or files from the older version) to the new instance 
and I start testing the new instance to see if all jobs are running wi

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

2017-07-20 Thread Oleg Nenashev
Regarding the executions on the master, I believe that Job Restrictions is 
a right way to do it since it also protects you from Flyweight tasks. I am 
the plugin creator, so I may be a bit biased though.

I have an example of the master protection here 
.
 
It is configuration-as-code, but you can do the same in the Web UI. There 
is also a brief description in my recent JAM talk in Oslo: slides 29-32 


Hopefully it helps,

четверг, 20 июля 2017 г., 13:56:25 UTC+3 пользователь Artur Szostak написал:
>
> I think you cannot do it properly using the project-based authorization 
> strategy. But you should be able to do it with the combination of the 
> following two plugins: 
> https://wiki.jenkins.io/display/JENKINS/Ownership+Plugin 
> https://wiki.jenkins.io/display/JENKINS/Role+Strategy+Plugin 
>
> I have only recently become aware of this plugin combination and started 
> playing around with it. So if you are willing to change your security model 
> then the best is to look at the documentation. See the section "Restricting 
> executions on agents" from the following: 
>
> https://github.com/jenkinsci/ownership-plugin/blob/master/doc/OwnershipBasedSecurity.md
>  
> 
>  
>
> Cheers 
>
> Artur 
>
>  
> From: jenkins...@googlegroups.com  <
> jenkins...@googlegroups.com > on behalf of Jason LeMauk <
> jason@csquaredsystems.com > 
> Sent: 11 July 2017 20:41:23 
> To: jenkins...@googlegroups.com  
> Subject: Jenkins Distributed Builds: Restricting users from configuring 
> jobs with Jenkins Master's executors 
>
> 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-use...@googlegroups.com  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&utm_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/9402f1c6-013b-4480-86af-de1dcfe610dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Jenkins Job Builder - one template with different params

2017-07-20 Thread Mike Giles
About 48 hours new to yaml and JJB as we migrate from Hudson to Jenkins and 
have thousands of jobs to move (hence trying to find a better way to manage 
them).  In one case we have 4 sets of jobs (about 20 each) that have very 
similar options except for some of the params.  For the other jenkins 
options in these jobs, I am making variables under the job definitions and 
using them in the shell builder calls and in the job names and such.  I 
also have some defaults that are being used on a global level.

Currently I am implementing different templates for each set of jobs as the 
choice: params have different options per user.  I don't want to set these 
per job (even though I am not sure how to pass a nested option like that), 
as it would mean a lot of maintenance whenever I need to update them across 
a whole pack of jobs.  I want to make sure we can use JJB like the config 
slicing plugin on steroids... change in one place for a whole bunch of 
jobs.  So, basically everything but these dynamic items can be altered in 
one template that all the 80 jobs use.

I am thinking there has to be a way for me to define different choice: 
blocks and key them based on one of the params used in the job: 
definitions.  For example 

jobs:
- 'dev-deploy':
type: dev
product: productA
deploy_user: "{dev_user}"

jobs:
- 'qa-deploy':
type: qa
product: productA
deploy_user: "{qa_user}"

Now these are obviously using different templates (dev-deploy and 
qa-deploy).  The difference between the templates may be as small as email 
recipients and a choice: param like:

parameters:
- choice:
name: DEPLOY_SERVER
choices: ['hostname1', 'hostname2']

In the qa-deploy template it might look like:

parameters:
- choice:
name: DEPLOY_SERVER
choices: ['hostname3', 'hostname4']

I would like to do something like setup a default (which does not work like 
this but you get the idea):

- defaults:
name: global
dev_deploy_hosts: ['hostname1', 'hostname2']
qa_deploy_hosts: ['hostname3', 'hostname4']

And then use those in a single template that all the jobs leverage, since 
the job names are parameterized.  Maybe a multi-level interpolation or 
something like:

parameters:
   - choice:
   name: DEPLOY_SERVER
   choices: {{type}_deploy_hosts}

Where in the above type changes to dev or qa and then the value is replaced 
from globals by {dev_deploy_hosts} or {qa_deploy_hosts}

What am I missing?  I am sure it is either not possible or something simple 
I am missing.  Hoping it is the second.

Thanks.

P.S. Bonus points for an issue we also came across.  I can't seem to use 
variables in nested jenkins blocks.  For example this works:
properties:
- build-discarder:
days-to-keep: -1
num-to-keep: 15
artifact-days-to-keep: -1
artifact-num-to-keep: -1

But this does not when I set a defaults: of builds_to_keep: 10
properties:
- build-discarder:
days-to-keep: -1
num-to-keep: {builds_to_keep}
artifact-days-to-keep: -1
artifact-num-to-keep: -1


-- 
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/8c94ed79-c9d2-4a38-8f67-182558830e53%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Discard old build artifacts?

2017-07-20 Thread James Green
I don't want to remove the entire job - having the logs of what the SCM
commit was and build output logs is really useful alongside the Jenkins
build number.

But I'm generating gigs of artifacts that I don't need. Is there a way of
discarding these within a Jenkinsfile?

Thanks,

James

-- 
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/CAMH6%2BawDBdLSg4x7k4BhF--sFDHMMxx%2Ba%2BNyx79a-qkzwgZC8A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-07-20 Thread leandro . lucarella
BTW, I've seen in Jenkins docs, in the "Steps Reference" that comes with 
Jenkins, that there is a class GitHubSCMSource, I guess there is no way to 
use that as a step to change the configuration from the Jenkinsfile, right? 
It seems to have all the include/exclude conigurations there but I never 
understood how to use these "classes" in a Jenkinsfile.

Thanks!

On Tuesday, 11 July 2017 16:46:16 UTC+2, 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  > 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-use...@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/3638df72-e07b-4b33-9d8c-01091b7ccc3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2017-07-20 Thread leandro . lucarella
Mmm, not the answer I was hoping for, but fair enough.

Thanks!

On Tuesday, 11 July 2017 16:46:16 UTC+2, 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  > 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-use...@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/51187518-0b1b-45a2-bd32-e960e3f16b07%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: How to let jenkins clone and use the branch I hope?

2017-07-20 Thread Dirk Heinrichs
On 20.07.2017 09:11, Mellisa wrote:

> --data-binary "tag_branch:origin\/CI"

Not sure, but I'd say you don't need to escape the "/".

HTH...

Dirk
-- 
*Dirk Heinrichs*
Senior Systems Engineer, Delivery Pipeline
OpenText^TM Discovery | Recommind
*Email*: dhein...@opentext.com 
*Website*: www.recommind.de 

Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach

Vertretungsberechtigte Geschäftsführer John Marshall Doolittle, Gordon
Davies, Roger Illing, Registergericht Amtsgericht Bonn, Registernummer
HRB 10646

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden

Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie
die unbefugte Weitergabe dieser Mail sind nicht gestattet.

-- 
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/64f33072-15e7-fab3-a1c3-adaf40d2e2c5%40opentext.com.
For more options, visit https://groups.google.com/d/optout.


Pipeline Editor Shows only If it is a GitHub repository

2017-07-20 Thread Zied Yaich
Hello

I have been working with jenkins for a very short period, so my question 
may be a bit basic, but I can't find an answer for it, so I will appreciate 
it if you guys help me  understand.

I'm integrating Blue Ocean plugin and trying to re-do my company projects 
with the  pipeline editor, whenever I run a project from GitHub, everything 
is just fine, otherwise when I take a project from BitBucket or GitLab It 
seems that the Pipeline editor it's not supported in those private 
platforms.

I've tried to run the same project from GitHub and BitBucket, and I can't 
find the pipeline Editor Button.
Is this some kind of bugs or this is meant to be this way. In either way 
can you help me to better understand !

Thanks in advance
Cordially..

-- 
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/49cda00e-26ae-467f-a3c1-fe13629a6c98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: How to get a Second Instance of Jenkins Running with the latest release and the Backup Strategy to Incorporate

2017-07-20 Thread Artur Szostak
Jenkins has no built in enterprise grade backup or migration strategy. You have 
to deal with all of this yourself.

With regards to migration, for small Jenkins instances you should be OK with:
1) Stopping the new Jenkins instance.
2) Copying the XML configuration files and job directory from $JENKINS_HOME 
from the old instance to the new instance.
3) Start the new instance up.
For larger and more complex setups the probability of this working tends 
towards zero. In that case the better strategy is copying the configuration and 
jobs over one at a time while going through a stop, copy, start and verify 
cycle each time. This is extremely painful though. If you can it is better to 
script migration of the jobs through the REST APIs, while both instances are up 
and running. You will still need to consider how to verify your migration.
If you do have a large setup and have not done so already you might want to 
take this opportunity to put in the effort and build your new instance so that 
the whole configuration is created automatically (ideally in a virtualised 
server). You will again have to use the REST APIs and tools like 
jenkins-job-builder. For larger setups I think this becomes a must, since the 
default Jenkins GUI is not scalable for administrative tasks. Try maintain >60 
build nodes and >1000 jobs with the existing Jenkins GUI and you will know what 
I mean.

With regards to backup, if you want a true and full backup strategy then I am 
not aware of any built in facility or plugin that can help. There are a few 
that will skim the XML configs of the jobs and a few other bits and pieces, but 
nothing that will restore a server to its original state if the whole thing 
burns down.
When I first setup our Jenkins server a few years ago the best option I could 
come up with was using 
https://wiki.jenkins.io/display/JENKINS/Exclusive+Execution+Plugin and rsync 
within an exclusive job to snapshot $JENKINS_HOME (in our case excluding any 
job workspaces, just keeping their configs and build logs). The snapshot itself 
can then be backed up properly in the background while Jenkins returns to work.
This worked OK, but it is not very scalable. At some point the snapshot starts 
taking way too long. An improved strategy I plan to implement on our next 
upgrade is to use Btrfs (ZFS can work also) as the underlying data store for 
#JENKINS_HOME. This will allow to perform copy on write snapshots which are 
very quick.
I will also switch to using 
https://wiki.jenkins.io/display/JENKINS/Build+Blocker+Plugin rather than 
https://wiki.jenkins.io/display/JENKINS/Exclusive+Execution+Plugin.
Note that I am relying on the fact that Jenkins does not do any serious I/Os 
while the snapshotting is taking place. Otherwise the backup will never be 
consistent. This is a major pitfall and until Jenkins provides a real quiescing 
infrastructure ,100% safe online backups will never be possible. However, I 
believe that with Btrfs one can mitigate this by performing 2 COW snapshots 
with a small interval of time between them and see if there is any difference 
between those snapshots. If not then there is a high probability that you have 
a consistent backup.
If you do not care for online backups then you can of course avoid the 
consistency problem by shutting down Jenkins, doing the backup and then 
starting it up again. But our Jenkins instance takes > 40min to start, so I 
stick to online backups, since I want to do them regularly.

Hope you find some of this useful.

Cheers

Artur

From: jenkinsci-users@googlegroups.com  on 
behalf of Palanilkunnathil Melemuriyil, Vinod P 

Sent: 17 July 2017 17:40:20
To: jenkinsci-users@googlegroups.com
Subject: How to get a Second Instance of Jenkins Running with the latest 
release and the Backup Strategy to Incorporate

Hi All,

We have an old version (1.651.3) of Jenkins running on a server (RHEL) with 
many jobs configured to automate our day to day activities.
I would like to migrate to the latest stable release of Jenkins.

For that, I would want to have a second instance of Jenkins running (with the 
latest stable release of Jenkins) on the same server and slowly migrate all the 
jobs and users to the new jenkins instance after thorough testing.

Can anyone guide me on how all the jobs and all the configurations which I have 
already in place in the old instance can be migrated in one go (maybe by 
copying some directories or files from the older version) to the new instance 
and I start testing the new instance to see if all jobs are running without any 
issues.

What would be the best approach to migrate to the latest version of Jenkins and 
at the same time have the old version running till we decommission it in due 
course.

Also right now, we don’t have a backup strategy in place for our Jenkins 
instance. I am wondering if by chance the Jenkins instance crashes how do I 
recover it?
What are the directories/configuration files

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

2017-07-20 Thread Artur Szostak
I think you cannot do it properly using the project-based authorization 
strategy. But you should be able to do it with the combination of the following 
two plugins:
https://wiki.jenkins.io/display/JENKINS/Ownership+Plugin
https://wiki.jenkins.io/display/JENKINS/Role+Strategy+Plugin

I have only recently become aware of this plugin combination and started 
playing around with it. So if you are willing to change your security model 
then the best is to look at the documentation. See the section "Restricting 
executions on agents" from the following:
https://github.com/jenkinsci/ownership-plugin/blob/master/doc/OwnershipBasedSecurity.md

Cheers

Artur


From: jenkinsci-users@googlegroups.com  on 
behalf of Jason LeMauk 
Sent: 11 July 2017 20:41:23
To: jenkinsci-users@googlegroups.com
Subject: Jenkins Distributed Builds: Restricting users from configuring jobs 
with Jenkins Master's executors

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.

-- 
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/bc714dc405924475820d5db4efe20db4%40partner.eso.org.
For more options, visit https://groups.google.com/d/optout.


Jenkinsfile doubts

2017-07-20 Thread Joaquin Henriquez
HI ppl,

I have the bellow Jenkinsfile and I want to either:

1)  Include the node sectin inside the pipeline (but needs to run on the 
master while the other will run on the slave)

2)  Either I need the jiraTicket variable to be pass to the Building stage 
(actually is is not cause it only last until the end of the node)

Thanks for the help

Jo

properties([[$class: 'GitLabConnectionProperty', gitLabConnection: 'GitLab']])
node {
   stage('JIRA') {
def issue = [fields: [ project: [key: 'JIRAKEY'],
 assignee: [name: 'devops'],
 summary: "Jenkins Build ${env.JOB_NAME} 
#${env.BUILD_ID} Ticket",
 description: "New JIRA Ticket created on 
${env.BUILD_TIMESTAMP} from Jenkins. URL: ${env.JENKINS_URL}",
 priority: [name: 'Medium'],
 labels: ['Jenkins'],
 issuetype: [name: 'Jenkins']]]

def newIssue = jiraNewIssue issue: issue, site: 'JIRASITE'

def jiraTicket = newIssue.data.key
echo "${jiraTicket}"
}
}
pipeline {
  agent { label 'Slave_CentOS7' }
stages {
stage('Build') {
steps {
echo 'Building..'
//jiraAddComment idOrKey: 
"${jiraTicket}", comment: 'test comment'
sh 'ls -lrt'
}
}
stage('Test') {
steps {
echo 'Testing..'
sh 'ls -lrt'
}
}
stage('Deploy') {
steps {
echo 'Deploying'
}
}
}
post {
  always {
echo 'Always'
  }
  success {
  updateGitlabCommitStatus(name: 'build', state: 
'success')
  }
  failure {
updateGitlabCommitStatus(name: 'build', state: 'failed')
  }
}
}

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


AWT-EventQueue-0/3021

2017-07-20 Thread LnT
Hi,

my jenkins server stops working with below error.

Any clue ?


-
Jul 19, 2017 12:41:40 PM 
hudson.init.impl.InstallUncaughtExceptionHandler$DefaultUncaughtExceptionHandler
 
uncaughtException
SEVERE: A thread (AWT-EventQueue-0/3021) died unexpectedly due to an 
uncaught exception, this may leave your Jenkins in a bad way and is usually 
indicative of a bug in the code.
java.lang.ClassCastException: sun.java2d.HeadlessGraphicsEnvironment cannot 
be cast to sun.awt.Win32GraphicsEnvironment
at sun.awt.windows.WToolkit$5.run(WToolkit.java:771)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:312)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:745)
at java.awt.EventQueue.access$300(EventQueue.java:103)
at java.awt.EventQueue$3.run(EventQueue.java:706)
at java.awt.EventQueue$3.run(EventQueue.java:704)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:715)
at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
at 
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
-


Regards,
LnT

-- 
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/97b07a8a-bad7-4b84-992c-5efacb550af4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Multiline regex not working in Build Failure Analyzer Plugin

2017-07-20 Thread Shiran
Eric thank you for your help.
Yet, this is still not working for me.

Could you give me an example of a Jenkins log of yours and a multiline in 
BFA that actually work? (maybe you could attach a screen shot of the BFA 
page in Jenkins.)

Thanks! :)

On Wednesday, July 19, 2017 at 4:38:24 PM UTC+3, Eric Pyle wrote:
>
> I think the pattern has to match full lines, so you would need:
>
> ".*Segmentation fault.*busy: Error! failed to run driver tests"
>
> in the multiline regex definition box in BFA. No need to put .* in 
> parentheses.
>
> Eric
>
> On 7/19/2017 2:48 AM, Shiran wrote:
>
> Hi, 
>
> I've been struggling for days in making the multiline build log indication 
> work.
>
> I couldn’t find any example in the net, I had it working in a Groovy 
> console but not in Jenkins.
>
>  
>
> *This is the Jenkins log.  I want to detect the yellow part – if I find 
> these two yellow strings are the indication of the failure:*
>
> *22:14:36* 2017-07-10 22:14:36   Test INFO:  busy: -E- T:78008253
>
> *22:14:36* 2017-07-10 22:14:36   Test INFO:  busy: Segmentation fault
>
> *22:14:36* 2017-07-10 22:14:36   Test INFO:  busy: Error! failed to 
> run driver tests
>
> *22:14:36* 2017-07-10 22:14:36   Test INFO:  busy: 
> /opt/cve_driver_test
>
> *22:14:36* 2017-07-10 22:14:36   Test INFO:  busy: Return1Code
>
>  
>
> I tried to find this pattern in a groovy console and succeeded:
>
> def pattern = "(?s)Segmentation fault(.*)busy: Error! failed to run 
> driver tests"
> def example1 = text.find(pattern)  //=> found!
>
>
> *How do I make it work Jenkins?*
>
> *Thanks!*
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-use...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-users/f71e269b-1929-46ee-80a5-874f8e69b72c%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> -- 
> Eric Pyle
> Siemens PLM Software
> Lebanon, NH
> +1 603-277-3060eric...@siemens.com http://www.siemens.com/plm
>
>

-- 
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/7d55726e-d7df-4138-b9a9-54c9095d57d8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.