Re: Invoke another pipeline under another repository's branch

[Kevin Burnett]

:D

this is working for me:

build('/proj/hot-repo/master')

where proj is a bitbucket project key (bitbucket server in my case) and 
hot-repo is a repo within that project.

On Friday, September 15, 2017 at 11:30:02 AM UTC-4, Slava Dubrovskiy wrote:
>
>
> 15.09.2017 17:50, Dan Tran пишет: 
> > Ping! 
> 0% packet loss 
>
> -- 
> WBD, 
> Viacheslav Dubrovskyi 
>
>

-- 
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/24e22be1-57be-4734-a342-7c1485dc370f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins pipeline parallel execution for different nodes on both Declarative and Scripted

[Kevin Burnett]

you can use the "parallel" step in a declarative pipeline. you cannot wrap 
multiple stages inside a parallel step unless you use scripted (currently. 
this may be implemented in declarative in the future).

it is very hard to read code that is not indented. please indent your code. 
:) i think this is your pipeline, but with "steps" added inside the build 
stage and with a quote added to the end of the label 'server02' (it now 
validates clean):

pipeline {
  agent any
  stages {
stage('build') {
  steps {
agent { label 'testnode' }
echo 'build process'
  }
}
stage('Deployment') {
  steps {
parallel(
  "Deployment1": {
agent { label 'server01'}
echo 'deployment in server1'
  },
  "Deployment2": {
agent { label 'server02' }
echo 'deployment in server2'
  }
)
  }
}
  }
}


On Wednesday, August 23, 2017 at 9:40:32 PM UTC-4, jothibasu k wrote:
>
> I like to add stackoverflow questions also, in the below two questions in 
> one they are saying it doable in Declarative and another saying you need to 
> wrap it with script {} block.
>
> which one i we need to follow.
>
> https://stackoverflow.com/questions/44585619/parallel-jenkins-pipeline
>
>
> https://stackoverflow.com/questions/45294813/jenkins-declarative-pipeline-parallel-stages
>
> Thanks,
> JB
>
> On Thursday, August 24, 2017 at 6:53:07 AM UTC+5:30, jothibasu k wrote:
>>
>> I understand the basic difference between the Declarative and scripted 
>> pipeline in Jenkins 2.0.
>>
>> when I try to implement the parallel deployment on different nodes, it 
>> seems declarative is not working I guess.
>>
>> Question
>> 
>> 1. can you please confirm running the parallel task in the different node 
>> is supported or not in both pipeline model.
>> 2. if it works the syntax to do that in the declarative and scripted 
>> pipeline.
>>
>> My declarative pipeline 
>>
>> *pipeline {*
>> *agent any*
>> *stages {*
>> *stage('build') {*
>> *  agent { label 'testnode' }*
>> *  echo 'build process'*
>> *}*
>> *stage('Deployment') {*
>> *steps {*
>> *parallel (*
>> *"Deployment1": {*
>> *agent { label 'server01'}*
>> *echo 'deployment in server1'*
>> *},*
>>
>> *"Deployment2": {*
>> *agent { label 'server02 }*
>> *echo 'deployment in server2'*
>> *}*
>> *)*
>> *}*
>> *}*
>> *}*
>> *}*
>>
>>
>> the above example is not working, if i put the agent in stage level it is 
>> working but stream level it is not working, basically, i like to understand 
>> parallel execution in the different node is supported or not on both 
>> pipelines.
>>
>> Thanks in Advance,
>>
>>
>>

-- 
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/3ff93e0d-e44b-41f1-a72c-25d43c7f532d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: notifyCommit won't fire specific jobs, need help debugging

[Kevin Burnett]

so the job that doesn't fire has parameters. what about the job in the same 
instance that you said works? does it have parameters? i'm believe i've 
seen jobs with parameters not get triggered, but i'm not sure if that's 
just how it works (job with parameters never get triggered) or if there are 
some configurations where they can get triggered by changes in source 
control and some configurations where they cannot.


On Monday, June 26, 2017 at 1:51:21 PM UTC-4, David Karr wrote:
>
> For months now, I and the local Jenkins admins I work with, have been 
> struggling with a problem where my main jenkins job is not firing on a 
> "notifyCommit" firing from a BitBucket instance.  We actually were able to 
> define another job in the same Jenkins instance, pointing to the same repo, 
> that IS fired when the notifyCommit url is hit, but we still can't get the 
> normal job to fire.  We also see the log entry that shows the notifyCommit 
> call, but it just doesn't start the job.
>
> The job works fine when we run it manually, it just doesn't fire 
> automatically.  It also works fine when it's spawned from the 
> "buildWithParameters" URL, which we use to build pull request branches 
> automatically (the same job is designed to build both master and pr 
> branches).
>
> We've tried numerous variations of the value in the "Branches to build" 
> field, but it doesn't appear to make any difference.
>
> We're using v2.46.2 of Jenkins and v3.3.0 of the git plugin for Jenkins.
>
> Assuming no one here has any bright ideas about why this is happening, I 
> figure my next step is to connect to the Jenkins instance with a remote 
> debugger and step through the code.  In order to do that, I have to obtain 
> the correct code to step through, and some hints on some breakpoints to set.
>
> I figure I at least need the source for the correct release.  When I look 
> on github, I see a release for "2.46.3", but not "2.46.2".  I do see that 
> github has a "3.3.0" release for the git plugin, so I assume I'm ok there.
>
> Assuming I can get the 2.46.2 vs. 2.46.3 issue resolved, are there any 
> other plugins that I need to get the source for in order to properly debug 
> this?
>

-- 
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/af6805e9-293f-4649-88fd-b33b0081a0cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub and Bitbucket branch source UI refactoring

[Kevin Burnett]

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 
>> https://groups.google.com/d/msgid/jenkinsci-dev/c2e110d7-f929-461d-8595-273e8e543d89%40googlegroups.com
>>  
>> 

Re: Fastest way to git tag in a Jenkinsfile?

[Kevin Burnett]

it is possible to skipDefaultCheckout and then "checkout scm". this isn't 
typically necessary or desirable if you want to operate on the same repo 
where your Jenkinsfile lives, but it sounds like you might want to override 
some checkout options, which seems cool. we also do this for some jobs that 
"trash the workspace" by writing some files as root, so the default 
checkout can't work on subsequent builds. in a Jenkinsfile stage we first 
"fix the workspace" by chown'ing it to the jenkins user, which allows `scm 
checkout` to work.

On Saturday, June 17, 2017 at 1:22:48 PM UTC-4, Mark Waite wrote:
>
> Defaults are taken when values are not provided.
>
> On Sat, Jun 17, 2017 at 11:19 AM Idan Adar  
> wrote:
>
>> Another question, if I do customize "checkout", do I need to include 
>> everything like in your example, or only what I want specifically, like 
>> depth, and if nothing else is mentioned that the defaults are taken...?
>>
>> -- 
>> 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/ed87e710-1906-46b3-9486-6440b92da5ba%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/2cd44a76-c556-41a8-93f6-d40e81aca9e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub and Bitbucket branch source UI refactoring

[Kevin Burnett]

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  > 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/fd613b68-3f87-4650-a3f9-6657d8f4179a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Can environment directive be used in post?

[Kevin Burnett]

i don't believe you can use the environment instruction in post, no.

but you can use 
withEnv: 
https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/#code-withenv-code-set-environment-variables

On Wednesday, June 14, 2017 at 8:43:43 AM UTC-4, Idan Adar wrote:
>
> In a stage I can do the following: 
>
> stage ("Merge pull request") {
>  environment {
> JENKINSBOT = credentials('${JENKINSBOT_GHE_ACCESS_TOKEN}')
>  }
>  ...
>  ...
>  steps {
>   
>  }
> }
>
> Can this done also in post?
>
> post {
>  success {
>  environment { 
>  JENKINSBOT = credentials('${JENKINSBOT_GHE_ACCESS_TOKEN}')
>  }
>
>  script {
>  
>  }
>   }
> }
> 
>
> Or is there any other way to ahchieve this?
>

-- 
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/a3beb8eb-353f-41cb-ada9-dccbe889b189%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to set environment variable in multibranch pipeline?

[Kevin Burnett]

here's an example Jenkinsfile that sets an environment variable (REPO_URL) 
that applies to all stages. you can also use the withEnv step to set an 
environment variable for a certain block.

pipeline {
  agent { label 'docker' }
  environment {
REPO_URL = 'www.my.repo'
  }
  stages {
stage('build') {
  steps {
sh 'env | grep REPO_URL'
  }
}
  }
}

Jenkinsfiles apply to all branches in a repo, so that part is handled 
implicitly.

Hope this helps,
KB


On Tuesday, June 13, 2017 at 3:53:33 AM UTC-4, Mark Allison wrote:
>
> I have a Jenkins multibranch pipeline project and I want to set an 
> environment variable for all branches. Is this possible? I could only see a 
> way to do it with the environment injector plugin at the branch level. I 
> want to be able to do this at the project level because I want new feature 
> branches to automatically inherit some environment variables.
>

-- 
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/35f81b50-ac62-4f9c-8937-b8c600434a8e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Does Jenkis need the workspace in order to compare previous commits for Git repository

[Kevin Burnett]

I got super-confused here for a minute, so I thought it might be worth 
pointing out that people who are using multibranch pipelines can completely 
ignore the article presented in this thread (it says it's for 
"non-multibranch jobs") and get this bitbucket server add-on 
instead: 
https://marketplace.atlassian.com/plugins/nl.topicus.bitbucket.bitbucket-webhooks/server/overview.
 
stephen has recently submitted pull requests for this "topicus" add-on, so 
i'm pretty sure it's still a thing. :) it works in concert with the 
Bitbucket Branch Source jenkins plugin.

On Wednesday, June 7, 2017 at 11:29:09 PM UTC-4, Mark Waite wrote:
>
>
>
> On Wed, Jun 7, 2017 at 5:46 PM Stephen Connolly  > wrote:
>
>> On Wed 7 Jun 2017 at 22:48, Łukasz Zachulski > > wrote:
>>
>>> I've found Jenkins article Triggering a build using hooks in Bitbucket 
>>> server 
>>> 
>>>  
>>> and it states that
>>>
>>> You need to ensure that your workspace is not deleted after every build. 
 The Git plugin needs the workspace in order to compare previous commits to 
 check if there were changes in the repository or not.
>>>
>>>
>>>
> As far as I understand it, that statement is incorrect.  The git plugin 
> does not need the workspace to check if there were changes in the 
> repository or not.  The plugin remembers the SHA1 associated with a build.  
> If a SHA1 is detected which has not been previously built, then it is 
> assumed a new build is needed.
>
> Remote polling (the default) does not require a workspace, unless you're 
> using certain special cases, like ignoring commits based on the commit 
> author or commit message.
>
> Mark Waite
>  
>
>> What will happen if the workspace will be deleted or when build will be 
>>> simply executed on different node? Will Jenkins not be able to correctly 
>>> depict changes between previous and current builds?
>>>
>>>
> Changes from build to build are calculated using the git repository that 
> was used for the build.  That repository is assumed to have enough history 
> in it to compute the differences between the build and its predecessor.  
>
> Yes, it is possible to violate that assumption using a shallow clone value 
> that is less than the number of intervening commits between the build and 
> its predecessor.
>
> No, I haven't tested the behavior when that assumption is violated.
>
> Mark Waite
>  
>
>> How does this rule apply to *Pipeline*, especially *Multibranch* and 
>> *Bitbucket 
>>> Team* jobs and the fact that mult-ibranch jobs do it own branch 
>>> indexing? 
>>>
>>
>> Multibranch keeps its own track. You can ignore that rule for multibranch 
>>
>>>
>>>
>>> With Regards,
>>> Lukasz.
>>>
>>> -- 
>>> 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/2060c2f6-78a9-4421-a15d-aabafb3877d8%40googlegroups.com
>>>  
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> -- 
>> Sent from my phone
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-use...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-users/CA%2BnPnMwj%3DwH1-ue599HspTL8vkDzTYCfjJjM%3DBWbZF6CrK0t0A%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/07e9deec-a0ab-45ce-8ec6-a08db28cc93f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Manual step stage on BlueOcean/Jenkins2 pipeline

[Kevin Burnett]

use the input step 
, like this:

timeout(time: 5, unit: 'DAYS') {
input message: 'Approve deployment?'
}


it's helpful to wrap it in a timeout, so eventually the pipeline will stop 
(fail) if no one approves it.

On Thursday, May 11, 2017 at 10:58:26 AM UTC-4, Thiago Carvalho Davila 
wrote:
>
> Hello,
>
> I am migrating my old pipelines to pipeline as code of Jenkins2. I've been 
> strugling to make manual step stages like stage('Deploy-Production'){}. It 
> is autoexecuted if I just put it in the pipeline{}.
>
> What is the best practice here? Is there native support to manual step?
>
> Thanks,
>
> Thiago
> -
>
>
> "Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), 
> empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é 
> enviada exclusivamente a seu destinatário e pode conter informações 
> confidenciais, protegidas por sigilo profissional. Sua utilização 
> desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a 
> recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, 
> esclarecendo o equívoco."
>
> "This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a 
> government company established under Brazilian law (5.615/70) -- is 
> directed exclusively to its addressee and may contain confidential data, 
> protected under professional secrecy rules. Its unauthorized use is illegal 
> and may subject the transgressor to the law's penalties. If you're not the 
> addressee, please send it back, elucidating the failure."
>

-- 
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/ee9fa059-1854-4ee8-9d00-d51b8501916a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How do I set env variable to currentBuild property in declarative pipeline environment.

[Kevin Burnett]

This is a way to accomplish what you're trying to do:

#!groovy

// assign to this variable in the first stage (see below), and then you can 
use it throughout your pipeline
// not quite as clean as using the environment block, but it works. the 
problem seems to be that
// the environment block is "compiled" at the same time as the parameters 
block, etc, so the things
// that you want to use to set up an environment variable (params, other 
env vars) are not yet available.
def buildRevision = "UNKNOWN"

pipeline {
agent {
label "linux"
}
parameters {
string(name: "releaseName", defaultValue: "RM_TEST", description: "Ivy 
release spec")
}
tools {
jdk 'jdk1.8.0_102'
maven 'maven-3.2.5'
}
stages {
stage("dummy") {
steps {
script {
buildRevision = 
"${params.releaseName}.${env.BRANCH_NAME}.${currentBuild.startTimeInMillis}.${env.BUILD_ID}"
}  
echo "buildRevision: ${buildRevision}"
}
}
}
}


On Wednesday, May 10, 2017 at 1:42:11 PM UTC-4, JG wrote:
>
> Unfortunately not.
>
> [branch_jenkins-dummy_master-ZKZSOZRU2C4BR7MTP6RRGC4D2OPUWJONM6DQP6YFBP3UB5R3DCYQ]
>  
> Running shell script
> + env
> + sort
> BRANCH_NAME=master
> BUILD_DISPLAY_NAME=#13
> BUILD_ID=13
> BUILD_NUMBER=13
> BUILD_REVISION=null
> BUILD_TAG=jenkins-testing-multibranch-jenkins-dummy-master-13
> ...
>
> It's specifically the inclusion of ${currentBuild.*property*} in the 
> variable declaration within the *environment{}* block that leaves the 
> variable null.
>
> On Wednesday, May 10, 2017 at 12:07:31 PM UTC-5, Cuong Tran wrote:
>>
>> Does it work with this?
>>
>> withEnv(["BUILD_REVISION=${env.BUILD_REVISION}"]) {
>> sh "env | sort"
>> }
>>
>> On Wednesday, May 10, 2017 at 8:20:45 AM UTC-7, JG wrote:
>>>
>>> I'm trying to set an env variable globally in my *pipeline {} *with a 
>>> concatenation of build details like this
>>>
>>> #!groovy
>>> pipeline {
>>> agent {
>>> label "linux"
>>> }
>>>   parameters {
>>> string(name: "releaseName", defaultValue: "RM_TEST", 
>>> description: "Ivy release spec")
>>> }
>>> tools {
>>> jdk 'jdk1.8.0_102'
>>> maven 'maven-3.2.5'
>>> }
>>> environment {
>>> BUILD_REVISION = 
>>> "${params.releaseName}.${env.BRANCH_NAME}.${currentBuild.startTimeInMillis}.${env.BUILD_ID}"
>>> RELEASE_NAME = "${params.releaseName}"
>>> }
>>> stages {
>>> stage("dummy") {
>>> steps {
>>> sh "echo 
>>> \"${params.releaseName}.${env.BRANCH_NAME}.${currentBuild.startTimeInMillis}.${env.BUILD_ID}\""
>>> sh "env | sort"
>>> }
>>> }
>>> }
>>> }
>>>
>>> and it seems to be silently failing. The *echo* command prints the 
>>> value as expected, but the *env *does not include a *BUILD_REVISION* 
>>> variable (the *RELEASE_NAME* env variable is shown in the output of 
>>> *env*. I also tried setting the *BUILD_REVISION* in an *environment{}* 
>>> block 
>>> within the stage, and also tried using a string property of 
>>> *currentBuild*. Nothing seems to work.
>>>
>>> It seems to work using *withEnv* 
>>>
>>> steps {
>>> sh "echo 
>>> \"${params.releaseName}.${env.BRANCH_NAME}.${currentBuild.startTimeInMillis}.${env.BUILD_ID}\""
>>> 
>>> withEnv(["BUILD_REVISION=${params.releaseName}.${env.BRANCH_NAME}.${currentBuild.startTimeInMillis}.${env.BUILD_ID}"])
>>>  
>>> {
>>> sh "env | sort"
>>> }
>>> }
>>>
>>> But I'll need to use the variable in multiple stages so I'd prefer it to 
>>> be in a global *environment{}* block.
>>>
>>

-- 
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/1c77d1a9-0272-40be-bfc0-dbb7e3184db7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: A job to update other jobs

[Kevin Burnett]

what is up morgan, man? :)

i just tested this to update a job description (it gets an http 302 when it 
works):

  curl -u user:pass -X POST 
https://ci.example.com/job/my-hot-job/submitDescription --data-urlencode 
"description=FROZEN by [fancy_business_here]"

maybe someone else knows all about updating jobs from xml files.

good luck,
kb

On Monday, May 8, 2017 at 2:06:33 PM UTC-4, Morgan Blackthorne wrote:
>
> We're using Chef automation around configuring our Jenkins jobs. Basically 
> chef clones a git repo with the job XML files, and then tells Jenkins to 
> use them.
>
> What we want to have is:
>
>1. One job to edit other jobs description to say "FROZEN by  
>at " or to remove the FROZEN line (basically a toggle)
>2. Chef will then be updated to look at the job XML currently on the 
>Jenkins server
>   1. If the description includes FROZEN, skip that job and leave it 
>   alone
>   2. If the description does not include FROZEN, update the job from 
>   the XML file
>
> I'm not really up to speed on Groovy, so what's the simplest way to 
> approach this? (I already know how to do the XML check for step 2, we can 
> just look at the XML over HTTP.)
>

-- 
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/fa729891-a5fe-44c8-9f6c-cafb050a5985%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline with CVS

[Kevin Burnett]

Use the pipeline syntax generator that you can find in the left nav of your 
jenkins UI in any pipeline job. It's sweet. I will not take any cheap shots 
at CVS while I'm here.





On Tuesday, May 2, 2017 at 4:54:42 AM UTC-4, xto...@gmail.com wrote:
>
> Hi,
>
>
> I try to write pipeline to check out code from CVS. While there are many 
> example with git, I cannot find any example with CVS. I would very 
> appreciate if anyone can post some groovy examples here.
>
>
> 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/4c4d5f60-6a61-42bb-841a-064d9a29d7cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multi branch source - PR versus branch build

[Kevin Burnett]

i'm actually totally with you on this.

i've been wanting to only build branches (and never build PRs) for a while 
now. in fact, we've gone so far as to "kill" PR builds manually in our 
shared library in order to not chew up resources needlessly:

if (env.BRANCH_NAME && env.BRANCH_NAME.contains('PR-')) {
  error("IntentionallyFailingPullRequestBuild")
}

our workaround is annoying since our pull requests obviously always show up 
as broken in bitbucket server. :|

i think https://issues.jenkins-ci.org/browse/JENKINS-43426 is related, and 
lots of new use-cases will be supported when this new UI is eventually 
rolled out (i hope our "ignore PRs completely" use case is supported, but 
i'm not 100% sure what's in scope).

On Monday, May 1, 2017 at 2:17:23 PM UTC-4, Dan Tran wrote:
>
>
> So I misunderstood the mechanism of PR build where the target branch is 
> not merged into the destination branch before build
>
> what is the benefit of auto build both merge and pr for every new commit? 
>  I can understand the benefit before issuing the PR, but from my experience 
> ppl usually issue PR very early to solicit feed back and there for we have 
> double builds
>
> Thanks
>
> -Dan
>
> On Monday, May 1, 2017 at 10:44:33 AM UTC-7, Kevin Burnett wrote:
>>
>> dan,
>>
>> i understand that you're using the bitbucket branch source plugin, you 
>> introduce a syntax error into the mainline branch (let's call it master), 
>> and you submit a pull request for a different branch (let's call it 
>> feature/new-hotness) that wasn't based off this bad master branch. your 
>> master build fails and your pull request build succeeds.
>>
>> that is what i'd expect, because it doesn't automatically merge the 
>> feature branch into master or master into the feature branch. where have i 
>> misunderstood?
>>
>>
>> On Sunday, April 30, 2017 at 5:26:44 PM UTC-4, Dan Tran wrote:
>>>
>>> Hi
>>>
>>> I am experimenting BitBucket multi branch source plugin I think PR build 
>>> is just same as branch build.
>>>
>>> Basically, i force a syntax failure  the main source, and create a pull 
>>> request from another branch.  
>>> I am expecting the PR build also fails as in main. But  it is  not.
>>>
>>> Am I missing something?
>>>
>>> Thanks
>>>
>>> 0Dan
>>>
>>

-- 
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/728454ea-fca1-40d9-90b7-1a04e7415fe8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multi branch source - PR versus branch build

[Kevin Burnett]

dan,

i understand that you're using the bitbucket branch source plugin, you 
introduce a syntax error into the mainline branch (let's call it master), 
and you submit a pull request for a different branch (let's call it 
feature/new-hotness) that wasn't based off this bad master branch. your 
master build fails and your pull request build succeeds.

that is what i'd expect, because it doesn't automatically merge the feature 
branch into master or master into the feature branch. where have i 
misunderstood?


On Sunday, April 30, 2017 at 5:26:44 PM UTC-4, Dan Tran wrote:
>
> Hi
>
> I am experimenting BitBucket multi branch source plugin I think PR build 
> is just same as branch build.
>
> Basically, i force a syntax failure  the main source, and create a pull 
> request from another branch.  
> I am expecting the PR build also fails as in main. But  it is  not.
>
> Am I missing something?
>
> Thanks
>
> 0Dan
>

-- 
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/6a1523be-25a0-4519-9887-28fd29363cde%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins Job gets triggered by Bitbucket Push event but not by Pull request event.

[Kevin Burnett]

if you're using bitbucket server and the recommended bitbucket server 
add-on, maybe you're running into this documented regression: 
https://github.com/topicusfinan/bitbucket-webhooks-plugin/issues/31.

if so, as discussed in this github issue, a workaround is to downgrade this 
add-on to version 1.2.0.

On Thursday, April 6, 2017 at 1:07:28 AM UTC-4, joe.c...@gmail.com wrote:
>
> Hi guys,
>
> Iam not able to trigger a jenkins job , whenever I make a pull request in 
> bitbucket but I am able to trigger Jenkins job whenever there is commit in 
> bitbucket branch.
> I tried  "BitBucket pull request builder" plugin,  to achieve this but not 
> able to succeed.
>
> Any help will 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/3fe9ee64-b451-4fc9-89f7-c5d9bc435326%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Moving jobs from Bamboo to Jenkins

[Kevin Burnett]

type faster?

:)

...

:(

i don't think you're going to find much help in terms of an existing script 
to perform the whole 
migration. 
http://stackoverflow.com/questions/38910932/bamboo-to-jenkins-migration.

what i have found is that declarative pipelines facilitate migration quite 
well, since similar projects can use similar Jenkinsfiles (and you can put 
shared Jenkinsfile functionality in libraries as well). then, when you've 
added a bunch of Jenkinsfiles, you can mass import them into jenkins as 
long as you're using github or bitbucket for source control. 
https://jenkins.io/blog/2017/02/03/declarative-pipeline-ga/ post is maybe a 
reasonable starting point for getting into declarative pipelines.

On Friday, March 31, 2017 at 7:03:22 AM UTC-4, DevOps_PS wrote:
>
> *My company has decided to move from Bamboo to Jenkins. We have several 
> jobs already in Bamboo. Can someone help me with a solution on moving all 
> jobs from Bamboo to Jenkins swiftly ?*
>

-- 
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/77dcff40-23d9-4d92-ba85-ceb327a53a65%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline script for Build Trigger

[Kevin Burnett]

Sebastian, here's a snippet of a declarative Jenkinsfile pipeline showing a 
time-based (cron) trigger:

pipeline {
  triggers {
// every 30 minutes during 9 hours each night
cron('H/30 20,21,22,23,0,1,2,3,4 * * *')
  }
  agent { label 'docker' }
  environment {
GIT_COMMITTER_NAME = 'jenkins'
GIT_COMMITTER_EMAIL = 'jenk...@jenkins.io'
  }
  stages {
stage('setup') {
.

On Friday, January 27, 2017 at 4:58:21 AM UTC-5, Sebastian Gurlt wrote:
>
> Hey,
>
> I want to do the same with automatic time based builds, any hint how I 
> could implement this ? :)
>
> Greetings
> Sebastian
>
> Am Freitag, 12. August 2016 20:55:03 UTC+2 schrieb John Engelman:
>>
>> I was able to get the branch to enable the trigger by adding the 
>> following to my Jenkinsfile:
>>
>> properties([
>> pipelineTriggers([
>>   [$class: "GitHubPushTrigger"]
>> ])
>>   ])
>>
>> I then manually executed a Branch Index on the parent job and the 
>> resulting PR builds had the trigger on push setting enabled.
>>
>> On Thursday, August 11, 2016 at 9:01:19 AM UTC-5, Michal Medvecky wrote:
>>>
>>> I see that the related issue was resolved, but I still don't know how to 
>>> add "Build when a change is pushed to GitHub" support to my Jenkinsfile.
>>>
>>> Can anyone help me please?
>>>
>>> Michal
>>>
>>

-- 
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/4c299cfe-887a-4729-9a34-235d6c5c971f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.