Re: Visualizing tests separately from different stages of a pipeline

[Joshua Harlow]

Do I need to just give each capture a unique filename?

I was trying this earlier and it appears giving them the same name only 
caused the first to show up on the UI :(

Perhaps though I was doing something wrong...

On Wednesday, August 17, 2016 at 9:24:37 PM UTC-7, James Dumay wrote:
>
> Joshua, I don't think there is anything stopping you from recording the 
> test results in the Pipeline you have described. Jenkins will capture them 
> wherever you ask it to with the JUnitArchiver however it won't record what 
> stage it captured them from (there is an outstanding Improvement in JIRA 
> for this).
>
> I hope I didn't miss anything
>
> On Thu, Aug 18, 2016 at 2:19 PM Joshua Harlow  > wrote:
>
>> I to would like something like this,
>>
>> It seems to be a common thing to do and a real weakness of the pipeline 
>> style,
>>
>> If people are supposed to setup complex pipelines in a pipeline file then 
>> its pretty important that there be a way to ship out multiple result files,
>>
>> Even if they are successful, discarding information, especially in 
>> jenkins seems bad.
>>
>> Because in my view the 'Build-->Test-->Integration Test-->Deploy' is a 
>> real simple example and I personally plan on doing a much bigger pipeline 
>> like,
>>
>> Build project Y--> Unit Test Y--> Local functional test Y 
>>  
>> |
>>   
>>---> Integration Test Y + Z -> Perf test Y + Z -> Request deploy to 
>> stage ---> (wait) -> Integration Test -> Perf test --> Deploy to prod ---> 
>> (wait) -->  
>>  
>> |
>> Build project Z-->Unit Test Z--> Local functional test Z
>>
>> And in that there will be more than Y and Z (all done in parallel with a 
>> join), at each stage having test results,
>>
>> Now maybe pipelines aren't meant to approach this complexity? Though if 
>> they are not, then I'm not quite sure what they are really useful for 
>> (because I can do the same thing in ansible/equivalent),
>>
>> -Josh
>>
>>
>> On Sunday, July 24, 2016 at 1:47:37 PM UTC-7, Arnaud wrote:
>>
>>> Yes, like Matrix job but not only. Separate tests by stage between unit 
>>> tests and integration tests looks important for me.
>>>
>>> Arnaud.
>>>
>> 2016-07-24 21:12 GMT+02:00 James Dumay :
>>>
>> Are you describing a situation here that's closer to what the Matrix job 
 type caters to? Eg Operating System X Browser Version or something?

 If you don't mind drawing a picture, that could help me get across what 
 you're use case entails :)

 On Mon, 25 Jul 2016 at 4:24 AM, Arnaud bourree  
 wrote:

>>> Hi
>
> I'm interested in test grouped by stage: we'd like to run the same set 
> of test in different context: tests have same name and each can work in 
> one 
> context and not in other. Grouped by stage we can see easily which 
> context 
> has issue 
>
> Regards 
>
> Arnaud Bourrée 
>
> Le 22 juil. 2016 14:07, "ST"  a écrit :
>
 James,
>
> Interesting statement "successful tests is an edge case" - I've never 
> thought about it this way, but if all tests pass I dont need to know 
> anything else, so true I guess :-)
>
>
> Our use case is (with daily releases):
> * unit tests
> * itests that set up their own data (most of our itests)
> * itests relying on specific test data (i.e. they have to be run 
> against a specific test database)
> * itests that test typical API consumption (to ensure we haven't 
> broken existing API)
>
> So when:
> (A) a test fails I'd like to know into which category it falls to 
> better assess any consequences and being able to make a first guess about 
> what the root cause could be
> (B) many tests fail it's useful to know whether all of them fall into 
> same test category.
>
> Putting tests into a specific java package (*.itest.api.* etc.) would 
> probably help to solve (A) but not (B). 
>
> Best regards,
>  stefan.
>
>
>
> On Thu, Jul 21, 2016 at 7:12 PM, James Dumay  
> wrote:
>
> Hi Stefan,
>>
>> There is no way to do this with Pipeline today. However, when 
>> designing the new test reporting screen 
>>  in Blue 
>> Ocean I did have someone ask if we could group them by stage. 
>>
>> The problem I saw here is that most peoples pipelines look like this:
>>
>> Build-->Test-->Integration Test-->Deploy
>>
>> If any tests fail in "Test" then you would not see any tests 
>> displayed for "Integration Tests" as they were not executed - rendering 
>> the 

Re: Visualizing tests separately from different stages of a pipeline

[James Dumay]

Joshua, I don't think there is anything stopping you from recording the
test results in the Pipeline you have described. Jenkins will capture them
wherever you ask it to with the JUnitArchiver however it won't record what
stage it captured them from (there is an outstanding Improvement in JIRA
for this).

I hope I didn't miss anything

On Thu, Aug 18, 2016 at 2:19 PM Joshua Harlow  wrote:

> I to would like something like this,
>
> It seems to be a common thing to do and a real weakness of the pipeline
> style,
>
> If people are supposed to setup complex pipelines in a pipeline file then
> its pretty important that there be a way to ship out multiple result files,
>
> Even if they are successful, discarding information, especially in jenkins
> seems bad.
>
> Because in my view the 'Build-->Test-->Integration Test-->Deploy' is a
> real simple example and I personally plan on doing a much bigger pipeline
> like,
>
> Build project Y--> Unit Test Y--> Local functional test Y
>
>   |
>
>---> Integration Test Y + Z -> Perf test Y + Z -> Request deploy to
> stage ---> (wait) -> Integration Test -> Perf test --> Deploy to prod --->
> (wait) -->  
>
> |
> Build project Z-->Unit Test Z--> Local functional test Z
>
> And in that there will be more than Y and Z (all done in parallel with a
> join), at each stage having test results,
>
> Now maybe pipelines aren't meant to approach this complexity? Though if
> they are not, then I'm not quite sure what they are really useful for
> (because I can do the same thing in ansible/equivalent),
>
> -Josh
>
>
> On Sunday, July 24, 2016 at 1:47:37 PM UTC-7, Arnaud wrote:
>
>> Yes, like Matrix job but not only. Separate tests by stage between unit
>> tests and integration tests looks important for me.
>>
>> Arnaud.
>>
> 2016-07-24 21:12 GMT+02:00 James Dumay :
>>
> Are you describing a situation here that's closer to what the Matrix job
>>> type caters to? Eg Operating System X Browser Version or something?
>>>
>>> If you don't mind drawing a picture, that could help me get across what
>>> you're use case entails :)
>>>
>>> On Mon, 25 Jul 2016 at 4:24 AM, Arnaud bourree 
>>> wrote:
>>>
>> Hi

 I'm interested in test grouped by stage: we'd like to run the same set
 of test in different context: tests have same name and each can work in one
 context and not in other. Grouped by stage we can see easily which context
 has issue

 Regards

 Arnaud Bourrée

 Le 22 juil. 2016 14:07, "ST"  a écrit :

>>> James,

 Interesting statement "successful tests is an edge case" - I've never
 thought about it this way, but if all tests pass I dont need to know
 anything else, so true I guess :-)


 Our use case is (with daily releases):
 * unit tests
 * itests that set up their own data (most of our itests)
 * itests relying on specific test data (i.e. they have to be run
 against a specific test database)
 * itests that test typical API consumption (to ensure we haven't broken
 existing API)

 So when:
 (A) a test fails I'd like to know into which category it falls to
 better assess any consequences and being able to make a first guess about
 what the root cause could be
 (B) many tests fail it's useful to know whether all of them fall into
 same test category.

 Putting tests into a specific java package (*.itest.api.* etc.) would
 probably help to solve (A) but not (B).

 Best regards,
  stefan.



 On Thu, Jul 21, 2016 at 7:12 PM, James Dumay 
 wrote:

 Hi Stefan,
>
> There is no way to do this with Pipeline today. However, when
> designing the new test reporting screen
>  in Blue Ocean
> I did have someone ask if we could group them by stage.
>
> The problem I saw here is that most peoples pipelines look like this:
>
> Build-->Test-->Integration Test-->Deploy
>
> If any tests fail in "Test" then you would not see any tests displayed
> for "Integration Tests" as they were not executed - rendering the grouping
> reasonably useless except for viewing successful tests. (Viewing 
> successful
> tests is an edge case
>  we've opted not
> to handle for the moment due to UI scaling concerns).
>
> Whats your use case for grouping tests by stage?
>
>
> On Thursday, July 21, 2016 at 7:24:39 AM UTC-7, ST wrote:
>>
>> Hi!
>>
>> I am migrating our java/maven build pipeline to a Jenkinsfile, so
>> both the unit tests (maven-surefire-plugin) and integration tests
>> (maven-failsafe-plugin) will be run inside the same pipeline, but in
>> different stages.
>>
>> How 

Re: Visualizing tests separately from different stages of a pipeline

[Joshua Harlow]

I to would like something like this,

It seems to be a common thing to do and a real weakness of the pipeline 
style,

If people are supposed to setup complex pipelines in a pipeline file then 
its pretty important that there be a way to ship out multiple result files,

Even if they are successful, discarding information, especially in jenkins 
seems bad.

Because in my view the 'Build-->Test-->Integration Test-->Deploy' is a real 
simple example and I personally plan on doing a much bigger pipeline like,

Build project Y--> Unit Test Y--> Local functional test Y 
   
  |
  
   ---> Integration Test Y + Z -> Perf test Y + Z -> Request deploy to 
stage ---> (wait) -> Integration Test -> Perf test --> Deploy to prod ---> 
(wait) -->  
 
|
Build project Z-->Unit Test Z--> Local functional test Z

And in that there will be more than Y and Z (all done in parallel with a 
join), at each stage having test results,

Now maybe pipelines aren't meant to approach this complexity? Though if 
they are not, then I'm not quite sure what they are really useful for 
(because I can do the same thing in ansible/equivalent),

-Josh

On Sunday, July 24, 2016 at 1:47:37 PM UTC-7, Arnaud wrote:
>
> Yes, like Matrix job but not only. Separate tests by stage between unit 
> tests and integration tests looks important for me.
>
> Arnaud.
>
> 2016-07-24 21:12 GMT+02:00 James Dumay  >:
>
>> Are you describing a situation here that's closer to what the Matrix job 
>> type caters to? Eg Operating System X Browser Version or something?
>>
>> If you don't mind drawing a picture, that could help me get across what 
>> you're use case entails :)
>>
>> On Mon, 25 Jul 2016 at 4:24 AM, Arnaud bourree > > wrote:
>>
>>> Hi
>>>
>>> I'm interested in test grouped by stage: we'd like to run the same set 
>>> of test in different context: tests have same name and each can work in one 
>>> context and not in other. Grouped by stage we can see easily which context 
>>> has issue 
>>>
>>> Regards 
>>>
>>> Arnaud Bourrée 
>>>
>>> Le 22 juil. 2016 14:07, "ST"  a 
>>> écrit :
>>>
>>> James,
>>>
>>> Interesting statement "successful tests is an edge case" - I've never 
>>> thought about it this way, but if all tests pass I dont need to know 
>>> anything else, so true I guess :-)
>>>
>>>
>>> Our use case is (with daily releases):
>>> * unit tests
>>> * itests that set up their own data (most of our itests)
>>> * itests relying on specific test data (i.e. they have to be run against 
>>> a specific test database)
>>> * itests that test typical API consumption (to ensure we haven't broken 
>>> existing API)
>>>
>>> So when:
>>> (A) a test fails I'd like to know into which category it falls to better 
>>> assess any consequences and being able to make a first guess about what the 
>>> root cause could be
>>> (B) many tests fail it's useful to know whether all of them fall into 
>>> same test category.
>>>
>>> Putting tests into a specific java package (*.itest.api.* etc.) would 
>>> probably help to solve (A) but not (B). 
>>>
>>> Best regards,
>>>  stefan.
>>>
>>>
>>>
>>>
>>> On Thu, Jul 21, 2016 at 7:12 PM, James Dumay >> > wrote:
>>>
 Hi Stefan,

 There is no way to do this with Pipeline today. However, when designing 
 the new test reporting screen 
  in Blue Ocean 
 I did have someone ask if we could group them by stage. 

 The problem I saw here is that most peoples pipelines look like this:

 Build-->Test-->Integration Test-->Deploy

 If any tests fail in "Test" then you would not see any tests displayed 
 for "Integration Tests" as they were not executed - rendering the grouping 
 reasonably useless except for viewing successful tests. (Viewing 
 successful 
 tests is an edge case 
  we've opted not 
 to handle for the moment due to UI scaling concerns).

 Whats your use case for grouping tests by stage?


 On Thursday, July 21, 2016 at 7:24:39 AM UTC-7, ST wrote:
>
> Hi!
>
> I am migrating our java/maven build pipeline to a Jenkinsfile, so both 
> the unit tests (maven-surefire-plugin) and integration tests 
> (maven-failsafe-plugin) will be run inside the same pipeline, but in 
> different stages.
>
> How can I separate the test results for unit tests and integration 
> tests in Jenkins? I am collecting test results like this:
>
> for unit tests:
> step([$class: 'JUnitResultArchiver', testResults: 
> '**/target/surefire-reports/*.xml'])
>
> for integration tests:
> 

Publishing multiple test results from a jenkinsfile (or equivalent)

[Joshua Harlow]

Hi,

I am working through creating a jenkinsfile (and/or equivalent) for the 
openstack (nova) project we are using at godaddy,

The stages are broken up into (literally the following):

stage("Initiation")
flows = build()
node {
start {
net_info()
}
}

stage("Checkout")
slack_stage(
"Checking out (and stashing) repo for ${project}",
{
parallel(flows["cloners"])
}
)

stage("Patch fetching")
slack_stage(
"Checking out (internal) patch repo and stashing patches for ${project}"
,
{
parallel(flows['patch_getters'])
}
)

stage("Unmodified (unit) testing")
slack_stage(
"Unit testing unmodified ${project}",
{
parallel(flows["testers"])
}
)

stage("Augmentation")
slack_stage(
"Augmenting ${project}",
{
parallel(flows["augmenters"])
}
)

stage("Modified (unit) testing")
slack_stage(
"Unit testing modified ${project}",
{
parallel(flows["post_testers"])
}
)

stage("Finished")
finish()


The unmodified testing there will publish before-patch unit test results 
and the post-patch modification will also publish another set of unit test 
results,

When this happens it seems like jenkins only shows the first and not both 
sets of unit test results; is there a plugin that would make both show up?

For recording I am using the following:

 step([$class: 'JUnitResultArchiver', 
testResults: 'results.xml', allowEmptyResults: true])

Maybe there is something special people are doing in groovy to make it work,

Tips would be appreciated :)

-Josh

-- 
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/ba6d8e88-a84b-491f-946a-37cc6a57aeaa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Not able to trigger Github Organization folder job automatically

[Patrick Wolf]

Can you confirm if this is the same behavior you are seeing?

https://issues.jenkins-ci.org/browse/JENKINS-34563

If so, add your comments here so we can track all of it.

On Wed, Aug 17, 2016 at 11:21 AM, Harsha Adiga 
wrote:

> Hi Patrick,
>
> Any updates on this query? Do you need any more information from me?
>
> Regards,
> Harsha
>
>
> On Monday, 15 August 2016 17:03:54 UTC-4, Harsha Adiga wrote:
>>
>> I think yes Jenkins is receiving the event. I can see the below line in
>> System Logs:
>>
>> Aug 15, 2016 4:17:13 PM INFO 
>> org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber 
>> onEvent
>>
>> Received POST for https:TestRepo_MultiBranchPipeline3
>>
>>
>> Do you know where can I see more detailed logs? I see the attached message 
>> in the GitHub payload.
>>
>>
>> Also when I fork my repos (ones that already have a Jenkinsfile) my job is 
>> getting triggered automatically.
>>
>>
>> Regards,
>>
>> Harsha
>>
>>
>> On Monday, 15 August 2016 16:13:02 UTC-4, Patrick Wolf wrote:
>>>
>>> Do you know if the Push Event webhook is received by Jenkins when you
>>> create the Jenkinsfile?
>>>
>>> "Does the plugin expect the repo to have a Jenkinsfile at the time of
>>> creation itself?"
>>>
>>> Just the opposite. The plugin expects the repo to be empty at the time
>>> of creation unless the repo is created by a fork. That is why the first
>>> Push Event is so important.
>>>
>>>
>>>
>>> On Mon, Aug 15, 2016 at 1:03 PM, Harsha Adiga 
>>> wrote:
>>>
 Hi Patrick,

 Thanks for the quick reply. Yes I am creating an empty repository
 without Jenkinsfile at first and then adding the Jenkins file as a new file
 commit. I was expecting my job to get triggered at this point when I add
 the Jenkinsfile. But it is not doing that. Am I missing something here?
 Does the plugin expect the repo to have a Jenkinsfile at the time of
 creation itself?

 Regards,
 Harsha

 On Monday, 15 August 2016 15:54:07 UTC-4, Patrick Wolf wrote:
>
> How are you creating the Jenkinsfile?  When a new repository is
> created the repository trigger will be sent but the Github Organization
> Folder plugin won't do anything at that point because it assumes the
> repository is empty. If the repository is created from a fork and a
> Jenkinsfile is already there then Jenkins should create a job for that
> repository right away.
>
> You can see that code here:
>
> https://github.com/jenkinsci/github-organization-folder-plug
> in/blob/master/src/main/java/org/jenkinsci/plugins/orgfolde
> r/github/RepositoryGHEventSubscriber.java
>
> The first push to the new repository that contains a Jenkinsfile
> should trigger Jenkins to create the job at that point based on the Push
> webhook sent from Github.  Is that not working correctly?
>
> On Mon, Aug 15, 2016 at 12:47 PM, Harsha Adiga 
> wrote:
>
>> I am doing a POC using GitHub Organization Folder plugin. I have
>> created a job selecting Git Hub Organization as the type. I have 
>> configured
>> it to scan my org using the personal access token that I have generated 
>> in
>> my Github account. I am using my Enterprise Git hub. I have also created 
>> a
>> webhook at the org level as below:
>>
>> *http:///github-webhook/*  (I have selected content
>> type as  "application/x-www-form-urlencoded" and selected "Send me
>> everything" option)
>>
>> I am able to scan the organization and create folders and jobs for
>> all my repos.
>>
>> But I am not able to trigger my Jenkins job automatically when a new
>> repo is created in my GitHub organization. I see that the webhook is
>> getting fired on new repo creation. I also see the event logged in 
>> Jenkins
>> logs. But the job is not getting triggered. I need to manually run 
>> "Re-scan
>> organization" to get jobs created for the new repo.  But once the jobs 
>> are
>> created any future commits to the repo or even branch creation is able to
>> trigger the jenkins build job automatically. Only the new repo creation 
>> is
>> not working. I am using Jenkins v 2.7.2 and Git Hub Org folder plugin v
>> 1.4. Can someone please help me?
>>
>>
>> --
>> 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/2edb9a66-
>> be61-4bea-85fb-77e3ab3eeb7b%40googlegroups.com
>> 
>> .
>> 

Re: Multiple Jobs that are exactly the same

[Baptiste Mathus]

IMO it's a good thing to have a job per repo/project.

You could probably have a look at either Job DSL plugin to version and
script the fact and jobs are alike. Or use a pipeline script for all of
them, using by default a standard function coming from the Pipeline Global
Library Plugin.

My 2 cents

Le 17 août 2016 3:25 PM, "Pykler"  a écrit :

> We have a code base with many small repos, each repo is essentially a
> service. To test we have separate builds for each small repo, yet they are
> all pretty much identical. The problem happens when we want to make a
> change, we have to change every single one (over 60 builds). Is there a way
> we can have a single set of build steps that run regardless of the repo
> that was changed? does anyone have a similar setup and can share the best
> practices
>
> --
> 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/b7dd8d3d-9d39-47fa-8f3c-2928bbe734fe%40googlegroups.
> com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Jenkinsfile Multibranch Pipeline Github Maven Checkout Directory Issues

[Baptiste Mathus]

Not sure I get what your actual issue is. Could you maybe rephrase it to
say what you see, compared to what you expect, and provide the error logs
and so on?

Cheers

Le 17 août 2016 11:02 AM, "Tony Murphy"  a écrit :

> Hi
>
> I'm using the new Jenkins Pipelines and I need some help.
>
> I was under the illusion that once I setup my multi branch pipeline that
> was it as far as checkouts and branch management was concerned. But it
> seems that I was mistaken.
>
> I had issues where for example mvn command was not running in the
> directory were the code was checkout out to. The command seemed to be
> running in a  folder, while the code was in a sibling folder
> with a @scripts name (hope that makes sense)
>
> `checkout scm` does not work for me btw
>
> I would be grateful if someone could confirm I'm on the right track, could
> suggest improvements or confirm that it won't always be like this :)
>
> #!groovy
>
> githubCredentials = 'github_credentials'
> def projectBranch = "${env.BRANCH_NAME}"
>
> node {
>
> def javaHome = tool "java8" // ensure Java 8 is installed
> def projectRepoURL = 'g...@github.com:tonymurphy/jenkins-test.git'
> echo "${env.getEnvironment()}"
> def mvnHome  = tool "mvn-3.2.2"
>
> wrap([$class: 'AnsiColorBuildWrapper', colorMapName: 'xterm']) {
>
> stage "Checkout"
> sh("git config --global credential.helper cache")
> checkout([$class   : 'GitSCM',
>   branches : [[name: projectBranch]],
>   extensions   : [[$class: 'RelativeTargetDirectory', 
> relativeTargetDir: 'jenkins-test'], [$class: 'CheckoutOption', timeout: 
> 10]],
>   userRemoteConfigs: [[credentialsId: githubCredentials, url: 
> projectRepoURL]]])
>
> stage 'Build'
> withEnv(["PATH+ACTIVATOR=${tool 'activator-1.3.x'}", 
> "PATH+JDK=${javaHome}/bin", "JAVA_HOME=${javaHome}"]) {
> dir("jenkins-test") {
> sh "${mvnHome}/bin/mvn clean compile test "
> step([$class: 'ArtifactArchiver', artifacts: 
> '**/target/*.jar', fingerprint: true])
> step([$class: 'JUnitResultArchiver', testResults: 
> '**/target/surefire-reports/TEST-*.xml'])
>
> }
> }
> }
> }
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-users/CAORQRkVZKg0fh4oqcgi8CQKhfpJ6B
> GnBoHijP55xv1SUR2VF6A%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/CANWgJS64ZCkH6YEeNmTcKL%2BE9b8nqCtY9nUK4kb%2BuqONtrqQ9w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Multi-Branch Pipeline triggers interval example?

[Greg Smith]

Hi,

Would someone mind giving me an example of how to use the "properties" task 
to set a build trigger so that a multibranch pipeline build will run every 
15 minutes?

Somehow, both the snippet generator and the pipeline syntax generator are 
both errorring out on my server, so I can not find any sample of how to do 
it correctly.

My snippet generator with the value of "H/15 * * * *" just generates the 
following:
pipelineTriggers([])

And the pipeline syntax generator shows the following:
$class: 'PipelineTriggersJobProperty'
triggers
Array/List:
java.lang.UnsupportedOperationException: do not know how to categorize 
attributes of type hudson.triggers.Trigger


So with both of those broken, I can't seem to find any good example of how 
to configure this new capability in my by branch build

Thanks,
Greg



-- 
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/cb6ed62f-377b-47a2-8af8-677e1e360245%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

CloudBees Docker Build/Credentials Plugin question

[rudybone]

My Jenkins installation is using the CloudBees Docker Build and Publish 
Plugin version 1.2.1 and the Credentials Plugin v 1.28.

When I go to configure my Docker Builder and set my Registry Credentials I 
can only seem to add the credentials to Global Credentials, despite 
creating my own credential domain AND creating a username/password 
credential in my User configuration (neither of which appear in the 
Registry Credentials drop-down.  I don't want my Registry Credentials to be 
Global.  

Any help would be appreciated

-- 
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/ff5f6693-d239-4301-8ba1-f3d01a97198e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Where did it move to? "Under the Build Triggers section, check Trigger builds remotely"

[Brian G]

A little more looking and I find that it has to do with not running a 
'secure' Jenkins setup.




-- 
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/3b9c32f7-c563-419d-8aca-7af8f3fd7504%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Where did it move to? "Under the Build Triggers section, check Trigger builds remotely"

[Brian G]

I keep seeing this in many reference articles on triggering builds. "Under 
the Build Triggers section, check Trigger builds remotely", however it has 
apparently been moved somewhere else and I can't find any references to 
where that is. Can someone please point me in the  right direction?

thanks,
Brian

-- 
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/db708a93-2836-4378-b372-193ef4e64104%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Not able to trigger Github Organization folder job automatically

[Harsha Adiga]

Hi Patrick,

Any updates on this query? Do you need any more information from me?

Regards,
Harsha

On Monday, 15 August 2016 17:03:54 UTC-4, Harsha Adiga wrote:
>
> I think yes Jenkins is receiving the event. I can see the below line in 
> System Logs:
>
> Aug 15, 2016 4:17:13 PM INFO 
> org.jenkinsci.plugins.github.webhook.subscriber.DefaultPushGHEventSubscriber 
> onEvent
>
> Received POST for https:TestRepo_MultiBranchPipeline3
>
>
> Do you know where can I see more detailed logs? I see the attached message in 
> the GitHub payload.
>
>
> Also when I fork my repos (ones that already have a Jenkinsfile) my job is 
> getting triggered automatically.
>
>
> Regards,
>
> Harsha
>
>
> On Monday, 15 August 2016 16:13:02 UTC-4, Patrick Wolf wrote:
>>
>> Do you know if the Push Event webhook is received by Jenkins when you 
>> create the Jenkinsfile?
>>
>> "Does the plugin expect the repo to have a Jenkinsfile at the time of 
>> creation itself?"
>>
>> Just the opposite. The plugin expects the repo to be empty at the time of 
>> creation unless the repo is created by a fork. That is why the first Push 
>> Event is so important.
>>
>>
>>
>> On Mon, Aug 15, 2016 at 1:03 PM, Harsha Adiga  
>> wrote:
>>
>>> Hi Patrick,
>>>
>>> Thanks for the quick reply. Yes I am creating an empty repository 
>>> without Jenkinsfile at first and then adding the Jenkins file as a new file 
>>> commit. I was expecting my job to get triggered at this point when I add 
>>> the Jenkinsfile. But it is not doing that. Am I missing something here? 
>>> Does the plugin expect the repo to have a Jenkinsfile at the time of 
>>> creation itself?
>>>
>>> Regards,
>>> Harsha
>>>
>>> On Monday, 15 August 2016 15:54:07 UTC-4, Patrick Wolf wrote:

 How are you creating the Jenkinsfile?  When a new repository is created 
 the repository trigger will be sent but the Github Organization Folder 
 plugin won't do anything at that point because it assumes the repository 
 is 
 empty. If the repository is created from a fork and a Jenkinsfile is 
 already there then Jenkins should create a job for that repository right 
 away.

 You can see that code here:


 https://github.com/jenkinsci/github-organization-folder-plugin/blob/master/src/main/java/org/jenkinsci/plugins/orgfolder/github/RepositoryGHEventSubscriber.java

 The first push to the new repository that contains a Jenkinsfile should 
 trigger Jenkins to create the job at that point based on the Push webhook 
 sent from Github.  Is that not working correctly?

 On Mon, Aug 15, 2016 at 12:47 PM, Harsha Adiga  
 wrote:

> I am doing a POC using GitHub Organization Folder plugin. I have 
> created a job selecting Git Hub Organization as the type. I have 
> configured 
> it to scan my org using the personal access token that I have generated 
> in 
> my Github account. I am using my Enterprise Git hub. I have also created 
> a 
> webhook at the org level as below:
>
> *http:///github-webhook/*  (I have selected content type 
> as  "application/x-www-form-urlencoded" and selected "Send me everything" 
> option)
>
> I am able to scan the organization and create folders and jobs for all 
> my repos. 
>
> But I am not able to trigger my Jenkins job automatically when a new 
> repo is created in my GitHub organization. I see that the webhook is 
> getting fired on new repo creation. I also see the event logged in 
> Jenkins 
> logs. But the job is not getting triggered. I need to manually run 
> "Re-scan 
> organization" to get jobs created for the new repo.  But once the jobs 
> are 
> created any future commits to the repo or even branch creation is able to 
> trigger the jenkins build job automatically. Only the new repo creation 
> is 
> not working. I am using Jenkins v 2.7.2 and Git Hub Org folder plugin v 
> 1.4. Can someone please help me?
>
>
> -- 
> 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/2edb9a66-be61-4bea-85fb-77e3ab3eeb7b%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



 -- 

 Patrick Wolf
 Product Director - Jenkins 
 CloudBees

>>> -- 
>>> 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 

Re: LDAP groups and Role Based Authorization no playing nice.

[Michael Lasevich]

So, was this broken at some later time on purpose? I could have sworn I 
have used this functionality in the past.

Is this a problem in Role plugin or LDAP plugin? You mention Role plugin, 
but Role plugin is clearly recognizing the group for admin - it seems like 
there is a security problem in LDAP plugin that prevents it from reading 
the groups for non-admin users.

-M




On Wednesday, August 17, 2016 at 5:25:08 AM UTC-7, Indra Gunawan (ingunawa) 
wrote:
>
> LDAP group never works with the Role Based Authorization plugin.  Only the 
> CloudBee paid version of Role based plugin combined with Folder plugin on 
> Enterprise Jenkins are made to work with LDAP group.
>
> -Indra
>
> From:  on behalf of Michael 
> Lasevich 
> Reply-To: "jenkins...@googlegroups.com " <
> jenkins...@googlegroups.com >
> Date: Monday, August 15, 2016 at 1:59 PM
> To: Jenkins Users 
> Subject: LDAP groups and Role Based Authorization no playing nice.
>
> I am trying to do something I thought I have done many times before, but 
> it is not working now - using Roles based Authorization with LDAP 
> authentication and specifically LDAP Groups 
>
> I believe I have LDAP Authentication setup and working  for both users and 
> groups
> I believe I have Role based authentication set up.
>
> Granting roles to LDAP users directly - either global or project roles - 
> works. I can login with LDAP user and get expected permissions. Granting 
> roles to 'authenticated' also seems to work.
>
> However if I grant permissions to LDAP group - it just does not work. 
>
> I am very confused why assigning roles to groups does not work.
>
> Few thoughts and observations: 
>
> * "Assign Roles" UI recognizes LDAP Groups and shows a group icon next to 
> them.
>
> * "User status" UI (/user/username URI) shows groups for the use and I 
> even ran that LDAP test groovy script that worked as expected. Although...
>
> * "User Status" only shows groups to "admin" user. A regular use with just 
> access to run specific jobs does not see their own groups - perhaps 
> something is blocking non-admin users from reading their own groups?
>
> * Increasing logging shows that a user that was granted admin rights 
> directly has all the groups in the "Granted Authorities" but non-admin user 
> only has "authenticated" - interestingly enough admin user does NOT have 
> 'authenticated'...
>
> * Don't think it is relevant here, but in the past I recall having to do a 
> special prefix for groups (like '@' I think) - not sure if this is still 
> necessary
>
>
> Versions -- Running this on:
>
> * Jenkins 2.10
> * LDAP Plugin 1.12
> * Role Based Authorization Strategy 2.3.2
>
> Any thoughts or suggestions would be appreciated
>
> Thanks,
>
> -Michael
>
>
>
> -- 
> 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/0c1f3dd2-e132-4c08-b8e3-c4b22cb2974c%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [pipeline][parametrized build][Jenkinsfile]Cannot use variable to checkout the parametrized build

[jerome]

Hi,
Anybody known if this will solved or any workaround? this is the last show 
stoper for us to move to pipeline. I would really like to get ride of the 
old project. 

I have attach some screen capture if I wasn't clear enough.

I work around most other problems but this I cannot do much. Unless I use a 
project direct script that perform a first checkout (checkout scm: 
[...]) with the branch then append the repos Jenkinsfile to the current 
script execution if that's even possible???

Thanks,
Jerome

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

Re: Stash Integration with Jenkins Pipeline {for Code Review}

[Michael Kobit]

The *Bitbucket Branch Source Plugin *is still in a weird place for 
Bitbucket Server. Follow the discussion on 
https://issues.jenkins-ci.org/browse/JENKINS-33507 to see some of the 
issues with some of the existing Bitbucket Server plugins and the open PRs 
for auto-registration.

On Sunday, August 14, 2016 at 11:22:43 PM UTC-5, James Dumay wrote:
>
> You need the Bitbucket Branch source plugin which works with Bitbucket 
> Cloud and Bitbucket Server (was Stash) 
> https://wiki.jenkins-ci.org/display/JENKINS/Bitbucket+Branch+Source+Plugin
>
> The user guide can be found here 
> https://go.cloudbees.com/docs/cloudbees-documentation/cje-user-guide/chapter-bitbucket.html
>  
>
> Interested to know what your milage is like so do drop a reply here if it 
> works for you or if you have any troubles :)
>
>
> On Friday, August 12, 2016 at 12:17:14 PM UTC+10, Sajith Majeed - Saaj 
> wrote:
>>
>> We are trying to implement a code review process for our applications. We 
>> use GIT repository and Atlassian Stash.
>>
>> 1. Have any of you integrated Stash Pull requests with Jenkins Pipelines 
>> ? Are there any plugins or documentations that are available to do this ?
>> 2. Is there a better code review process with Pull request that can be 
>> integrated to Jenkins Pipelines?
>>
>>
>> Thanks | Sajith
>>
>

-- 
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/bc78cbd7-8043-49f3-8f5d-e3de9215125d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Jenkins Master and Slave containers sharing Jenkins home

[Tony Owens]

I have a single Linux vm dedicated to running a Jenkins master container 
with Jenkins home mapped to an NFS mount.  I have two other Linux vm's with 
the same mount configured and have FS Root set to that path.  Am I asking 
for trouble by doing this?  If so, any explanation would be greatly 
appreciated.

Tony

-- 
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/be2ae7a6-a624-4689-a637-36535f5c5327%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

CD Summit & Jenkins Days Fall Tour Line Up

[Jared@DevOps]

Hello everybody,

 
My name is Jared and I’m with DevOps.com, we are the only destination on 
the worldwide web dedicated to all thing DevOps. We are very proud bringing 
together the local CI/CD/DevOps communities to learn, network and discuss 
the latest trends and topics around this very hot subject. Our Fall line up 
has been announced and I want to let everybody know that these shows ROCK! 
Our spring shows were a hit and our new line up is sure to be a success. 
Please feel free to message me directly for more information and coupon 
codes to attend.

This is our Fall Tour and Dates. We would love to see you there. 

Amsterdam - Novotel Amsterdam City – October 4

Atlanta, GA - Cobb Galleria Center – October 6

Berlin, Germany – Steigenberger - October 6

Denver, CO - Colorado Convention Center – October 13

Austin, TX - Austin Convention Center – November 17

Seattle, WA – BELL HARBOR INTERNATIONAL CONFERENCE CENTER - December 6

Los Angeles, CA - Olympic Conference Center – December 15

-- 
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/48993827-5b11-4bdb-a508-19543674ac4e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Building GitHub Pull Requests using Pipelines (and optionally Docker)

[Pascal Widdershoven]

I blogged about building GitHub Pull Requests with Pipelines and optionally 
Docker: 
https://www.theguild.nl/building-github-pull-requests-using-jenkins-pipelines/

Hope it's useful to anyone :-)

-- 
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/659fa2de-0733-49fc-8685-7271bb1485ca%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Automated Jenkins Plugin/Dependency Management

[Jason Kulatunga]

Hey,
Thanks for all the help guys.
I slept on this idea for a few days because, to be honest I really didn't 
want to write my own package manager 

 and 
re-invent the wheel. I took a step back and looked at how Jenkins solved 
this problem for Plugin developers, and I think that we could just 
piggy-back on top of what they use 
.

Basically what I've done is specify the plugins I want to install in a 
build.gradle file on my Jenkins server. The build.gradle file lets me 
specify exactly what versions of the plugins I want for some, and get the 
latest for the rest. My install task then goes and copies just the runtime 
hpi files to the $JENKINS_HOME/plugins folder (after clearing out whatever 
is in there). After restarting my Jenkins server, all plugins are 
installed, with the correct versions.

I've included a plugin management section in my blog post: You Don't Know 
Jenkins - Part 1 
 
which 
goes into more detail on how it all works, and includes an example 
build.gradle file. 

Things to note:
- The plugin.lock file isn't perfect, its just a STDOUT redirect of `gradle 
dependencies` which is great for visually checking which versions are 
installed, but committing it to git gets you nothing, subsequent installs 
wont be locked to the same transient dependencies. I think I can solve this 
by using https://github.com/nebula-plugins/gradle-dependency-lock-plugin
- Since the build.gradle file uses repo.jenkins-ci.org instead 
of updates.jenkins-ci.org it does pick up the occassional beta/alpha 
version that gets pushed to the releases repo by developers. I'm working to 
fix this using a filter in the gradle dependency solver configuration. 



On Thursday, August 11, 2016 at 6:03:12 PM UTC-7, Michael Kobit wrote:
>
> We are looking at doing something similar (actually talking about this 
> with colleagues today). The idea is to basically build an immutable Jenkins 
> instance that can't be modified. Or at least severely limit any kinds of 
> modifications to it so that we have an easily deployable "Jenkins as a 
> service".
>
> I've looked at possibly doing an "unpack and install" execution with the 
> *jenkins.war 
> *, but it doesn't look like an easy route. The other pain-point I see is 
> effectively treating the correct files as "data" that should be persisted 
> over time, rather than at "Jenkins build time". I am considering trying out 
> the Docker-type approach. I think for plugin resolution, we are probably 
> going to have to go the route that you are talking about for doing the 
> resolution ourselves.
>
> For security type issues, I think we could still handle it with the Docker 
> approach. Build whatever restrictions into the next "immutable" image and 
> making that deployable. Then, we can have a "staging" area and easily 
> rollback if we effectively control all the things we need to control. We 
> are experimenting with pipelines right now, and are waiting to see how 
> https://issues.jenkins-ci.org/browse/JENKINS-33507 will work for us to 
> get as much of the job configuration out of Jenkins as possible.
>
> We are still in the brainstorming phase, so I'm interested to see who else 
> has ran into this and what they have done.
>
> On Thursday, August 11, 2016 at 5:47:45 PM UTC-5, Jason Kulatunga wrote:
>>
>> Hey,
>> Thanks for all the feedback :)
>>
>> @Daniel Beck:
>> Yup, I'm familiar with the limitations of the 
>> https://updates.jenkins-ci.org/current/update-center.json file. Thats 
>> why I'm thinking of creating a plugin/dependency resolution system that 
>> will have to directly download the specific version of a plugin file from 
>> update site folder structure 
>> https://updates.jenkins-ci.org/download/plugins/*/ or use 
>> https://updates.jenkins-ci.org/latest/ 
>> if no version restriction is found.
>>
>> I wasn't aware that pinning was pointless in 2.x so that'll be an 
>> interesting problem to deal with. It seems that I'll have to restrict all 
>> access to the UpdateCenter for idea #1, or do a hybrid approach with a 
>> UpdateCenter subclass as well.
>>
>> @Baptiste Mathus 
>> Unfortunately just using an image with locked plugins isn't a long term 
>> solution, because we'll have to occasionally update our Jenkins due to 
>> required security updates in plugins or the main application. So being able 
>> to update plugins, creating a new *.lock file, test the plugin interactions 
>> and deploying the *.lock file to existing Jenkins servers is a requirement. 
>>
>> I was hoping to stay away from a hybrid approach that used both an 
>> executable and a subclass as it makes development and deployment more 
>> complicated, decreasing adoption with Jenkins users. 
>>
>> Honestly the goal was to create a tool like Bundler/Pip which would just 
>> work out 

RE: Teaching an old job new tricks

[Ginga, Dick]

Thank you Mark

From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Mark Waite
Sent: Wednesday, August 17, 2016 10:03 AM
To: jenkinsci-users@googlegroups.com
Subject: Re: Teaching an old job new tricks

Labels do not have any concept of affinity as far as I know.

On Wed, Aug 17, 2016 at 7:40 AM Ginga, Dick 
> wrote:
Does the use of node label contain a notion of “affinity”. In other words, I 
would like a build to go to node A always, unless node A is unavailable.

I implemented my own failover by using a node label parameter with a default 
node of A and a “possible nodes” of the failover node.

From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com]
 On Behalf Of Mark Waite
Sent: Tuesday, August 16, 2016 7:15 PM
To: jenkinsci-users@googlegroups.com
Subject: Re: Teaching an old job new tricks


On Tue, Aug 16, 2016 at 3:44 PM Bruce Epstein 
> wrote:
Thanks, I will try that.

I guess this gets to the heart of my question...

If I make it so that an old job won't run on builder, will it fail over to the 
newly created node?

Yes, it will switch freely from one node to another unless you have tied the 
job to a specific node.  That's one of the reasons to tie a job to a capability 
based label rather than tying it to a specific node name.

Mark Waite

That is, will old jobs run on the new node, if cajoled properly, or will they 
just fail altogether?


On Tuesday, August 16, 2016 at 4:23:38 PM UTC-4, Mark Waite wrote:
You might also consider changing the setting of the master node.

The "Usage" field of the master node configuration should have a pick list with 
two choices, either "Use this node as much as possible" (the default), or "Only 
build jobs with label expressions matching this node".  That will tend to keep 
most jobs off your master node (at least it does for me).

Mark Waite

On Tue, Aug 16, 2016 at 2:19 PM Indra Gunawan (ingunawa) 
> wrote:
Use the Configuration Slicing Plugin : 
https://wiki.jenkins-ci.org/display/JENKINS/Configuration+Slicing+Plugin
 to mass assign a label to jobs that are not tied to any node all at once.

-Indra

From: > on 
behalf of Bruce Epstein >
Reply-To: "jenkins...@googlegroups.com" 
>

Date: Tuesday, August 16, 2016 at 1:16 PM
To: Jenkins Users 
>

Subject: Teaching an old job new tricks
Hi All,

Thanks to those who answered my previous question about setting up agents.

I now have two new agent nodes set up and want to move old jobs off the master, 
so the master won't be used for any building (just admin).

How do I prevent jobs from running on the master? Do I just set "number of 
executors" to zero?

For new jobs, I see the choice in their configuration allowing me to decide 
where to run the job, so I can force it to run on the agent node not the master.

I understand old jobs are supposed to run on the master, but I don't want them 
to any more. Even cloned (new) jobs seem to not have the "Restrict where this 
job runs" configuration option, so I assume they will run on the master (as did 
the job from which they were cloned.)

What are my options?

This plugin seems to be one possibility for setting the node at build time (I 
imagine I can set its default to specify a new node for building?)

https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin

Will that work with old jobs, causing them to run on one of the new agent nodes 
instead of the master?

Inquiring minds want to know!

Thanks again in 

Re: Teaching an old job new tricks

[Mark Waite]

Labels do not have any concept of affinity as far as I know.

On Wed, Aug 17, 2016 at 7:40 AM Ginga, Dick 
wrote:

> Does the use of node label contain a notion of “affinity”. In other words,
> I would like a build to go to node A always, unless node A is unavailable.
>
>
>
> I implemented my own failover by using a node label parameter with a
> default node of A and a “possible nodes” of the failover node.
>
>
>
> *From:* jenkinsci-users@googlegroups.com [mailto:
> jenkinsci-users@googlegroups.com] *On Behalf Of *Mark Waite
> *Sent:* Tuesday, August 16, 2016 7:15 PM
> *To:* jenkinsci-users@googlegroups.com
> *Subject:* Re: Teaching an old job new tricks
>
>
>
>
>
> On Tue, Aug 16, 2016 at 3:44 PM Bruce Epstein  wrote:
>
> Thanks, I will try that.
>
> I guess this gets to the heart of my question...
>
> If I make it so that an old job won't run on builder, will it fail over to
> the newly created node?
>
>
>
> Yes, it will switch freely from one node to another unless you have tied
> the job to a specific node.  That's one of the reasons to tie a job to a
> capability based label rather than tying it to a specific node name.
>
>
>
> Mark Waite
>
>
>
> That is, will old jobs run on the new node, if cajoled properly, or will
> they just fail altogether?
>
>
>
> On Tuesday, August 16, 2016 at 4:23:38 PM UTC-4, Mark Waite wrote:
>
> You might also consider changing the setting of the master node.
>
>
>
> The "Usage" field of the master node configuration should have a pick list
> with two choices, either "Use this node as much as possible" (the default),
> or "Only build jobs with label expressions matching this node".  That will
> tend to keep most jobs off your master node (at least it does for me).
>
>
>
> Mark Waite
>
>
>
> On Tue, Aug 16, 2016 at 2:19 PM Indra Gunawan (ingunawa) <
> ingu...@cisco.com> wrote:
>
> Use the Configuration Slicing Plugin :
> https://wiki.jenkins-ci.org/display/JENKINS/Configuration+Slicing+Plugin
> 
>  to
> mass assign a label to jobs that are not tied to any node all at once.
>
>
>
> -Indra
>
>
>
> *From: * on behalf of Bruce Epstein <
> goo...@zeusprod.com>
> *Reply-To: *"jenkins...@googlegroups.com" 
>
>
> *Date: *Tuesday, August 16, 2016 at 1:16 PM
>
> *To: *Jenkins Users 
>
>
> *Subject: *Teaching an old job new tricks
>
> Hi All,
>
> Thanks to those who answered my previous question about setting up agents.
>
> I now have two new agent nodes set up and want to move old jobs off the
> master, so the master won't be used for any building (just admin).
>
> How do I prevent jobs from running on the master? Do I just set "number of
> executors" to zero?
>
> For new jobs, I see the choice in their configuration allowing me to
> decide where to run the job, so I can force it to run on the agent node not
> the master.
>
> I understand old jobs are supposed to run on the master, but I don't want
> them to any more. Even cloned (new) jobs seem to not have the "Restrict
> where this job runs" configuration option, so I assume they will run on the
> master (as did the job from which they were cloned.)
>
> What are my options?
>
> This plugin seems to be one possibility for setting the node at build time
> (I imagine I can set its default to specify a new node for building?)
>
> https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin
> 
>
> Will that work with old jobs, causing them to run on one of the new agent
> nodes instead of the master?
>
> Inquiring minds want to know!
>
> Thanks again in advance.
>
> Cheers
> Bruce
>
> --
> 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/8a88c69f-bf54-4bd8-8009-e73c2f42895b%40googlegroups.com

Re: Matrix-based security does not authenticate group users in Active Directory

[h yee]

This was my issue

For job project-base security to work with AD group/ user configured in a 
job,
remove from AD group / user from 'configure global security' 

On Monday, November 18, 2013 at 12:49:10 PM UTC-5, SamL wrote:
>
> Hello Folks,
>
> We are facing an issue where Matrix-based security does not appear to be 
> authenticating against users in groups.
> We have tried both:
>
> Active Directory and LDAP Security Realms and the issue appears in both 
>  cases
>
> We we add an Active Directory name in the Matrix-based security  users in 
> that group only see the settings applied to anonymous.
> It works find for individual  users.
>
>
> There are no  errors in the log file either.
>
> Any help would be very much appreciated.
>
> Jenkins 1.509.4
> Ubuntu 12.04
> Jenkins Active Directory plugin 1.33
>
>

-- 
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/fc7948c4-8831-4e0f-b914-1385c8d1b957%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: Teaching an old job new tricks

[Ginga, Dick]

Does the use of node label contain a notion of “affinity”. In other words, I 
would like a build to go to node A always, unless node A is unavailable.

I implemented my own failover by using a node label parameter with a default 
node of A and a “possible nodes” of the failover node.

From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Mark Waite
Sent: Tuesday, August 16, 2016 7:15 PM
To: jenkinsci-users@googlegroups.com
Subject: Re: Teaching an old job new tricks


On Tue, Aug 16, 2016 at 3:44 PM Bruce Epstein 
> wrote:
Thanks, I will try that.

I guess this gets to the heart of my question...

If I make it so that an old job won't run on builder, will it fail over to the 
newly created node?

Yes, it will switch freely from one node to another unless you have tied the 
job to a specific node.  That's one of the reasons to tie a job to a capability 
based label rather than tying it to a specific node name.

Mark Waite

That is, will old jobs run on the new node, if cajoled properly, or will they 
just fail altogether?


On Tuesday, August 16, 2016 at 4:23:38 PM UTC-4, Mark Waite wrote:
You might also consider changing the setting of the master node.

The "Usage" field of the master node configuration should have a pick list with 
two choices, either "Use this node as much as possible" (the default), or "Only 
build jobs with label expressions matching this node".  That will tend to keep 
most jobs off your master node (at least it does for me).

Mark Waite

On Tue, Aug 16, 2016 at 2:19 PM Indra Gunawan (ingunawa) 
> wrote:
Use the Configuration Slicing Plugin : 
https://wiki.jenkins-ci.org/display/JENKINS/Configuration+Slicing+Plugin
 to mass assign a label to jobs that are not tied to any node all at once.

-Indra

From: > on 
behalf of Bruce Epstein >
Reply-To: "jenkins...@googlegroups.com" 
>

Date: Tuesday, August 16, 2016 at 1:16 PM
To: Jenkins Users 
>

Subject: Teaching an old job new tricks
Hi All,

Thanks to those who answered my previous question about setting up agents.

I now have two new agent nodes set up and want to move old jobs off the master, 
so the master won't be used for any building (just admin).

How do I prevent jobs from running on the master? Do I just set "number of 
executors" to zero?

For new jobs, I see the choice in their configuration allowing me to decide 
where to run the job, so I can force it to run on the agent node not the master.

I understand old jobs are supposed to run on the master, but I don't want them 
to any more. Even cloned (new) jobs seem to not have the "Restrict where this 
job runs" configuration option, so I assume they will run on the master (as did 
the job from which they were cloned.)

What are my options?

This plugin seems to be one possibility for setting the node at build time (I 
imagine I can set its default to specify a new node for building?)

https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin

Will that work with old jobs, causing them to run on one of the new agent nodes 
instead of the master?

Inquiring minds want to know!

Thanks again in advance.

Cheers
Bruce
--
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 

Multiple Jobs that are exactly the same

[Pykler]

 

We have a code base with many small repos, each repo is essentially a 
service. To test we have separate builds for each small repo, yet they are 
all pretty much identical. The problem happens when we want to make a 
change, we have to change every single one (over 60 builds). Is there a way 
we can have a single set of build steps that run regardless of the repo 
that was changed? does anyone have a similar setup and can share the best 
practices

-- 
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/b7dd8d3d-9d39-47fa-8f3c-2928bbe734fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: LDAP groups and Role Based Authorization no playing nice.

[Indra Gunawan (ingunawa)]

LDAP group never works with the Role Based Authorization plugin.  Only the 
CloudBee paid version of Role based plugin combined with Folder plugin on 
Enterprise Jenkins are made to work with LDAP group.

-Indra

From: 
> on 
behalf of Michael Lasevich >
Reply-To: 
"jenkinsci-users@googlegroups.com" 
>
Date: Monday, August 15, 2016 at 1:59 PM
To: Jenkins Users 
>
Subject: LDAP groups and Role Based Authorization no playing nice.

I am trying to do something I thought I have done many times before, but it is 
not working now - using Roles based Authorization with LDAP authentication and 
specifically LDAP Groups

I believe I have LDAP Authentication setup and working  for both users and 
groups
I believe I have Role based authentication set up.

Granting roles to LDAP users directly - either global or project roles - works. 
I can login with LDAP user and get expected permissions. Granting roles to 
'authenticated' also seems to work.

However if I grant permissions to LDAP group - it just does not work.

I am very confused why assigning roles to groups does not work.

Few thoughts and observations:

* "Assign Roles" UI recognizes LDAP Groups and shows a group icon next to them.

* "User status" UI (/user/username URI) shows groups for the use and I even ran 
that LDAP test groovy script that worked as expected. Although...

* "User Status" only shows groups to "admin" user. A regular use with just 
access to run specific jobs does not see their own groups - perhaps something 
is blocking non-admin users from reading their own groups?

* Increasing logging shows that a user that was granted admin rights directly 
has all the groups in the "Granted Authorities" but non-admin user only has 
"authenticated" - interestingly enough admin user does NOT have 
'authenticated'...

* Don't think it is relevant here, but in the past I recall having to do a 
special prefix for groups (like '@' I think) - not sure if this is still 
necessary


Versions -- Running this on:

* Jenkins 2.10
* LDAP Plugin 1.12
* Role Based Authorization Strategy 2.3.2

Any thoughts or suggestions would be appreciated

Thanks,

-Michael




--
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/0c1f3dd2-e132-4c08-b8e3-c4b22cb2974c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Jenkinsfile Multibranch Pipeline Github Maven Checkout Directory Issues

[Tony Murphy]

Hi

I'm using the new Jenkins Pipelines and I need some help.

I was under the illusion that once I setup my multi branch pipeline that
was it as far as checkouts and branch management was concerned. But it
seems that I was mistaken.

I had issues where for example mvn command was not running in the directory
were the code was checkout out to. The command seemed to be running in a
 folder, while the code was in a sibling folder with a
@scripts name (hope that makes sense)

`checkout scm` does not work for me btw

I would be grateful if someone could confirm I'm on the right track, could
suggest improvements or confirm that it won't always be like this :)

#!groovy

githubCredentials = 'github_credentials'
def projectBranch = "${env.BRANCH_NAME}"

node {

def javaHome = tool "java8" // ensure Java 8 is installed
def projectRepoURL = 'g...@github.com:tonymurphy/jenkins-test.git'
echo "${env.getEnvironment()}"
def mvnHome  = tool "mvn-3.2.2"

wrap([$class: 'AnsiColorBuildWrapper', colorMapName: 'xterm']) {

stage "Checkout"
sh("git config --global credential.helper cache")
checkout([$class   : 'GitSCM',
  branches : [[name: projectBranch]],
  extensions   : [[$class:
'RelativeTargetDirectory', relativeTargetDir: 'jenkins-test'],
[$class: 'CheckoutOption', timeout: 10]],
  userRemoteConfigs: [[credentialsId:
githubCredentials, url: projectRepoURL]]])

stage 'Build'
withEnv(["PATH+ACTIVATOR=${tool 'activator-1.3.x'}",
"PATH+JDK=${javaHome}/bin", "JAVA_HOME=${javaHome}"]) {
dir("jenkins-test") {
sh "${mvnHome}/bin/mvn clean compile test "
step([$class: 'ArtifactArchiver', artifacts:
'**/target/*.jar', fingerprint: true])
step([$class: 'JUnitResultArchiver', testResults:
'**/target/surefire-reports/TEST-*.xml'])

}
}
}
}

Thanks!

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