Re: GitHub and Bitbucket branch source UI refactoring

[Michael Kobit]

We haven't upgraded to the latest plugin yet (partially because of this) so 
no workaround yet. We are going to do a test cycle in the next few weeks. I 
opened https://issues.jenkins-ci.org/browse/JENKINS-45860 a few days ago to 
hopefully understand how to implement it since I originally implemented 
support for OrganizationFolder in the Job DSL plugin.

On Thursday, August 3, 2017 at 11:28:38 AM UTC-5, Tim Downey wrote:
>
> Hi Michael -- I finally go around to upgrading as well and am facing the 
> same problem.  Have you worked around this?  Are you just supplying the XML 
> directly?
>
> On Tuesday, July 11, 2017 at 8:39:29 PM UTC-4, Michael Kobit wrote:
>>
>> Finally got some time to try it out (sorry!) and I know the PR has 
>> already been merged, but UI looks great, and the contextual help menus 
>> make it easy to pick up. Awesome job!
>>
>> Only thing I noticed is no built-in Job DSL support - we use the Job DSL 
>> entirely to create and setup all of our Organization folders, and I didn't 
>> see any generated DSL methods under 
>> */plugin/job-dsl/api-viewer/index.html#path/organizationFolder-organizations-bitbucket*
>> .
>>
>> On Thu, Jun 29, 2017 at 9:43 AM Mark Waite <mark.ea...@gmail.com> wrote:
>>
>>> I think I have detected the difference between by multi-branch pipelines 
>>> with GitHub branch sources.
>>>
>>> The problem job is a GitHub private repository (
>>> https://github.com/MarkEWaite/jenkins-bugs-private), while the working 
>>> job is a GitHub public repository (
>>> https://github.com/MarkEWaite/jenkins-bugs) .
>>>
>>> When I configure the private repository job, it presents the list of 
>>> repositories but only includes public repositories in the list.  The 
>>> credentials are valid and are used in other jobs, but it is as though the 
>>> list of repositories is not being refreshed with the credentials.
>>>
>>> Mark Waite
>>>
>>> On Thu, Jun 29, 2017 at 8:27 AM Mark Waite <mark.ea...@gmail.com> wrote:
>>>
>>>> I'm using latest betas (as far as I can tell).  The GitHub source is 
>>>> now working in the cases that were failing previously.  Thanks very much 
>>>> for that!
>>>>
>>>> Unfortunately, when I open the "Configure" page for one of my 
>>>> multi-branch pipeline job that is using GitHub as a branch source, it 
>>>> reverts the repository choice to the top of the list, instead of showing 
>>>> the originally selected repository.
>>>>
>>>> When I open the "Configure" page for another of my multi-branch 
>>>> pipeline jobs that is using GitHub as a branch source, it retains the 
>>>> repository choice.
>>>>
>>>> Unfortunately, I don't know what is different between those two cases 
>>>> of a GitHub branch source for a multi-branch pipeline.
>>>>
>>>> I'll let you know if I identify key attributes which make the two cases 
>>>> behave differently.
>>>>
>>>> Mark Waite 
>>>>
>>>>
>>>> On Monday, June 26, 2017 at 10:04:00 PM UTC-6, Michael Neale wrote:
>>>>>
>>>>> I retested with latest betas and looking good (binary compat, 
>>>>> migration etc). 
>>>>>
>>>>> On Monday, June 26, 2017 at 11:46:49 PM UTC+10, Stephen Connolly wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 26 June 2017 at 06:13, Kevin Burnett <kbur...@rosettastone.com> 
>>>>>> wrote:
>>>>>>
>>>>>>> This is so good. :)
>>>>>>>
>>>>>>
>>>>>> Great to hear it. I love feedback (+ve or -ve beats none)
>>>>>>  
>>>>>>
>>>>>>>
>>>>>>> The pre and post diffs looked right, and the new UI and 
>>>>>>> functionality gives me everything that I was hoping for.
>>>>>>>
>>>>>>
>>>>>> w00t
>>>>>>  
>>>>>>
>>>>>>>
>>>>>>> I'm going to remove the "discover pull requests from [everywhere]" 
>>>>>>> behaviors and select "Only branches that are also filed as PRs" on 
>>>>>>> production as soon as possible.
>>>>>>>
>>>>>>> Michael Neale mentioned that one issue he had seen "does look be

Re: GitHub and Bitbucket branch source UI refactoring

[Michael Kobit]

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

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

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

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



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

> This is so good. :)
>

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


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

 w00t


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

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

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

Re: GitHub and Bitbucket branch source UI refactoring

[Michael Kobit]

I'm going to have time to do this today. Are there newer alphas available?

On Mon, Jun 26, 2017, 08:13 Kevin Burnett  wrote:

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

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

 Earlier I reported an NPE when configuring a multi-branch pipeline that
 uses GitHub as source instead of Git as source.  The NPE was resolved by
 removing the multiple-scms plugin.  Unfortunately, the 404 is still there,
 along with a stack trace that starts with this:

 Jun 23, 2017 9:51:38 AM hudson.ExpressionFactory2$JexlExpression
 evaluate
 WARNING: Caught exception evaluating:
 descriptor.calcFillSettings(field,attrs) in
 /job/Git-Client-Folder/job/git-client-pipeline-github/configure. Reason:
 java.lang.IllegalStateException: class
 org.jenkinsci.plugins.github_branch_source.GitHubSCMSource$DescriptorImpl
 doesn't have the doFillCredentialsIdItems method for filling a drop-down
 list
 java.lang.IllegalStateException: class
 org.jenkinsci.plugins.github_branch_source.GitHubSCMSource$DescriptorImpl
 doesn't have the doFillCredentialsIdItems method for filling a drop-down
 list
 at hudson.model.Descriptor.calcFillSettings(Descriptor.java:412)
 at sun.reflect.GeneratedMethodAccessor578.invoke(Unknown Source)
 at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:498)
 at
 org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:258)
 at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:104)
 at
 org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83)
 at
 org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57)
 at
 org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51)
 at
 org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80)
 at
 hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:74)
 at
 org.apache.commons.jelly.parser.EscapingExpression.evaluate(EscapingExpression.java:24)
 at
 org.apache.commons.jelly.impl.ExpressionScript.run(ExpressionScript.java:66)
 at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)

 I'm not sure how to provide a repeatable condition for that bug yet,
 but wanted to alert you about it.  I won't investigate further on it until
 after the end of the working day today.

 Mark Waite

 On Friday, June 23, 2017 at 7:32:54 AM UTC-6, Stephen Connolly wrote:
>
> How do you find the new UI compared with the previous one?
>
> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to jenkinsci-de...@googlegroups.com.
>>>
>> To view this discussion on the web visit
>>> 

Re: GitHub and Bitbucket branch source UI refactoring

[Michael Kobit]

github.com/stephenc/64ef58783b4438a126ad4e3f43062df1 and
>>>> save the output to smoke-post-rescan.txt
>>>>
>>>> At this point, do a diff between smoke-pre-upgrade.txt and
>>>> smoke-post-rescan.txt
>>>>
>>>> You are looking for three classes of difference:
>>>>
>>>> a. branch jobs that have been rebuilt for no reason (i.e. the revision
>>>> is the same)
>>>> b. branch jobs that have disappeared for no good reason (i.e. the
>>>> branch is still present in the backing scm)
>>>> c. branch jobs that have suddenly appeared for no good reason (i.e. the
>>>> branch was there before but not found) [expecting some of these for
>>>> BitBucket PRs from forks, but only after configuration updated, saved and
>>>> another rescan performed]
>>>>
>>>> My expectation is that nobody will have these kinds of issues.
>>>>
>>>> Also try out the new UI to see what you think.
>>>>
>>>> Please report back your testing results either way. Don't forget to
>>>> report back your UI feedback too ;-)
>>>>
>>>> After doing that test in a throw-away Jenkins, you can *optionally*
>>>> repeat the test on a *more* production*-like* (emphasis on being
>>>> production-like not production) instance... but this is code that has not
>>>> yet completed code review (hence -alpha-1 not -beta-1) so it is at your own
>>>> risk. There are additional issues to be aware when using more
>>>> production-like environment:
>>>>
>>>> a. You may have builds that were assuming branches were full clones,
>>>> now the refspec is tightly reduced to minimize clone time. If you need a
>>>> full clone you will need to add the "Advanced Clone" behaviour.
>>>> b. Mercurial repositories on Bitbucket Cloud do not support merge
>>>> commits for PR building (yet)
>>>> c. Credential domains were not being correctly compared so as a result
>>>> - if you are using credential domains to help sort credentials - there may
>>>> be cases where the credentials are now searched for in a different domain
>>>> than you had them in, so your domains may need reconfiguration to have the
>>>> credentials found by the multibranch project / org folder.
>>>> d. The pipeline snippitizer is generating $class style for some of the
>>>> GitHub and BitBucket specific behaviours, this is because my plan is to
>>>> further consolidate the implementations and have a single shared
>>>> implementation of each for these plugins, that way they can have a single
>>>> @Symbol annotation... if that is too difficult then the @Symbol would need
>>>> to be prefixed with gitHub / bitbucket respectively, e.g. gitHubBranches,
>>>> bitbucketBranches for the discover branches behaviour.
>>>>
>>>>
>>>> Thanks in advance
>>>>
>>>> -Stephen
>>>>
>>>> On 18 June 2017 at 15:53, Michael Kobit <mko...@gmail.com> wrote:
>>>>
>>>>> I may be able to help with this as well.
>>>>>
>>>>> On Fri, Jun 16, 2017, 17:28 Dan Tran <dant...@gmail.com> wrote:
>>>>>
>>>>>> I will give it a spin too.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> -Dan
>>>>>>
>>>>>> On Friday, June 16, 2017 at 11:57:26 AM UTC-7, Kevin Burnett wrote:
>>>>>>>
>>>>>>> we'd be down to try that, yes. thanks for making these changes in a
>>>>>>> way that will benefit the product long-term!
>>>>>>>
>>>>>>> fingers are crossed that there's already a built-in way to pretend
>>>>>>> like pull requests don't exist! you're already building the branches; 
>>>>>>> why
>>>>>>> also build the pull requests, eh? :)
>>>>>>>
>>>>>>> thanks!
>>>>>>> kb
>>>>>>>
>>>>>>>
>>>>>>> On Friday, June 16, 2017 at 2:35:54 PM UTC-4, Mark Waite wrote:
>>>>>>>>
>>>>>>>> I'd like to be part of the beta test.
>>>>>>>>
>>>>>>>> Mark Waite
>>>>>>>>
>>>>>>>> On Fri, Jun 16, 2017 at 12:19 PM Stephen Connolly <
>>>>>>&

Re: GitHub and Bitbucket branch source UI refactoring

[Michael Kobit]

I may be able to help with this as well.

On Fri, Jun 16, 2017, 17:28 Dan Tran  wrote:

> I will give it a spin too.
>
> Thanks
>
> -Dan
>
> On Friday, June 16, 2017 at 11:57:26 AM UTC-7, Kevin Burnett wrote:
>>
>> we'd be down to try that, yes. thanks for making these changes in a way
>> that will benefit the product long-term!
>>
>> fingers are crossed that there's already a built-in way to pretend like
>> pull requests don't exist! you're already building the branches; why also
>> build the pull requests, eh? :)
>>
>> thanks!
>> kb
>>
>>
>> On Friday, June 16, 2017 at 2:35:54 PM UTC-4, Mark Waite wrote:
>>>
>>> I'd like to be part of the beta test.
>>>
>>> Mark Waite
>>>
>>> On Fri, Jun 16, 2017 at 12:19 PM Stephen Connolly <
>>> stephen.al...@gmail.com> wrote:
>>>
 Just a quick status update.

 In final stages of this work now. Bobby is being a superstar and
 reviewing my 13k LoC change on the Bitbucket branch source - brings lots of
 feature parity with GitHub and adds the configuration ability of the pure
 Git branch source

 I am finalising the GitHub Branch Source changes... likely to be
 another big PR

 Then there's a 5k LoC change in the Git plugin

 Plan is to try and get all merged next week and cut a beta

 I'll be looking for people to help test at that stage.

 Please respond if you think you can help (lots of bugs fixed as a side
 effect of the refactoring - it makes things more easy to test => I found
 and fixed bugs)
 --
 Sent from my phone

 --
 You received this message because you are subscribed to the Google
 Groups "Jenkins Developers" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to jenkinsci-de...@googlegroups.com.
 To view this discussion on the web visit
 https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxfYrZphgYDXFD3i%2Bo_7eDn7mn2qVrzJz6wFaoVkNmc%2Bw%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/5dd15ac2-b8a2-4ebd-bb4a-3bffa4815227%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/CALELY9GHbX4WuHdDKM8-bU1xR5voh-NsfHeQXNAxMjJpXkiwrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: sh returnStdout:true leaking deleted file handles

[Michael Kobit]

We see massive file handle leaks on a different Jenkins we have that does
not use Pipeline. The leaks were on the build logs. We haven't figured out
if it is a plugin or something in Jenkins core and we just dealt with it by
restarting Jenkins nighty.

On another instance we use pipelines extensively (and the returnStdout) but
haven't ran into file handle leaks hitting the limit. I'll have to check
today to see if we are just getting lucky.

On Wed, Jun 7, 2017, 04:39 'Kieran Shaw' via Jenkins Users <
jenkinsci-users@googlegroups.com> wrote:

> Anyone got any thoughts or experience with this:
> https://issues.jenkins-ci.org/browse/JENKINS-43639?focusedCommentId=302114=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-302114
>
> --
> 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/2fd3edc0-79d3-4e4c-9f79-611a929b25ba%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/CALELY9HqdwF9AxJWBUFqbAt41JWGXXC-3h84v8BmRGfDwDcYrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Resume pipeline on a different slave

[Michael Kobit]

Are there other ways than that plugin? It seems like agents should be
considered fungible in general. There doesn't seem to be any way on Dumb
Slave that I can see.

On Tue, May 30, 2017, 08:48 Arvind Jayaprakash  wrote:

> I face the same issue with Mesos and my understanding is that there is a
> way to declare slaves as *ephemeral* i.e.they will never come back once
> they are gone. This appeared to be something that the cloud provider plugin
> (mesos in this case) needs to worry about.
>
>
> On Thursday, May 25, 2017 at 7:11:57 PM UTC+5:30, Michal Tekel' wrote:
>>
>> Hi,
>>
>> I have a question if it is possible to configure Jenkins to resume
>> pipeline build (e.g. after Jenkins restart) on any slave which has required
>> labels. Currently jenkins will only try to resume on the exactly same build
>> slave the pipeline was running on before. But sometimes, this slave is
>> never coming back (e.g. it was a mesos slave and the task is expired). Such
>> jobs can then never resume, even though jenkins has enough build slaves of
>> required type available after restart.
>>
>> 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/4ed72f0c-e3dc-479a-9b61-effdcdb71842%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/CALELY9E6YsP1zZWBmoL9uePwbmfZYabe-d12zrdZFAXwiauNCA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: One Jenkinsfile per repo in multi-branch workflows?

[Michael Kobit]

Be careful if you do use the job DSL as you will have to deal with Groovy
sandbox permissions for job creation.

On Fri, May 19, 2017, 09:20 Matt Stave  wrote:

> You can use a JobDSL statement in the Jenkinsfile in the root of your repo
> to generate other jobs.  Those jobs wouldn't be triggered by subsequent
> repo changes, unless you add a call to them in your main Jenkinsfile - they
> also could be triggered on-demand, through replay, a cron ...
>
> --- Matt
>
>
> On Thursday, May 18, 2017 at 9:38:28 AM UTC-5, David Aldrich wrote:
>>
>> Hi
>>
>>
>>
>> As the free-style Multi-Branch Project plugin is deprecated, I am
>> experimenting with the Multibranch Pipeline job type.
>>
>>
>>
>> With the Multi-Branch Project plugin it was possible to have multiple
>> multi-branch jobs.  We took advantage of that and had multiple jobs to
>> build different executables in the repo and to run different regression
>> tests, with different polling periods.
>>
>>
>>
>> It seems that the Multibranch Pipeline supports only one build script
>> per repo, defined by the JenkinsFile in the root directory.
>>
>>
>>
>> This seems to me to be restrictive.  What is the thinking behind it and
>> is it possible to define multiple multi-branch pipeline jobs per repo?
>>
>>
>>
>> Best regards
>>
>>
>>
>> David
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/4b45b914-1cdf-4dfe-9076-330fea88798c%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/CALELY9F%3DWixhtxvoW0rFORs_Xtgp8N79dn3FWi8CMU4xgyB5Gw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline: combining milestone, lock and parallel executions

[Michael Kobit]

That is useful! Did you discover an open issue for that? Is it just not
supported yet?

On Sun, Jan 15, 2017 at 4:17 PM ST  wrote:

> After even more investigation it seems that *nested lock() statements are
> not supported*. Thats what caused all my headache. When using a single
> lock() statement with inversePrecedence:true, and two milestone()
> statements, then the LIFO queue for running the integration tests works
> like a charm.
>
> Hope this info is helpful to other users!
>   stefan.
>
> Den 15 jan. 2017 1:15 em skrev "ST" :
>
> Found this Jenkins bug which I guess is the cause of my problems, so added
> a comment there:
> https://issues.jenkins-ci.org/browse/JENKINS-40787
>
> On Sun, Jan 15, 2017 at 12:28 AM, ST  wrote:
>
> I'm trying to understand why the construct below doesnt work as I expect
> it to, but have spent hours over it without success.
>
> We use git with many branches, and a multi-branch pipeline in Jenkins to
> build and test. The total build takes more than an hour, where 90% is
> integration tests ((see build stage below). When several git push events
> occur within a few minutes, I want a LIFO queue for the integration tests
> and I also want to abort any older builds waiting to run the integration
> tests.
>
> I believe that the pipeline code below should do that by lock()'ing per
> branch. However I'm seeing that when 2 builds are waiting for the lock
> while an earlier build is running the integration tests, then when that
> earlier build releases the lock, both of the other two builds can acquire
> the lock simultaneously and start running integration tests.
>
> The lockable resources "integrationTests-" get created
> dynamically, in case that plays any role.
>
> Anything I'm missing in my line of thoughts?
>
> We run on Jenkins 2.37, with latest version of all pipeline plugins.
>
>
> // ... other stages to build, static code analysis, unit tests etc
>
> stage('Integration testing') {
> milestone(label: 'IntegrationTests-AttemptingToStart')
> String lockResource = "integrationTests-${env.BRANCH_NAME}"
> lock(resource: lockResource, inversePrecedence: true) {
> try {
> integrationTestsStage()
> } finally {
> echo "Done with all integration tests."
> milestone(label:'IntegrationTests-Done') // abort all older
> builds (for same git branch) that haven't passed this milestone yet
> }
> }
> }
>
> Anyone any input or helping thoughts? Thanks,
>  stefan.
>
>
> --
> 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/CABwQARuA0ZPmZfPpd2wQ%3DOyF-JK2pRmW9JNL%2B_G-bq81yi%2Bq0A%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/CALELY9Ed9kwDOpE9WfEn9MciwCO2VqhuUuVxYqPMpowzuVRr_Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Read files from workspace in multibranch pipeline scm?

[Michael Kobit]

Your problem is the new File( piece. The pipeline code runs on a flyweight
executor on the master, and the various steps can run on allocated nodes.
You might be able to do something using FilePath
, but I think you could
use the findFiles step

which
would get you some information. You could then use the readFile step

to
get the file contents into your pipeline execution.

On Tue, Dec 13, 2016 at 4:36 PM anton kropp  wrote:

> I'm having some issues reading files from the local workspace. As part of
> my build a set of artifact files are created and I'd like to iterate over
> them, parse their json contents, and act on it in a pipeline step. However,
> I can't seem to get reading files from the workspace to work.
>
> My stage looks like:
>
>
> stage('Push docker containers') {
> def slurper = new JsonSlurper()
>
> def files = new File(env.WORKSPACE).listFiles()
>
> for (int i = 0; i < files.size(); i++) {
> def file = files[i]
> println(file.name)
> if (file.name.endsWith(".json")) {
> def json = slurper.parse(file)
>
> json.each { key, value ->
> // do stuff
> }
> }
> }
> }
>
> I keep getting a null pointer on files.size. I've tried to ls the
> workspace to see whats in it, but nothing shows up.   Whats the recommended
> approach here?
>
> Thanks
> -Anton
>
> --
> 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/fd65242f-f3a7-4ba3-8717-3146639d759a%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/CALELY9Gr0nrmt69eS8KXAu0r4tHYqJA4GGk9ZnLv7XTMn%3DF_4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline: Hos to test them locally

[Michael Kobit]

You can use the "Replay" option, which might help you iterate a little bit
faster. There isn't really a good way to test and validate that your
pipeline is correct other than just running it.

https://issues.jenkins-ci.org/browse/JENKINS-33925 is open for a test
framework for Jenkinsfile.

On Fri, Dec 9, 2016 at 1:20 AM Victor Martinez <
victormartinezru...@gmail.com> wrote:

> Hi there,
>
> Just wondering if there is any new supported feature of testing
> Jenkinsfile, aka pipelines, locally, if so, where can i find some
> examples/docs? I want to get rid of the manual and tedious process of
> pushing changes to my repo then look at the jebkibs job andsee whether it
> does what i coded. I'd like to speed up my development with lets say some
> TDD. If no, will it be supported in the near future? Or it doesnt make
> sense?
>
> Thanks guys
>
> --
> 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/c6122b07-85f3-407b-8e81-ae23651e0b27%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/CALELY9HHZ1wnJq6fvXgBS5DZGxTjMRZo%2B_PxpRZNQDHBJ5ubsQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: how to use git commands inside a Multi Branch Project?

[Michael Kobit]

We haven't really figured both this Git issue yet, but another problem we 
ran into when running builds in Docker containers is described in 
https://go.cloudbees.com/docs/support-kb-articles/CloudBees-Jenkins-Enterprise/Why-am-I-unable-to-authenticate-via-sshagent-inside-docker-.html
 where 
the socket path is too long.

On Wednesday, November 30, 2016 at 5:20:22 AM UTC-6, Torsten Reinhard wrote:
>
> Hi all,
>
> I have a Multi Branch Project, using a *.git Repository. All branches are 
> detected and the checkout is working. 
> In my JenkinsFile I need to execute some "git" commands, like:
>
> ...
> sh "git tag -d FOR_INTEGRATION_TESTING" // removes 
> the tag in local env.
> sh "git push origin :refs/tags/FOR_INTEGRATION_TESTING"// removes 
> the tag in remote env.
> sh "git tag -a FOR_INTEGRATION_TESTING"// adds 
> the tag to different commit
> sh "git push origin FOR_INTEGRATION_TESTING"// pushes the 
> change to the remote
> ...
>
> How can I apply the credentials here ? 
> When trying 
>
> withCredentials [$class: 'UsernamePasswordMultiBinding', credentialsId: 
> git_creds, usernameVariable: 'G_USER', passwordVariable: 'G_PASS'] {
>   ...
> }
>
>
> I see this exception:
>
> org.jenkinsci.plugins.credentialsbinding.impl.CredentialNotFoundException: 
> Credentials 'a378e16a-3d20-4465-aef1-b2bd233f15b6' is of type 'SSH Username 
> with private key' 
> where 
> 'com.cloudbees.plugins.credentials.common.StandardUsernamePasswordCredentials'
>  was expected
>
>
> Is there another class instead of "UsernamePasswordMultiBinding" I have to 
> use? 
>
> Thanx for pointing me in the right direction, 
>
> Torsten
>
>
>

-- 
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/50223fa8-6407-4d8b-8c21-028fc1b507a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Unmask credentials in pipeline

[Michael Kobit]

You can also do something like what I reported in this issue
https://issues.jenkins-ci.org/browse/JENKINS-38181 .

On Fri, Dec 9, 2016 at 1:20 PM Raja Chinnam 
wrote:

> Hi Sophie
> It works in a pipeline when I have that code in a function and have it
> return the values, like this:
> def getuname(){
> withCredentials([usernamePassword(credentialsId: 'builduser',
> passwordVariable: 'PASSWD', usernameVariable: 'USRNAME')]) {
> // some block
> return USRNAME
> }
> }
>
>
> Good luck
>
>
> On Wednesday, December 7, 2016 at 6:21:56 AM UTC-8, Sophie Field wrote:
>
> Hi Raja,
>
> Did you have any success with this? I'm using the withCredentials syntax
> in a build but I can't use/access the variables stored globally. Also for a
> pipeline project there isn't the option of including the variables in the
> build from the Configure page like you get from a freestyle project.
>
> On Tuesday, November 29, 2016 at 7:36:10 PM UTC, Raja Chinnam wrote:
>
> Hello
>
> How can I pass the username and password to my a custom application in the
> pipeline?
> I have username and password added as credentials and am using this code:
>
> withCredentials([[$class: 'UsernamePasswordMultiBinding', credentialsId:
> 'usrid', passwordVariable: 'USR', usernameVariable: 'PWD']]) {
> bat '''
> echo off
> Query.exe -u %USR% -p %PWD%
> '''
> }
>
> my application fails with the message: 'invalid user ""'
>
> thank you.
>
> --
> 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/c4611aea-c328-40bf-866c-8a3b16c5c554%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/CALELY9EttM9zBFY8UOcUGd4mpoPYVgj18n8wyc5U%2BNX-ztZFUg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Bitbucket webhook triggering 2 builds at once

[Michael Kobit]

We use PR builds and notifications pretty heavily, so that is a very useful
feature for us. If you use the normal Multibranch features, you have to
either write your own code (global library is what we did this before BBBS
was available for Bitbucket Server) or use a plugin with a step. Another
one is the 1 job per project rather the 1 job per repository which has
reduced quite a bit of the overhead for each project. A nice value-add to
further reduce needed configuration is auto-registration for the webhooks
is currently open (
https://github.com/jenkinsci/bitbucket-branch-source-plugin/pull/21 ).

The plugin that you mentioned above does not support BBBS, and I'm not sure
it ever will (see
https://issues.jenkins-ci.org/browse/JENKINS-33507?focusedCommentId=260944=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-260944
 and
https://github.com/Nerdwin15/stash-jenkins-postreceive-webhook/issues/171 )
which is one of the reasons we have almost completely switched

We were (and still are) a bit cautious about about the newer Bitbucket
plugin (
https://marketplace.atlassian.com/plugins/nl.topicus.bitbucket.bitbucket-webhooks/server/overview
) but it has worked really well for us. Overall, we have found switching
from the Multibranch to BBBS has been a great decision and very valuable.

On Tue, Nov 15, 2016 at 11:51 AM Tim Webster <tim.webs...@gmail.com> wrote:

Hi,

Bear with me here - I'm not too worried about PRs right now (although I may
in the future), but doesn't the 'regular' multibranch pipeline plugin
already give you automatic branch indexing/builds?  What does BBBS give you
that it doesn't (or is it just the PR stuff)?

I would like to choose a solution that is supported and works properly -
the Blue Ocean support is good because I like the looks of that.  But right
now getting something as simple as push notifications and build triggers
working is turning out to be much trickier than I would expect.

I have a feeling the double build thing might have to do with merges, as
after I 'fixed' the problem by deleting build history for my jobs, it only
occurred after that on merge builds.  This looked similar (which is related
to the issue you sent me earlier):

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

Thanks,

Tim



On Tue, Nov 15, 2016 at 3:36 PM, Michael Kobit <mko...@gmail.com> wrote:

Sorry, I replied without understanding the full message entirely.

We still use that plugin with the Multibranch job type in some places but
have been transitioning to using
https://wiki.jenkins-ci.org/display/JENKINS/Bitbucket+Branch+Source+Plugin .
The Bitbucket plugin you previously mentioned does not work with the
Bitbucket Branch Source Plugin, which is why we have been switching. BBBS
helps in a few ways:

   - Automatic PR indexing/builds
   - Automatic PR notifications
   - Automatic branch indexing/builds
   - Integration with upcoming Blue Ocean
   <https://jenkins.io/projects/blueocean/>


The new Bitbucket Server plugin that works with BBBS is
https://marketplace.atlassian.com/plugins/nl.topicus.bitbucket.bitbucket-webhooks/server/overview
 .

In terms of why you are seeing double builds, I don't know why that is
happening.

On Mon, Nov 14, 2016 at 5:56 PM Tim Webster <tim.webs...@gmail.com> wrote:

Hi Michael,

Thanks for your reply.

I don't actually have that plugin installed (Bitbucket Branch Source
Plugin).  Should I?

To be honest I'm not sure what plugins (on both sides) I should be using.
What I had seemed to work OK for a while - until now.

Thanks,

Tim


On Mon, Nov 14, 2016 at 11:19 PM, Michael Kobit <mko...@gmail.com> wrote:

Sorry for mobile link:

https://issues.jenkins-ci.org/plugins/servlet/mobile#issue/JENKINS-36283

That issue is for customizing what is built by the plugin.

On Mon, Nov 14, 2016, 16:43 Tim Webster <tim.webs...@gmail.com> wrote:

Hi,

For some reason, my Bitbucket webhooks are triggering 2 Jenkins builds at
once in multibranch pipeline projects.

One build will have a commit notification as the trigger, while the other
one will have 'branch indexing' as the trigger (at least I think it's the
trigger).

Nothing has changed on the Bitbucket side, and it all used to work fine
which makes me think the problem is on the Jenkins side of things...

The only changes I've made are upgrading some pipeline plugins and setting
some job properties in the Jenkinsfile (for discard old builds plugin), but
it's worked OK for the past few days.

It also seems to happen on some projects, but not others.

Does anyone know where I should start looking?  I'm relatively new to both
Jenkins and Bitbucket.

I'm using:

Jenkins v2.30
Bitbucket v4.8.4

and this Bitbucket Plugin:

https://marketplace.atlassian.com/plugins/com.nerdwin15.stash-stash-webhook-jenkins/server/overview


Thanks...

-- 
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this

Re: Bitbucket webhook triggering 2 builds at once

[Michael Kobit]

Sorry, I replied without understanding the full message entirely.

We still use that plugin with the Multibranch job type in some places but
have been transitioning to using
https://wiki.jenkins-ci.org/display/JENKINS/Bitbucket+Branch+Source+Plugin .
The Bitbucket plugin you previously mentioned does not work with the
Bitbucket Branch Source Plugin, which is why we have been switching. BBBS
helps in a few ways:

   - Automatic PR indexing/builds
   - Automatic PR notifications
   - Automatic branch indexing/builds
   - Integration with upcoming Blue Ocean
   <https://jenkins.io/projects/blueocean/>


The new Bitbucket Server plugin that works with BBBS is
https://marketplace.atlassian.com/plugins/nl.topicus.bitbucket.bitbucket-webhooks/server/overview
 .

In terms of why you are seeing double builds, I don't know why that is
happening.

On Mon, Nov 14, 2016 at 5:56 PM Tim Webster <tim.webs...@gmail.com> wrote:

> Hi Michael,
>
> Thanks for your reply.
>
> I don't actually have that plugin installed (Bitbucket Branch Source
> Plugin).  Should I?
>
> To be honest I'm not sure what plugins (on both sides) I should be using.
> What I had seemed to work OK for a while - until now.
>
> Thanks,
>
> Tim
>
>
> On Mon, Nov 14, 2016 at 11:19 PM, Michael Kobit <mko...@gmail.com> wrote:
>
> Sorry for mobile link:
>
> https://issues.jenkins-ci.org/plugins/servlet/mobile#issue/JENKINS-36283
>
> That issue is for customizing what is built by the plugin.
>
> On Mon, Nov 14, 2016, 16:43 Tim Webster <tim.webs...@gmail.com> wrote:
>
> Hi,
>
> For some reason, my Bitbucket webhooks are triggering 2 Jenkins builds at
> once in multibranch pipeline projects.
>
> One build will have a commit notification as the trigger, while the other
> one will have 'branch indexing' as the trigger (at least I think it's the
> trigger).
>
> Nothing has changed on the Bitbucket side, and it all used to work fine
> which makes me think the problem is on the Jenkins side of things...
>
> The only changes I've made are upgrading some pipeline plugins and setting
> some job properties in the Jenkinsfile (for discard old builds plugin), but
> it's worked OK for the past few days.
>
> It also seems to happen on some projects, but not others.
>
> Does anyone know where I should start looking?  I'm relatively new to both
> Jenkins and Bitbucket.
>
> I'm using:
>
> Jenkins v2.30
> Bitbucket v4.8.4
>
> and this Bitbucket Plugin:
>
>
> https://marketplace.atlassian.com/plugins/com.nerdwin15.stash-stash-webhook-jenkins/server/overview
>
>
> 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/CABrquLxuA6tYm_vR-wJpcy6V3m2QC%2B%2BYdBNfoY%3Di2wGW%3Dc%3DR5w%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-users/CABrquLxuA6tYm_vR-wJpcy6V3m2QC%2B%2BYdBNfoY%3Di2wGW%3Dc%3DR5w%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
>
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/CALELY9Gv5Z2Ai35wUkUCu0u%3D4LmB6rbYDox6vqcxa7xYDRVfWw%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-users/CALELY9Gv5Z2Ai35wUkUCu0u%3D4LmB6rbYDox6vqcxa7xYDRVfWw%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
>
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-users/CABrquLwnd%3DpZnOGCjxo4XP7Yqh_fa37x0kD677umUikMw_mZVA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-users/CABrquLwnd%3DpZnOGCjxo4XP7Yqh_fa37x0kD677umUikMw_mZVA%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Bitbucket webhook triggering 2 builds at once

[Michael Kobit]

Sorry for mobile link:

https://issues.jenkins-ci.org/plugins/servlet/mobile#issue/JENKINS-36283

That issue is for customizing what is built by the plugin.

On Mon, Nov 14, 2016, 16:43 Tim Webster  wrote:

> Hi,
>
> For some reason, my Bitbucket webhooks are triggering 2 Jenkins builds at
> once in multibranch pipeline projects.
>
> One build will have a commit notification as the trigger, while the other
> one will have 'branch indexing' as the trigger (at least I think it's the
> trigger).
>
> Nothing has changed on the Bitbucket side, and it all used to work fine
> which makes me think the problem is on the Jenkins side of things...
>
> The only changes I've made are upgrading some pipeline plugins and setting
> some job properties in the Jenkinsfile (for discard old builds plugin), but
> it's worked OK for the past few days.
>
> It also seems to happen on some projects, but not others.
>
> Does anyone know where I should start looking?  I'm relatively new to both
> Jenkins and Bitbucket.
>
> I'm using:
>
> Jenkins v2.30
> Bitbucket v4.8.4
>
> and this Bitbucket Plugin:
>
>
> https://marketplace.atlassian.com/plugins/com.nerdwin15.stash-stash-webhook-jenkins/server/overview
>
>
> 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/CABrquLxuA6tYm_vR-wJpcy6V3m2QC%2B%2BYdBNfoY%3Di2wGW%3Dc%3DR5w%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/CALELY9Gv5Z2Ai35wUkUCu0u%3D4LmB6rbYDox6vqcxa7xYDRVfWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Writing integration tests for Global Libraries

[Michael Kobit]

Using the support for @Library seems like a much simpler way to go about 
testing it, and was thought about as the option. We were hoping to have 
turnaround time locally as well as having more codified tests. We have seen 
the Groovy CPS plugin bite us in the ass a few times, so we wanted to get 
some testing infrastructure in place and were hoping we could it as close 
to the writer as possible.

It will definitely be easier to set up a few simple jobs or something for 
us to run tests against the global libraries.

Thanks for the response.

On Monday, November 7, 2016 at 12:45:25 PM UTC-6, Michael Lasevich wrote:
>
> There is no reason why you cannot automate the local running of the 
> Jenkins tests. See how plugin development works - they have setup to start 
> a local Jenkins instance with plugin installed, and it should be relatively 
> simple to automate that to run test jobs and check for output. 
>
> That said, you are WAY overthinking this. A much simpler solution is to 
> store your library in a proper SCM and use the @Library's version support 
> to allow a job to specify the branch of the repo. Create a pre-production 
> branch and set up a validation job to trigger on commit of code to preprod 
> to test the pre-production version of the library. Validation job can 
> execute various tests against the pre-prod branch (which, if you desire, 
> can include executing of other jobs) and if everything passes, either 
> auto-merge the commit tested to production, or signal you that it is safe 
> to merge that commit. No additional infrastructure is required, use the 
> same Jenkins server you are already using with this library.
>
> The tricky part would be figuring out how to write proper validation tests.
>
> -M
>
>
>
>
> On Sunday, November 6, 2016 at 5:30:16 PM UTC-8, Michael Kobit wrote:
>>
>> I'm working on writing some global libraries using 
>> https://github.com/jenkinsci/workflow-cps-global-lib-plugin. My current 
>> process for iterating locally is:
>>
>>- Start up a local Jenkins instance
>>- Point the *globalLibs* directory to my global libraries repository
>>- Create a few jobs that use my global libraries
>>- Write some code
>>- Run jobs
>>- Check for results in logs
>>
>> This is inefficient and error prone.
>>
>> The workflow doesn't seem much better when using the recent @Library 
>> <https://github.com/jenkinsci/workflow-cps-global-lib-plugin#using-libraries>
>>  
>> support.
>>
>> My question is, what do I need to do to get some of the Jenkins 
>> infrastructure in place to write automated, integration tests for Jenkins 
>> pipelines jobs and Global libraries code?
>>
>> I am using Gradle, and was hoping to see if anybody else has been 
>> successful in setting up testing locally so I can validate that I my 
>> libraries work in an actual Jenkins pipeline execution with all of the 
>> Groovy CPS transformations and other nuances of writing Groovy libraries 
>> for Jenkins pipelines.
>>
>> My current *build.gradle* looks something like this, but I still haven't 
>> gotten it working:
>>
>> plugins {
>>   id 'build-dashboard'
>>   id 'groovy'
>> }
>> description = 'Libraries written for use with Jenkins Global Pipeline 
>> Libraries'
>>
>> repositories {
>>   jcenter()
>>   maven {
>> url 'http://repo.jenkins-ci.org/public'
>>   }
>>   mavenLocal()
>> }
>>
>> sourceSets {
>>   main {
>> groovy {
>>   // Jenkins Global Workflow Libraries requires sources to be at 'src'
>>   srcDirs = ['src']
>> }
>> java {
>>   srcDirs = []
>> }
>> resources {
>>   srcDirs = []
>> }
>>   }
>>   test {
>> groovy {
>>   // configure the test source set so that it is not part of the Global 
>> Pipeline Libraries
>>   srcDirs = ['unitTest']
>> }
>> java {
>>   srcDirs = []
>> }
>> resources {
>>   srcDirs = []
>> }
>>   }
>>   jenkinsIntegrationTest {
>> groovy {
>>   srcDirs = ['jenkinsIntegrationTest']
>> }
>> java {
>>   srcDirs = []
>> }
>> resources {
>>   srcDirs = []
>> }
>> compileClasspath += sourceSets.main.runtimeClasspath
>> runtimeClasspath += sourceSets.main.runtimeClasspath
>>   }
>> }
>>
>> configurations {
>>   jenkinsIntegrationTestCompile.extendsFrom testCompile
>>   jenkinsIntegrationTestRuntime.extendsFro

Writing integration tests for Global Libraries

[Michael Kobit]

I'm working on writing some global libraries using 
https://github.com/jenkinsci/workflow-cps-global-lib-plugin. My current 
process for iterating locally is:

   - Start up a local Jenkins instance
   - Point the *globalLibs* directory to my global libraries repository
   - Create a few jobs that use my global libraries
   - Write some code
   - Run jobs
   - Check for results in logs

This is inefficient and error prone.

The workflow doesn't seem much better when using the recent @Library 
 
support.

My question is, what do I need to do to get some of the Jenkins 
infrastructure in place to write automated, integration tests for Jenkins 
pipelines jobs and Global libraries code?

I am using Gradle, and was hoping to see if anybody else has been 
successful in setting up testing locally so I can validate that I my 
libraries work in an actual Jenkins pipeline execution with all of the 
Groovy CPS transformations and other nuances of writing Groovy libraries 
for Jenkins pipelines.

My current *build.gradle* looks something like this, but I still haven't 
gotten it working:

plugins {
  id 'build-dashboard'
  id 'groovy'
}
description = 'Libraries written for use with Jenkins Global Pipeline Libraries'

repositories {
  jcenter()
  maven {
url 'http://repo.jenkins-ci.org/public'
  }
  mavenLocal()
}

sourceSets {
  main {
groovy {
  // Jenkins Global Workflow Libraries requires sources to be at 'src'
  srcDirs = ['src']
}
java {
  srcDirs = []
}
resources {
  srcDirs = []
}
  }
  test {
groovy {
  // configure the test source set so that it is not part of the Global 
Pipeline Libraries
  srcDirs = ['unitTest']
}
java {
  srcDirs = []
}
resources {
  srcDirs = []
}
  }
  jenkinsIntegrationTest {
groovy {
  srcDirs = ['jenkinsIntegrationTest']
}
java {
  srcDirs = []
}
resources {
  srcDirs = []
}
compileClasspath += sourceSets.main.runtimeClasspath
runtimeClasspath += sourceSets.main.runtimeClasspath
  }
}

configurations {
  jenkinsIntegrationTestCompile.extendsFrom testCompile
  jenkinsIntegrationTestRuntime.extendsFrom testRuntime
}

tasks.create('jenkinsIntegrationTest', Test) {
  group = LifecycleBasePlugin.VERIFICATION_GROUP
  description = 'Runs tests against of actual Jenkins Pipelines'
  testClassesDir = sourceSets.jenkinsIntegrationTest.output.classesDir
  classpath = sourceSets.jenkinsIntegrationTest.runtimeClasspath
}

dependencies {
  compile 'org.codehaus.groovy:groovy-all:2.4.7'

  testCompile 'org.spockframework:spock-core:1.0-groovy-2.4'
  testCompile 'junit:junit:4.12'

  jenkinsIntegrationTestCompile 'org.jenkins-ci.main:jenkins-core:2.17'
  jenkinsIntegrationTestCompile 'org.jenkins-ci.main:jenkins-test-harness:2.17'
  jenkinsIntegrationTestCompile 
'org.jenkins-ci.main:jenkins-war:2.17:war-for-test@jar'
  jenkinsIntegrationTestCompile 'org.jenkins-ci.plugins:git:3.0.0:tests'
  jenkinsIntegrationTestCompile 
'org.jenkins-ci.plugins.workflow:workflow-cps-global-lib:2.4'
  jenkinsIntegrationTestCompile 
'org.jenkins-ci.plugins.workflow:workflow-support:1.15:tests'
  jenkinsIntegrationTestCompile 
'org.jenkins-ci.plugins.workflow:workflow-job:2.6'
}

// Make sure only the Groovy dependency is available.
// Other dependencies must be used with @Grab in the defined classes due to how 
Jenkins Global Libraries work
project.afterEvaluate {
  final compile = it.configurations.compile.dependencies
  if (compile.size() != 1 || compile.first().name != 'groovy-all') {
throw new GradleException('groovy-all must be the only dependency for the 
compile configuration')
  }
}


And an example spec (not executing yet because of missing dependencies) 

import jenkins.plugins.git.GitSampleRepoRule
import org.junit.Rule
import org.jvnet.hudson.test.RestartableJenkinsRule
import spock.lang.Specification

class ExampleIntegrationSpec extends Specification {

  @Rule
  RestartableJenkinsRule rr = new RestartableJenkinsRule()

  @Rule
  GitSampleRepoRule sampleRepo = new GitSampleRepoRule()

  def "my test"() {
expect:
true
  }
}


This is just based on some of the other test code I've seen in the actual 
Jenkins plugins.
Anybody have any luck or pointers for getting Global Library tests? What 
are the actual dependencies I need to declare to get this up and running?

-- 
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/a50859c5-f6e3-4854-83f4-b57073bc49e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: bitbucket & jenkins integration

[Michael Kobit]

Are you using Bitbucket Cloud or Server?

On Tue, Oct 25, 2016, 20:57 Eddú Meléndez Gonzales 
wrote:

Hi,

I am working with Jenkins 2 and Bitbucket Branch Source Plugin and I have
followed the following steps:

1. Create a new Item "Bitbucket Team/Project"
2. Set "Scan Credentials" (tested with credential from team member and
team/apitoken - Username and Password)
3. Enable "Auto-register webhooks"
4. Then, Jenkins perform "Folder computation"

This is working fine, scan all the projects which have Jenkinsfile in the
repo and when new commit is sent analysis is perform automatically. But,
when PR is sent the analysis is not performed. When, Folder computation is
Re-run then I got: *HTTP request error. Status: 403: FORBIDDEN*

I have a fork for this project so is obvious jenkins doesn't have access to
my PR because it is using another credentials but I am a team member too.

I'd like to know if I'm missing something or which kind of credentials
should I use?

Thanks in advance

Cheers,

-- 
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/335f22e7-562e-4b27-8bc3-a14e9e21bcd3%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/CALELY9Gt7PHc5xKetpXhP%2BJtmL3yZFXAFXJSYsOYhDcECLQafQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

locks vs stage w/concurrency

[Michael Kobit]

I believe the stage step with concurrency has been deprecated so I would avoid 
using that.

It sounds like you are looking for 
https://issues.jenkins-ci.org/plugins/servlet/mobile#issue/JENKINS-27039 
(milestone step).

-- 
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/c758e13a-c59c-4c8b-a0a6-36645c57477c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Automated Jenkins Plugin/Dependency Management

[Michael Kobit]

My fault explaining that

I know that I can extract it using the *jar* command, but I don't get the 
same "unzipped" output as running *java -jar jenkins.war*.

It looks like this happens because of some magic 
in https://github.com/jenkinsci/extras-executable-war that handles the 
unpacking and bootstrapping.

I'm wondering, is there a similar way to unpack the *jenkins.war* without 
actually running the service, so that I can then programmatically configure 
the JENKINS_HOME.

This might be the wrong approach or the totally wrong idea. I was probably 
going to move in the same direction that you said with using the 
https://github.com/jenkinsci/gradle-jpi-plugin to handle plugin dependency 
resolution, but plugins are not the only thing I want to configure. The 
Groovy init.d type scripts work, but it requires Jenkins to hit a certain 
lifecycle stage to run.

Jenkins just doesn't seem to lend itself well to configuration as code, but 
maybe I'm missing something. 

On Saturday, August 27, 2016 at 12:43:51 PM UTC-5, Jason Kulatunga wrote:
>
> Yep, the command is `jar xvf jenkins.war`, that will explode the war into 
> the current directory. 
>
> On Friday, August 26, 2016 at 12:27:00 PM UTC-7, Michael Kobit wrote:
>>
>> Is there a way to basically "unzip" the *jenkins.war* so that the 
>> plugins, workflow-libs, and other parts can be configured before actually 
>> running the service?
>>
>> On Wednesday, August 17, 2016 at 9:36:08 AM UTC-5, Jason Kulatunga wrote:
>>>
>>> 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 
>>> <https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527#.jieuao7e5>
>>>  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 
>>> <https://github.com/jenkinsci/gradle-jpi-plugin>.
>>>
>>> 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 
>>> <http://blog.thesparktree.com/post/149039600544/you-dont-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 thi

Re: Automated Jenkins Plugin/Dependency Management

[Michael Kobit]

Is there a way to basically "unzip" the *jenkins.war* so that the plugins, 
workflow-libs, and other parts can be configured before actually running 
the service?

On Wednesday, August 17, 2016 at 9:36:08 AM UTC-5, Jason Kulatunga wrote:
>
> 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 
> <https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527#.jieuao7e5>
>  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 
> <https://github.com/jenkinsci/gradle-jpi-plugin>.
>
> 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 
> <http://blog.thesparktree.com/post/149039600544/you-dont-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 
>>>

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.

Re: Automated Jenkins Plugin/Dependency Management

[Michael Kobit]

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 of the box for 99% of use cases. 
>
> Are there other people experiencing the same issue? I'm more than happy to 
> create my own open source solution, but I'd love to base it on an existing 
> (even unmaintained) project. 
>
> -Jason
>
>
> On Thursday, August 11, 2016 at 4:51:07 PM UTC-4, Baptiste Mathus wrote:
>>
>> IMO a Docker image with the right set of plugins you've tested, plus the 
>> security config you're talking about about forbidding any upgrade would 
>> seem a simpler way. And probably it would your life simpler if you somehow 
>> have to support all those different instances which can currently be 
>> actually quite different.
>>
>> HTH
>>
>> Le 11 août 2016 3:14 PM, "Jason Kulatunga"  a écrit :
>>
>> Hey Jenkins-Users,
>>
>> I manage almost a dozen Jenkins servers and our team has been having some 
>> issues with plugin management: such as locking our new installations to 
>> known working versions of some troublesome Jenkins plugins.
>> We use chef + Jenkins DSL to completely automate the initial installation 
>> of Jenkins, but we're not exactly thrilled with the way the Chef cookbook 
>> handles plugin installation and we've also verified that 
>> 'installNecessaryPlugins' does not actually respect the version parameter. 
>>
>> curl -XPOST 
>> http://192.150.23.105:8080/pluginManager/installNecessaryPlugins -d 
>> ''
>>
>> As such I've started looking into alternative means of locking plugins in 
>> an automated way during installation and I've come up with the following 
>> ideas:
>>
>> # An External Dependency Management Tool, eg Bundler, Pip, Berkshelf
>> Basically an executable that would:
>>
>>1. retrieve a list of all plugins installed in a specific Jenkins 
>>server using the API, and add them to a dependency graph (with metadata: 
>>installed, pinned, enabled, version)
>>2. look for a dependency config file (like Gemfile, Berksfile, 
>>requirements.txt)
>>3. iterate through all the uninstalled plugins in the dep config file 
>>and add them 

Re: Can I add a "publish" button to a build page

[Michael Kobit]

This above (input with timeout) is what we are currently doing. When the
milestone step is done (see
https://issues.jenkins-ci.org/plugins/servlet/mobile#issue/JENKINS-27039),
I believe we will switch to using that instead.

On Tue, Jul 12, 2016, 16:25 Vincent Latombe 
wrote:

> You could use an input step (
> https://jenkins.io/doc/pipeline/steps/pipeline-input-step/#code-input-code-wait-for-interactive-input)
> to require manual validation.
> Wrap it in a timeout
> https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/#code-timeout-code-enforce-time-limit
> to clean-up pending builds you didn't approve after a given time.
>
> Vincent
>
> 2016-07-12 22:57 GMT+02:00 Greg Smith :
>
>> I have exactly this same need, but with pipeline builds.
>>
>> The Promotion plugin works awesome for regular builds, but unfortunately
>> does not work with pipeline builds.
>>
>> I created this Jira to track enhancing the plugin to support pipeline
>> builds:  https://issues.jenkins-ci.org/browse/JENKINS-36089
>>
>> Has anyone found any other solution for this use case (Need to take
>> actions on a specific build) when using multibranch pipeline builds?
>>
>> Cheers,
>> Greg
>>
>>
>> On Tuesday, July 12, 2016 at 9:24:00 AM UTC-4, Eric Pyle wrote:
>>>
>>> You might take a look at the Promoted Builds plugin. It allows you to
>>> manually "promote" a particular build, and trigger other actions. It's
>>> designed exactly for this sort of situation.
>>>
>>> Eric
>>>
>>> On 7/12/2016 8:57 AM, Jonathan Hodgson wrote:
>>>
>>> Hi,
>>>
>>> If a build is successful (compiled correctly, passed all tests), I may
>>> then want to send it out to beta testers. Which means copying the built
>>> binary to a location where they can find it, and sending out emails. I
>>> don't want to do this for exery successful build though.
>>>
>>> A sensible solution is seems to me would be to have a button on the
>>> build page where I could trigger a groovy script to do this. Is there a
>>> plugin which would facilitate this?
>>>
>>> regards
>>>
>>> Jon
>>> --
>>> 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/22e1eeef-42a3-4604-ba1a-5731e1b91efd%40googlegroups.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>>
>>> * Eric Pyle *
>>> Release Engineer
>>> Lebanon
>>> +1 603-277-3060 (T)
>>> +1 603-359-8670 (M)
>>> eric...@cd-adapco.com
>>> http://www.cd-adapco.com
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-users+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-users/f081859c-0aa8-4fb5-8f42-6a6380f37577%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/CAH-zGChcR_D23TTJGnJQAkvvqMPDWW5%3DJnr-2fwuD%3DOr3MKNVw%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/CALELY9Ge9McEkoY3r7OfmNQ7UYmNZwD1Bkr%2BpBr14Wb9fUvdqQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: withCredentials not working in multibranch project?

[Michael Kobit]

There are a couple different things to notice here:


   1. Double quotes in Groovy is string interpolation 
   

  - Your *sh "cp $SETTINGS_LOCATION ./settings.xml"* is using string 
  interpolation and *$SETTINGS_LOCATION *is being evaluated in the 
  script, but that variable is not present
   2. *withCredentials* binds to an environment variable 
   
.
 
   So, *SETTINGS_LOCATION* *should* be available for execution on the 
   allocated nodes

There are a few ways I believe you could fix this:

   1. Use the *env* global variable (like previously mentioned) to 
   substitute in the value through the Groovy which will retrieve the 
   previously set environment variable by *withCredential*
  - 
*sh "cp ${env.SETTINGS_LOCATION} ./settings.xml" *
   2. Use single quotes to delay the evaluation of the $*SETTINGS_LOCATION 
*until 
   the script executes on the node and uses environment variable substituion 
   (I believe this would work, haven't tested it)
  - *sh 'cp $SETTINGS_LOCATION ./settings.xml'*
  
I believe the second example will not output the value to the logs (which 
may be important if you do other credentials substitutions, like 
UsernamePasswordMultiBinding)

On Friday, June 10, 2016 at 7:56:42 AM UTC-5, Michael Irwin wrote:
>
> Versions (current for each)...
> - Jenkins - 2.8
> - Credentials Plugin - 2.0.7
> - Credentials Binding Plugin - 1.7
> - Pipeline: Multibranch - 2.6
> (let me know if you need any others)
>
> - Working in a multibranch project
> - Created a "Secret File" credential in the Global scope (just for 
> testing) with id "settings-file".  
> - Jenkinsfile has:
>
> node {
>   ...
>   withCredentials([$class: 'FileBinding', credentialsId: 'settings-file', 
> variable: 'SETTINGS_LOCATION']) {
> sh "cp $SETTINGS_LOCATION ./settings.xml"
>   }
>   ...
> }
>
> When it runs, get hit with...
>
> groovy.lang.MissingPropertyException: No such property: SETTINGS_LOCATION for 
> class: groovy.lang.Binding
>
>
> Oddly, when I open the "Pipeline Syntax" at the project, I'm able to produce 
> a Groovy snippet for the credential.  But, if I open the "Pipeline Syntax" at 
> the branch level (within the project folder), there are no credentials 
> available for me to select in the snippet generator.  So, it seems that the 
> folder isn't getting the same visibility to the credential (even though it 
> was defined globally).
>
> Any pointers?
>
> --
> Michael Irwin
>
>

-- 
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/d575ffc9-b280-457a-90bc-ab01271fc3d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline script for Build Trigger

[Michael Kobit]

Based on what I can see on that issue, I believe that is the open issue you
should follow.

On Tue, May 17, 2016, 10:37 AM John Chandra <john...@bu.edu> wrote:

> Hi Michael, Thanks for your reference. So that means that there is an open
> issue regarding controlling the build trigger on Jenkins 2.0. Am I correct?
>
>
> On Tuesday, May 17, 2016 at 10:02:31 AM UTC-4, Michael Kobit wrote:
>>
>> I think https://issues.jenkins-ci.org/browse/JENKINS-34005 is what you
>> are looking for.
>>
>> On Monday, May 16, 2016 at 4:54:13 PM UTC-5, John Chandra wrote:
>>>
>>> Hi All,
>>>
>>> Is there any way to configure a build trigger using pipeline script in
>>> Jenkinsfile? We still want to trigger the build when a change is pushed to
>>> GitHub. Is that still possible using Jenkinsfile in Jenkins 2.0? I've been
>>> searching around but I couldn't find a way to get this done.
>>>
>>> John
>>>
>> --
> 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/95ab38d2-fbcc-4bad-bb0f-01acf7306d09%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-users/95ab38d2-fbcc-4bad-bb0f-01acf7306d09%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Pipeline script for Build Trigger

[Michael Kobit]

I think https://issues.jenkins-ci.org/browse/JENKINS-34005 is what you are 
looking for.

On Monday, May 16, 2016 at 4:54:13 PM UTC-5, John Chandra wrote:
>
> Hi All,
>
> Is there any way to configure a build trigger using pipeline script in 
> Jenkinsfile? We still want to trigger the build when a change is pushed to 
> GitHub. Is that still possible using Jenkinsfile in Jenkins 2.0? I've been 
> searching around but I couldn't find a way to get this done.
>
> John
>

-- 
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/621d3c43-a11e-4d37-87b7-145ad188bd73%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Scheduled execution, windowing, and fan-in/fan-out with Jenkinsfile

[Michael Kobit]

I have a use case of where I want my pipeline to run an execution at a 
scheduled time, which may be externally or internally provided and may or 
may not be blocking. I'm still new to the Jenkinsfile and pipeline, but I'm 
wondering if others have any experience with any of the following types of 
use cases:

   - External time window blacklist/whitelist (think of a Google calendar 
   or some calendar provider that gives approval windows, where this is an 
   input in a fan-in scenario)
  - Allow all to pass through if in whitelist timewindow
  - Block changes and wait until time window is open. Take the newest 
  change and 'promote' (continue) with it
   - Internal time window/scheduler (run this nightly, once, and in a 
   nonblocking fashion with the latest code at this stage in this pipeline)
  - Run this "stage" (execution?) at a desired time each night. For 
  example, upload the most up-to-date succeeding 'pipeline' somewhere. Do 
not 
  block other pipelines from progressing past (no fan-in)
   
Has anybody modeled these in the Jenkinsfile, or in a delivery pipeline? 
Also, are there any good example of the fan-in and fan-out?

-- 
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/428cbe19-97c8-4b66-835c-fcce2b7a6880%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.