Re: Meet jenkins.io

Great job, very well done! On Thursday, March 24, 2016 at 8:05:45 AM UTC-7, Alyssa Tong wrote: > > Well done! Congrats to all involved! jenkins.io looks AWESOME!! 珞珞 > > On Thu, Mar 24, 2016 at 6:30 AM, Tom Fennelly > wrote: > >> Really nice. Thanks guys!! >> >> On

Re: Jenkins 2.0 alpha release available

I cannot find documentation for the Jenkinsfile DSL format. It should be linked on the announcement page at (https://jenkins-ci.org/2.0/ and https://jenkins.io/2.0/) so that all the people who come will get a chance to look at it. On Monday, February 29, 2016 at 3:39:22 PM UTC-8, R Tyler Croy

Re: One CI job for 4 branches

If you have created a post-update hook on the remote repository to notify Jenkins when a push occurs, you might consider configuration as: Branch to build: ** Checkout to specific local branch: ** (requires Git plugin 2.4.4) Build Triggers: Poll SCM but leave the schedule blank. The job will

Git Plugin GIT_LOCAL_BRANCH environment variable implemented

There have been a couple of requests for an environment variable that publishes the local branch name. The current version of the Git Plugin has a new feature that targets Maven release builds, but can be leveraged by other builds. The maven release plugin pushes a commit to git using the

Re: One CI job for 4 branches

I think you'll like the results better if you have a job dedicated to each branch. There are plugins that will allow you to automatically create a separate job for each branch that matches a pattern (multi-branch plugin, I think), or that will allow you to create a separate job for each branch

Re: One CI job for 4 branches

you can use some regex in the branch name or use the below plugin https://wiki.jenkins-ci.org/display/JENKINS/Multi-Branch+Project+Plugin first approach might help to use pushing rather than polling, second approach, as far as I know, it's polling based. It does also depend on whether you

Re: email-ext plugin + credentials plugin?

getEnvironment(listener) worked!! Regarding buildVariables, this code: logger.println("Build Variables Start: ") build.each { logger.println(it) } logger.println("Build Variables End") Produced: Build Variables Start: deploy-sidecar-gold-gmatz-test #20 Build Variables End Thanks

Re: email-ext plugin + credentials plugin?

Can you print out what is in build.buildVariables? The other thing to try would be build.getEnvironment(listener)['JIRA_USERNAME'] On Fri, Mar 25, 2016 at 8:39 AM Guy Matz wrote: > Hmm . . . no, the build.buildVariables['JIRA_USERNAME'] showed up as > null . . . any other

Re: email-ext plugin + credentials plugin?

Hmm . . . no, the build.buildVariables['JIRA_USERNAME'] showed up as null . . . any other thoughts? Thanks again, Guy P.S. - Thanks for the pointer to the Jira plugin. That might work for another problem I have! On Fri, Mar 25, 2016 at 10:24 AM, Slide wrote: > Can

Re: Jenkins and Github authentication using SSH keys

The Jenkins ssh-agent plugin doesn't work on Windows. I'm running Jenkins as a service under a user with limited rights. The used ssh settings can be found in the file /C/Users//.ssh/config. But this should not be necessary as you define this also in the Jenkins -> Credentials. But there is a

Re: email-ext plugin + credentials plugin?

Can you try using build.buildVariables['JIRA_USERNAME']? Also, there are a couple of JIRA plugins that might do what you want. https://wiki.jenkins-ci.org/display/JENKINS/JIRA+Plugin https://wiki.jenkins-ci.org/display/JENKINS/Jira+Issue+Updater+Plugin On Fri, Mar 25, 2016 at 6:37 AM Guy Matz

Re: email-ext plugin + credentials plugin?

Thanks, yes the credentials are supposed to be in the environment! My presend script is creating a Jira ticket via REST API, so I have my jira user's username & password in credentials, and am defining them as JIRA_USERNAME & JIRA_PASSWORD, respectively. I am then referencing them in the

Re: Jenkins Maven repository server supports multiple upstream projects?

You can't. What you can do is if your build is A->B->C, you can specify C's upstream repository as 'repositoryChain', so it will include both A and B (where B takes priority over A). You could can extend the rules - possibly even with different resolution rules, but it's not something anyone has