Help with github plugin - SSL issue with custom CA

[Robert Hafner]

I have a fresh install of Jenkins that will not connect to my Github 
Enterprise instance. We are using an in house CA with our custom TLD (so 
https://github.acme) and aren't having any other SSL troubles outside of 
this.

Does anyone know if the CA certs need to be installed in a specific way for 
Jenkins to be able to use them?

Rob

-- 
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/59dd25be-f98f-443d-b8cc-0c167046c55f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How do I use the Jenkins CLI commands for Credentials Plugin?

[Brandon R]

I've been looking into this as well and made a little progress by digging 
around https://github.com/jenkinsci/credentials-plugin

For store, I used "system::system::jenkins" like in their tests.  For 
domain I tried variations on the word "global" but none worked.  I then 
tried underscore '_' as a wild guess and that worked.  I tried that because 
it's in the url when you hover on (global) on the credentials page.

Anyway, I haven't tried creating creds yet, but I can at least get them 
like:

java -jar /usr/share/jenkins/jenkins-cli.jar -s http://localhost:8080 -i 
~jenkins/.ssh/id_rsa list-credentials system::system::jenkins

and

java -jar /usr/share/jenkins/jenkins-cli.jar -s http://localhost:8080 -i 
~jenkins/.ssh/id_rsa get-credentials-as-xml system::system::jenkins _ 
somecredname

(note that I require auth hence the -i. This might not be relevant in your 
case)

Hope this helps some.

On Saturday, August 6, 2016 at 12:32:22 AM UTC-7, Vishwanath V wrote:
>
> Hi all,
>
> I need to *automatedly* load sets of credentials to a Jenkins instance, 
> so that my jobs can pick up these credentials. 
>
> For this purpose I am using the Jenkins CLI, specifically the set of 
> commands provided by the Credentials Provider plugin:
>
>   create-credentials-by-xml
> Create Credential by XML
>   create-credentials-domain-by-xml
> Create Credentials Domain by XML
>   get-credentials-as-xml
> Get a Credentials as XML (secrets redacted)
>   get-credentials-domain-as-xml
> Get a Credentials Domain as XML
>   list-credentials
> Lists the Credentials in a specific Store
>   list-credentials-context-resolvers
> List Credentials Context Resolvers
>   list-credentials-providers
> List Credentials Providers
>update-credentials-by-xml
> Update Credentials by XML
>   update-credentials-domain-by-xml
> Update Credentials Domain by XML
>
> I am trying to understand how to use them, but there is literally no 
> documentation on this beyond the actual code (which I unfortunately am 
> unable to understand). 
>
> *Question 1. What is the "Store ID"?* 
>
> Based on the error messages, I understand it is 
> list-credentials [Store ID]
>
> I am unable to understand what the Store ID is. Another error message says 
> it should be in the format Provider::Resolver::ContextPath.
> But where would I get this information from?
>
> *Question 2: How do I load an XML for "create-credentials-by-xml"?*
>
> When I use the create-credentials-by-xml, I assume I need to provide an 
> XML file. How do I provide this ? i.e would it be as follows
> create-credentials-by-xml [Store ID] [Path to XML]
> ??
>
>

-- 
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/a3137f6b-9753-455d-871b-6e564bf9452f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

LDAP groups and Role Based Authorization no playing nice.

[Michael Lasevich]

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

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

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

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

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

Few thoughts and observations: 

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

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

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

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

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


Versions -- Running this on:

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

Any thoughts or suggestions would be appreciated

Thanks,

-Michael



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

Pipeline: Can I use html in currentBuild.description?

[Greg Smith]

Hi,

Is there some simple way to allow html in currentBuild.description?  

Seems like when I write any html tags in that string, they are all 
automatically escaped.  I can see where it would be important to do this by 
default for security purposes -- but as we have control over our github 
instance, I would like to be able to allow it.

I want to create some basic links in the description to the deep artifacts 
that are being archived on the build.

Cheers,
Greg

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

Re: Git ChangeLog, how to change base branch it computes from?

[Eric Crahen]

Thanks, I'll try to find that setting and figure out a way to set that
programatically. My end goal is that a large number of people just install
the plugin and the right thing happens w/o manually configuring lots of
jobs correctly, so that why I wanted to do it in code. Thanks for the
pointer.

On Mon, Aug 15, 2016 at 12:58 PM, Mark Waite 
wrote:

> The git plugin has an "Additional Behaviour" which tells the plugin to
> calculate changes from a base branch, rather than calculating the changes
> from the preceding build.  Could you use that instead of writing code?
>
> Mark Waite
>
> On Mon, Aug 15, 2016 at 11:11 AM Eric Crahen 
> wrote:
>
>> Hey,
>>
>>   To support a PR-building workflow, I have a plugin which sets the
>> branch used by the Jenkins workspace, to something I configure (which is
>> the pr-branch).
>>   This happens by using the GitSCM API, a very abbreviated version of
>> what happens is this:
>>
>>GitTool tool = GitTool.getDefaultInstallation();
>>GitClient git = Git.with(listener, env).in(workspaceDir).using(
>> tool.getGitExe()).getClient();
>>git.fetch("origin", new RefSpec(refspec));
>>git.checkout(localBranch);
>>
>>
>>What I would like to do is make the changelog that appears on the
>> build page understand that the base branch used is not master (or whatever
>> the default branch is that the job was configured to use). Currently, I
>> notice the changelog is unaware the branch built from changed, and so it
>> shows the wrong commits.
>>
>>I have tried to change the BuildData associated with the job, and that
>> part at least makes the GitData link that shows on the build page name and
>> link to the correct (in this case the PR branch) branch. This doesn't seem
>> to be what ChangeLog is looking at though. I took a quick look and the
>> changelog logic is kind of complex, so if anyone knows how this works
>> that'd be super useful - this must be a thing we can do one way or another.
>> 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/c5041a95-874b-4bed-9130-
>> 88305f2acd36%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/jenkinsci-users/09qwlBeOQds/unsubscribe.
> To unsubscribe from this group and all its topics, 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/CAO49JtFCb-vJk7s4Sv6Giw84-isubuTNU3En9J5XZZMtf5TGNQ%
> 40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
- Eric

-- 
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/CAPyj2qGBW1w-e2BNq7Ew-ru%2B4hK1BA8ZuGZdfh4dOZms6rPnfg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Not able to trigger Github Organization folder job automatically

[Patrick Wolf]

Do you know if the Push Event webhook is received by Jenkins when you
create the Jenkinsfile?

"Does the plugin expect the repo to have a Jenkinsfile at the time of
creation itself?"

Just the opposite. The plugin expects the repo to be empty at the time of
creation unless the repo is created by a fork. That is why the first Push
Event is so important.



On Mon, Aug 15, 2016 at 1:03 PM, Harsha Adiga 
wrote:

> Hi Patrick,
>
> Thanks for the quick reply. Yes I am creating an empty repository without
> Jenkinsfile at first and then adding the Jenkins file as a new file commit.
> I was expecting my job to get triggered at this point when I add the
> Jenkinsfile. But it is not doing that. Am I missing something here? Does
> the plugin expect the repo to have a Jenkinsfile at the time of creation
> itself?
>
> Regards,
> Harsha
>
> On Monday, 15 August 2016 15:54:07 UTC-4, Patrick Wolf wrote:
>>
>> How are you creating the Jenkinsfile?  When a new repository is created
>> the repository trigger will be sent but the Github Organization Folder
>> plugin won't do anything at that point because it assumes the repository is
>> empty. If the repository is created from a fork and a Jenkinsfile is
>> already there then Jenkins should create a job for that repository right
>> away.
>>
>> You can see that code here:
>>
>> https://github.com/jenkinsci/github-organization-folder-plug
>> in/blob/master/src/main/java/org/jenkinsci/plugins/orgfolde
>> r/github/RepositoryGHEventSubscriber.java
>>
>> The first push to the new repository that contains a Jenkinsfile should
>> trigger Jenkins to create the job at that point based on the Push webhook
>> sent from Github.  Is that not working correctly?
>>
>> On Mon, Aug 15, 2016 at 12:47 PM, Harsha Adiga 
>> wrote:
>>
>>> I am doing a POC using GitHub Organization Folder plugin. I have created
>>> a job selecting Git Hub Organization as the type. I have configured it to
>>> scan my org using the personal access token that I have generated in my
>>> Github account. I am using my Enterprise Git hub. I have also created a
>>> webhook at the org level as below:
>>>
>>> *http:///github-webhook/*  (I have selected content type
>>> as  "application/x-www-form-urlencoded" and selected "Send me
>>> everything" option)
>>>
>>> I am able to scan the organization and create folders and jobs for all
>>> my repos.
>>>
>>> But I am not able to trigger my Jenkins job automatically when a new
>>> repo is created in my GitHub organization. I see that the webhook is
>>> getting fired on new repo creation. I also see the event logged in Jenkins
>>> logs. But the job is not getting triggered. I need to manually run "Re-scan
>>> organization" to get jobs created for the new repo.  But once the jobs are
>>> created any future commits to the repo or even branch creation is able to
>>> trigger the jenkins build job automatically. Only the new repo creation is
>>> not working. I am using Jenkins v 2.7.2 and Git Hub Org folder plugin v
>>> 1.4. Can someone please help me?
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-use...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/ms
>>> gid/jenkinsci-users/2edb9a66-be61-4bea-85fb-77e3ab3eeb7b%
>>> 40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>>
>> Patrick Wolf
>> Product Director - Jenkins
>> CloudBees
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from 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/264a62fc-f425-4769-ac5e-09a6448b0b25%40googlegroups.
> com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrick Wolf
Product Director - Jenkins
CloudBees

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from 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/CAGDV0P9EYo2cVQo_eE9-BQ0t%2BVScs4CsETFcqUH9nbwPDmwaJw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Not able to trigger Github Organization folder job automatically

[Harsha Adiga]

Hi Patrick,

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

Regards,
Harsha

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

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from 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/264a62fc-f425-4769-ac5e-09a6448b0b25%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Git ChangeLog, how to change base branch it computes from?

[Mark Waite]

The git plugin has an "Additional Behaviour" which tells the plugin to
calculate changes from a base branch, rather than calculating the changes
from the preceding build.  Could you use that instead of writing code?

Mark Waite

On Mon, Aug 15, 2016 at 11:11 AM Eric Crahen  wrote:

> Hey,
>
>   To support a PR-building workflow, I have a plugin which sets the branch
> used by the Jenkins workspace, to something I configure (which is the
> pr-branch).
>   This happens by using the GitSCM API, a very abbreviated version of what
> happens is this:
>
>GitTool tool = GitTool.getDefaultInstallation();
>GitClient git = Git.with(listener,
> env).in(workspaceDir).using(tool.getGitExe()).getClient();
>git.fetch("origin", new RefSpec(refspec));
>git.checkout(localBranch);
>
>
>What I would like to do is make the changelog that appears on the build
> page understand that the base branch used is not master (or whatever the
> default branch is that the job was configured to use). Currently, I notice
> the changelog is unaware the branch built from changed, and so it shows the
> wrong commits.
>
>I have tried to change the BuildData associated with the job, and that
> part at least makes the GitData link that shows on the build page name and
> link to the correct (in this case the PR branch) branch. This doesn't seem
> to be what ChangeLog is looking at though. I took a quick look and the
> changelog logic is kind of complex, so if anyone knows how this works
> that'd be super useful - this must be a thing we can do one way or another.
> 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/c5041a95-874b-4bed-9130-88305f2acd36%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/CAO49JtFCb-vJk7s4Sv6Giw84-isubuTNU3En9J5XZZMtf5TGNQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Not able to trigger Github Organization folder job automatically

[Patrick Wolf]

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

You can see that code here:

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

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

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

> I am doing a POC using GitHub Organization Folder plugin. I have created a
> job selecting Git Hub Organization as the type. I have configured it to
> scan my org using the personal access token that I have generated in my
> Github account. I am using my Enterprise Git hub. I have also created a
> webhook at the org level as below:
>
> *http:///github-webhook/*  (I have selected content type as
>  "application/x-www-form-urlencoded" and selected "Send me everything"
> option)
>
> I am able to scan the organization and create folders and jobs for all my
> repos.
>
> But I am not able to trigger my Jenkins job automatically when a new repo
> is created in my GitHub organization. I see that the webhook is getting
> fired on new repo creation. I also see the event logged in Jenkins logs.
> But the job is not getting triggered. I need to manually run "Re-scan
> organization" to get jobs created for the new repo.  But once the jobs are
> created any future commits to the repo or even branch creation is able to
> trigger the jenkins build job automatically. Only the new repo creation is
> not working. I am using Jenkins v 2.7.2 and Git Hub Org folder plugin v
> 1.4. Can someone please help me?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-users/2edb9a66-be61-4bea-85fb-77e3ab3eeb7b%40googlegroups.
> com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrick Wolf
Product Director - Jenkins
CloudBees

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from 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/CAGDV0P-e3T7aTtNqWth2SORUQyhRr3mohT3vpxG4-cr_Vh%3DRrA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Not able to trigger Github Organization folder job automatically

[Harsha Adiga]

I am doing a POC using GitHub Organization Folder plugin. I have created a 
job selecting Git Hub Organization as the type. I have configured it to 
scan my org using the personal access token that I have generated in my 
Github account. I am using my Enterprise Git hub. I have also created a 
webhook at the org level as below:

*http:///github-webhook/*  (I have selected content type as 
 "application/x-www-form-urlencoded" and selected "Send me everything" 
option)

I am able to scan the organization and create folders and jobs for all my 
repos. 

But I am not able to trigger my Jenkins job automatically when a new repo 
is created in my GitHub organization. I see that the webhook is getting 
fired on new repo creation. I also see the event logged in Jenkins logs. 
But the job is not getting triggered. I need to manually run "Re-scan 
organization" to get jobs created for the new repo.  But once the jobs are 
created any future commits to the repo or even branch creation is able to 
trigger the jenkins build job automatically. Only the new repo creation is 
not working. I am using Jenkins v 2.7.2 and Git Hub Org folder plugin v 
1.4. Can someone please help me?


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

Re: Pipelines, github fork models and the Jenkinfile

[Jesse Glick]

On Sunday, August 14, 2016 at 1:28:50 AM UTC-4, Arvind Jayaprakash wrote:
>
> A world wherein the following can happen is god enough
>>
>
>- "jenkins team" is able to offer pipelines with restricted set of 
>configuration points
>- "development team" exercises these configs through a file in the 
>source code (seed.properties) but doesn't get to tinker with the pipeline 
>script
>- a way for the "jenkins team" to ensure that the latest pipeline 
>libraries are being used
>
> There is no open-source feature for this that I know of, though you could 
probably cobble something together. CloudBees offers a proprietary version:

https://www.cloudbees.com/blog/new-angle-pipeline-code

-- 
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/250fade3-706e-4498-9e45-b314ef770306%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Git ChangeLog, how to change base branch it computes from?

[Eric Crahen]

Hey,

  To support a PR-building workflow, I have a plugin which sets the branch 
used by the Jenkins workspace, to something I configure (which is the 
pr-branch). 
  This happens by using the GitSCM API, a very abbreviated version of what 
happens is this:

   GitTool tool = GitTool.getDefaultInstallation();
   GitClient git = Git.with(listener, 
env).in(workspaceDir).using(tool.getGitExe()).getClient();
   git.fetch("origin", new RefSpec(refspec));
   git.checkout(localBranch);  


   What I would like to do is make the changelog that appears on the build 
page understand that the base branch used is not master (or whatever the 
default branch is that the job was configured to use). Currently, I notice 
the changelog is unaware the branch built from changed, and so it shows the 
wrong commits.

   I have tried to change the BuildData associated with the job, and that 
part at least makes the GitData link that shows on the build page name and 
link to the correct (in this case the PR branch) branch. This doesn't seem 
to be what ChangeLog is looking at though. I took a quick look and the 
changelog logic is kind of complex, so if anyone knows how this works 
that'd be super useful - this must be a thing we can do one way or another. 
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/c5041a95-874b-4bed-9130-88305f2acd36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Passing the artifacts of the current pipeline into a downstream job

[Greg Smith]

Never mind -- I seem to have found the solution to this:

1)  Set the freestyle project to use instead select the artifacts of "The 
upstream job that triggered this job" 
2)  Set the wait on the build value to false, so that the pipeline build 
does not wait on running the other freestyle build

These together seem to have fixed the problem (though I didn't try them 
individually, maybe I could have gotten away with one or the other...)

Greg

On Monday, August 15, 2016 at 12:11:00 PM UTC-4, Greg Smith wrote:
>
>
> Hi,
>
> I am trying to build a workflow where one a pipeline job passes its 
> artifacts into another (old style) job in Jenkins that we already have 
> defined.
>
> The freestyle job takes 2 parameters:  The project name, and the build 
> number.  It then copies the artifacts from "Project" / "Build Number" into 
> its workspace, and does stuff with it.
>
> In my pipeline job, I am first saving my artifacts, and then I am calling 
> my downstream job like this:
>
> build job: 'Publish MyJob', parameters: [string(name: 'PROJECT_NAME', 
> value: "${env.JOB_NAME}"), string(name: 'PROJECT_BUILD_NUMBER', value: 
> "${env.BUILD_NUMBER}")], wait: false
>
> The problem is that it seems that the downstream, freestyle project can't 
> access the artifacts of the currently, still running pipeline job.  In my 
> freestyle job, I'm getting this output:
>
> ERROR: Unable to find a build for artifact copy from: 
> Organization/MyJob/master
>
>
> What is the correct way for a pipeline job to start a downstream job with 
> the artifacts it just built?
>
> Thanks,
> Greg
>
>

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

How to best define .m2 local maven repo path in multi-branch projects/Jenkinsfile?

[ST]

Hi!

I am migrating our build pipeline from a set of maven-type jobs to a
multi-branch project defined in a Jenkinsfile, and I am wondering how
people solve the .m2 problem ? I cannot see any way to configure every
job/branch to have its own private .m2 repo through a comfortable boolean
config option, did I miss something?

Otherwise I guess the solution is to set the .m2 path via
-Dmaven.repo.local. But how to best define this path so it is different for
every job/branch? Put it under /tmp/? Any other more
elegant options?

Best regards,
 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/CABwQARufwXt0gm7zmFfB-54pAipn1kNtbT5hpPVUgY%2B2Cza8tg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Passing the artifacts of the current pipeline into a downstream job

[Greg Smith]

Hi,

I am trying to build a workflow where one a pipeline job passes its 
artifacts into another (old style) job in Jenkins that we already have 
defined.

The freestyle job takes 2 parameters:  The project name, and the build 
number.  It then copies the artifacts from "Project" / "Build Number" into 
its workspace, and does stuff with it.

In my pipeline job, I am first saving my artifacts, and then I am calling 
my downstream job like this:

build job: 'Publish MyJob', parameters: [string(name: 'PROJECT_NAME', 
value: "${env.JOB_NAME}"), string(name: 'PROJECT_BUILD_NUMBER', value: 
"${env.BUILD_NUMBER}")], wait: false

The problem is that it seems that the downstream, freestyle project can't 
access the artifacts of the currently, still running pipeline job.  In my 
freestyle job, I'm getting this output:

ERROR: Unable to find a build for artifact copy from: Organization/MyJob/master


What is the correct way for a pipeline job to start a downstream job with 
the artifacts it just built?

Thanks,
Greg

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

Re: New Pipeline Maven plugin

[Cyrille Le Clerc]

Hello ok999,

> Assuming maven was already installed in the node & have the files 
configured (settings.xml, local repo etc) from the TOOLS setting of 
jenkins.. 
> Will this plugin override those settings? 

Yes, "withMaven(){}" will override all the settings that you define with 
the wrapper. We do it creating a shell wrapper of the "mvn" / "mvn.bat" 
command.

If you specify a "jdk" with "withMaven(jdk: 'my-jdk'){}" then we will 
override "JAVA_HOME" and add this new "$JAVA_HOME/bin" to the "PATH"
If you specify a "mavenInstallation" then we will override "MAVEN_HOME", 
"M2_HOME", we will ensure that the "mvn" wrapper that we create with 
"withMaven()" points to this desired MAven installation.
If you specify a "mavenSettingsConfig", we will pass it as a "--settings" 
when invoking the "mvn" executable
If you specify a "mavenLocalRepo", we will pass the system property 
"-Dmaven.repo.local="

You can see all these details enabling a FINE logger on 
"org.jenkinsci.plugins.pipeline.maven.WithMavenStepExecution"

I have created a gist that details these 
https://gist.github.com/cyrille-leclerc/a9db59d346c937c8bdde2113df7653d5

> And is there any plan for the maven release plugin in pipeline? At the 
moment i am using the 'bat' to call the goals for release:prepare and 
release:perform   

We focus for the moment on covering as many Maven use cases as possible 
with the "withMaven(...){}" wrapper. We hope that a Maven execution step 
will appear soon.

I feel that a Maven release is already pretty straight forward with the 
"withMaven(...){}" wrapper. The following code actually works:

node {
> withMaven(mavenSettingsConfig: 'maven-settings-for-game-of-life', 
> mavenInstallation: 'M3', jdk: 'Oracle JDK 8') {
> git 'https://github.com/cyrille-leclerc/my-spring-boot-app.git'
> sh "mvn release:prepare release:perform"
> }
> }




On Thursday, August 11, 2016 at 10:06:31 PM UTC+2, ok999 wrote:
>
> Assuming maven was already installed in the node & have the files 
> configured (settings.xml, local repo etc) from the TOOLS setting of 
> jenkins.. 
> Will this plugin override those settings? 
>
>  withMaven(mavenInstallation: 'M3', mavenLocalRepo: '.repository', 
> mavenSettingsConfig: 'maven-settings-for-gameoflife') {
> // Run the maven buildsh "mvn clean install"
> }
>
>
>
> And is there any plan for the maven release plugin in pipeline? At the moment 
> i am using the 'bat' to call the goals for release:prepare and 
> release:perform   
>
>
>
> Thanks
>
>
>
>
>
>
> On Thu, Aug 11, 2016 at 11:33 AM, Álvaro Lobato  > wrote:
>
>>
>> Hello everyone,
>>
>> I'd like to introduce you to the new Pipeline Maven 
>>  plugin . 
>> The intention of this plugin is to help using maven from pipeline, setting 
>> up a maven environment by using a withMaven step. This environment can 
>> later be called with sh or bat step.
>>
>> The supported configuration parameters are:
>>
>>- Maven Installation
>>- JDK
>>- Maven Settings Config (Config File Provider Plugin)
>>- Maven Settings File Path 
>>- Maven JVM Opts 
>>- Maven Local Repository 
>>
>> The step can be used used directly on a node or in a docker.inside.
>>
>> Currently it is in an early stage of development and I've just released 
>> the first beta version, already available in the update center.
>>
>> This is the start point for a more feature rich integration between 
>> pipeline and maven.
>>
>> You can find more information on the wiki page: Pipeline Maven plugin 
>>  
>>
>> Thanks
>> Alvaro.
>>
>> -- 
>> 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/81089a41-3bdf-47a4-bdad-b4424d27341b%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Regards
> nirish okram
>

-- 
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/e5d55996-1800-4696-8e7b-f4f14f43d4f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pipeline][groovy postbuild] Groovy manager access

[jerome]

If anybody ever wonder it's the following:
*if(currentBuild.result == '**SUCCESS')*
*{*
   manager.addShortText("${APPLY_TAG}")
}

Not sure the isBetterOrEqualTo() is still available somewhere.

On Wednesday, July 13, 2016 at 11:44:03 AM UTC-4, jer...@bodycad.com wrote:
>
> Hi,
>
> I try to translate my Groovy PostBuild to pipeline:
>
> *if(manager.build.result.isBetterOrEqualTo(hudson.model.Result.SUCCESS)) *
> *{*
> *
> manager.addShortText("${manager.build.buildVariables.get('APPLY_TAG')}")*
> *}*
>
> I was thinking about using this:
>
> *if(manager.build.result.isBetterOrEqualTo(hudson.model.Result.SUCCESS)) *
> *{*
> * manager.addShortText("${APPLY_TAG}");*
> *}*
>
> But it doesn't work. Anyone have any idea?
>
> Jerome
>

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

Named Child Folder Health Metric

[Rob Oxspring]

Hi all,

I've been playing around with multibranch projects lately and noticed the 
only folder metric available by default is "Worst Child Health Metric"

For us the only branch that we really care about is the master branch so I 
wondered if anybody had a folder metric that would take that named branch's 
metrics and promote those to be the folder's? That way the parent folder 
could have a good overview of the master branches for each job.

Any pointers (including how to write one myself!) much appreciated.

Thanks,

Rob

-- 
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/c19561fb-9e30-4735-a30a-e0ae8a13b61a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: New Pipeline Maven plugin

[Cyrille Le Clerc]

Hello Will,

Fingerprint and reports rendering are things we would like to see in 
forthcoming releases of this plugin. We hope that the community will help 
on this kind of feature.

For the moment, we unfortunately have to use the following verbose steps:

step([$class: 'ArtifactArchiver', artifacts: 'gameoflife-web/target/*.war'])
step([$class: 'WarningsPublisher', consoleParsers: [[parserName: 'Maven']]])
step([$class: 'JUnitResultArchiver', testResults: 
'**/target/surefire-reports/TEST-*.xml'])
step([$class: 'JavadocArchiver', javadocDir: 
'gameoflife-core/target/site/apidocs/'])
...

Cyrille

On Saturday, August 13, 2016 at 1:43:37 AM UTC+2, Will Currie wrote:
>
> Nice. It seems to non-pipeline/'old-school'/regular jenkins maven build 
> has support for tracking fingerprints of artefacts used and produced by any 
> given maven build. I'm taking about the work that seems to be done by 
> MavenFingerprinter 
> .
>  
> If I understand correctly this allows you to see builds upstream and 
> downstream of any given maven build.
>
> Any thoughts on how this might fit into the pipeline builds? The pipeline 
> tutorial shows how to configure fingerprints for build outputs 
> (**/target/*.jar). It doesn't seem to cover tracking fingerprints for what 
> it consumes.
>
> Thanks.
>
> On Friday, 12 August 2016 02:33:19 UTC+10, Álvaro Lobato wrote:
>>
>>
>> Hello everyone,
>>
>> I'd like to introduce you to the new Pipeline Maven 
>>  plugin . 
>> The intention of this plugin is to help using maven from pipeline, setting 
>> up a maven environment by using a withMaven step. This environment can 
>> later be called with sh or bat step.
>>
>> The supported configuration parameters are:
>>
>>- Maven Installation
>>- JDK
>>- Maven Settings Config (Config File Provider Plugin)
>>- Maven Settings File Path 
>>- Maven JVM Opts 
>>- Maven Local Repository 
>>
>> The step can be used used directly on a node or in a docker.inside.
>>
>> Currently it is in an early stage of development and I've just released 
>> the first beta version, already available in the update center.
>>
>> This is the start point for a more feature rich integration between 
>> pipeline and maven.
>>
>> You can find more information on the wiki page: Pipeline Maven plugin 
>>  
>>
>> Thanks
>> Alvaro.
>>
>

-- 
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/5528fdcb-f9a1-4af5-ad6f-c94fac2e20cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

ECR authentication issues

[Daniel Guisinger]

Hey guys, I'm back with another credentials issue.  I'm starting to think 
my copy of Jenkins is possessed.
(Last week I couldn't get the Jenkins Git plugin to authenticate using the 
http credentials stored in Credentials, but for some reason ssh credentials 
worked)

I have several projects, some in pipeline, and some just regular projects, 
that are using Docker to build and image, and then pushing it to an Amazon 
ECR repository.

It was working a few days ago.  I logged in last night, tried to run a 
build again and it no longer worked.
Even though I was referring to my credentials in the pipeline in the form 
of "ecr:aws" where aws was the ID of the credentials, it was still telling 
me I had an expired token and needed to perform a "aws ecr get-login" call.
All pipelines failed, even the non-pipeline project which clearly had the 
credentials selected, failed to work.

I then SSH'd into the box, ran aws ecr get-login and executed its output.
I tried to manually push an image from the shell, that worked.

I then went back into Jenkins and **ALL** of my projects were working 
again.

Any idea what I can do here?  It seems like once again, stock credential 
functionality is failing me... I'm at an utter loss, but I feel i need to 
babysit Jenkins 24x7 at the moment

(And yes, i know there is an outstanding bug for people using regions other 
than us-east-1 this is a us-east-1 registry)

-- 
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/29be78b6-eb82-4674-9de1-accd5993bb29%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: Best practices: many distinct jobs vs parameterized jobs

[Ginga, Dick]

FWIW, I have implemented a 2-tier build approach where the first job prepares 
the source code workspace, pulling from whatever SCM. The second tier is the 
builder. It takes, as one parameter, that is the $WORKSPACE of the tier 1 job, 
performs all the building, testing, scanning in THAT job’s workspace. At 
completion, the tier 1 job can now report all is own successes, build times, 
test results, etc

This model enables several things:


1.   One core builder common to lots of branches

2.   building from separate branches

3.   re-building past builds (the tier 1 job populates a workspace from a 
particular commit)

4.   tier 1 jobs that produces Release Candidates can run extra step like 
labeling the source, creating checksums, virus scanning the workspace, etc

5.   even build developer workspaces as long as the location is network 
accessible

From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of w...@anomalizer.net
Sent: Saturday, August 13, 2016 10:24 AM
To: Jenkins Users
Subject: Re: Best practices: many distinct jobs vs parameterized jobs

I follow the principle of "one job per codebase (git repo)". The problem with 
reusing the same job across multiple codebases is that it makes any and every 
trend data invalid for the job in question. By trend data, I mean things such as

  *   Build success rates
  *   Average build times
  *   Test success rates
  *   Test coverage data
  *   Static analysis trends
  *   Artifacts sizes
  *   ... etc. etc.
The way to think about what should run under a single job should be influenced 
by what kind of grouping would ensure that the trend data is meaningful.

The one place where this gets ambiguous is dealing with branches and forks for 
a give code base. There are situations wherein it makes sense to consolidate 
build trends across branches and orks into a single job and there are 
situations wherein it is best to track them separately. The only way to track 
it separately in jenkins 1.x is to have one job for each. Jenkins 2.x has a 
mechanism wherein you have have a single job (pipeline) across the branches and 
yet, track their statistics separately.


On Saturday, August 13, 2016 at 2:23:15 AM UTC+5:30, Rich Schumacher wrote:

Hey folks,



I'm using the Job DSL plugin to create CI/CD pipelines for a bunch of projects. 
The projects themselves are very similar and therefore the jobs for build and 
release will be nearly identical, differing only in stuff like Git repo to 
clone, email address for notifications, etc. I've been going back and forth 
about using distinct jobs for each project or to use a parameterized job for 
each step of the pipeline. The former leads to a proliferation of jobs that are 
nearly identical. The latter leads to jobs that might have 3-6 parameters and 
means it's difficult to use directly since you'll need to define all the 
parameters. The nice thing is that the Job DSL plugin makes either case pretty 
easy to support.



So my question is really about best practices and preferences: many distinct 
jobs vs a handful of parameterized jobs? Are there any non-obvious pro/cons 
that I'm missing?



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/1fd10095-47a2-4d3f-82fe-1b3f10cadd92%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/6C6EE445A6F6CE4E8A0FFB51B071A4E2D873D35D%40AMERMBX02.PERKINELMER.NET.
For more options, visit https://groups.google.com/d/optout.

Re: Parameterized build, REST, one parameter with new value rest with default

[thomas . lehmann]

Yes, basically you could retrieve the job XML parsing for the parameter 
definitions storing the default values and
then changing the values you want. Your function could also stop if not all 
mandatory fields are set.

I wrote my own jenkins controller (cannot publish the moment) but that one 
is not bad: https://github.com/txels/autojenkins
However one important feature is 
missing: https://github.com/txels/autojenkins/issues/30 (CSRF protection)

Regards,
Thomas

On Monday, August 15, 2016 at 8:53:44 AM UTC+2, Daniel Olausson wrote:
>
> Hi,
>
> I have a job that I would like to trigger via REST where I have one 
> parameter that I want to change every time and the other ones I would like 
> to use the default values for. If I do a POST to /build it just ignores the 
> default values and set them to empty. If I do a post to 
> /buildWithParameters I can't set the new value for the parameter I want, 
> the default values for all parameters are taken.
>
> How can I achieve this? First do a GET to get the default values, and then 
> do a POST to /build with all the parameters even if they are just the 
> default? 
>

-- 
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/10497232-60ea-4f9a-be8a-77820a60e9bf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: The option to “Launch slave agents via Java Web Start” is missing from new node configuration

[Daniel Beck]

Changing DescriptorVisibilityFilter would likely have unintended side effects. 
Should probably not use Descriptor visibility, but just have a warning in the 
JNLP specific config if the agent port is disabled. I'm thinking of something 
similar to Maven build step's (or possibly Maven Project's) warning when no 
Maven versions are set up.

> On 15.08.2016, at 10:39, Stephen Connolly  
> wrote:
> 
> Yep, that would require changes to how descriptor visibility filters work 
> though... so likely not going to change for the next couple of weeks (unless 
> somebody else picks it up that is)
> 
> On 15 August 2016 at 02:02, Ryan Campbell  wrote:
> I agree. This is impossible to discover for new or even experienced users.
> 
> 
> On Sun, Aug 14, 2016, 7:25 PM Richard Bywater  wrote:
> Perhaps it would be an idea to show the item but as disabled and state what 
> actions are required to get it enabled?
> 
> Richard.
> 
> On Mon, 15 Aug 2016 at 12:15 Stephen Connolly 
>  wrote:
> So the logic here is to reflect that the TCP agent port has been disabled and 
> thus the launcher is not available to you.
> 
> On 4 August 2016 at 11:47, Kumar Dp  wrote:
> I'm trying to configure a salve using "Launch slave agents via Java Web 
> Start", but I see that option is not listed in the launch method. I'm using 
> Jenkins 2.14 version.OS: Linux 3.8.13-68.3.4.el6uek.x86_64 
> Please help me to solve the issue
> 
> -- 
> 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/21bef93a-67f6-4eb4-887b-ea1bc7d5f6cd%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/CA%2BnPnMzbwTVUYGXuuZ1vx52rcj_G26LjWJkt24KVE%3DC1bJ2t0Q%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/CAMui945xtpCZ-SjuuuUrGvmOcHjxDmZVGaBGws9vXkcE9D0Z2Q%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/CANHK%3DJ27pAVHDAXaNAbcF-zJmhfg%3DkvjVptqOF%2BoUoVcGms2jQ%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/CA%2BnPnMwU2m5uxjeV8Fet43RGvyTd_2MBpU7_fSfROQa0yD3svw%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/3EF68766-374F-46A2-A0BD-E1BA419C5007%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: The option to “Launch slave agents via Java Web Start” is missing from new node configuration

[Stephen Connolly]

Yep, that would require changes to how descriptor visibility filters work
though... so likely not going to change for the next couple of weeks
(unless somebody else picks it up that is)

On 15 August 2016 at 02:02, Ryan Campbell  wrote:

> I agree. This is impossible to discover for new or even experienced users.
>
> On Sun, Aug 14, 2016, 7:25 PM Richard Bywater  wrote:
>
>> Perhaps it would be an idea to show the item but as disabled and state
>> what actions are required to get it enabled?
>>
>> Richard.
>>
>> On Mon, 15 Aug 2016 at 12:15 Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>>> So the logic here is to reflect that the TCP agent port has been
>>> disabled and thus the launcher is not available to you.
>>>
>>> On 4 August 2016 at 11:47, Kumar Dp  wrote:
>>>
 I'm trying to configure a salve using "Launch slave agents via Java Web
 Start", but I see that option is not listed in the launch method. I'm using
 Jenkins 2.14 version.OS: Linux 3.8.13-68.3.4.el6uek.x86_64
 Please help me to solve the issue

 --
 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/21bef93a-67f6-4eb4-887b-
 ea1bc7d5f6cd%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/CA%2BnPnMzbwTVUYGXuuZ1vx52rcj_
>>> G26LjWJkt24KVE%3DC1bJ2t0Q%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/CAMui945xtpCZ-SjuuuUrGvmOcHjxDmZVGaBGws9vXkc
>> E9D0Z2Q%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/CANHK%3DJ27pAVHDAXaNAbcF-zJmhfg%
> 3DkvjVptqOF%2BoUoVcGms2jQ%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/CA%2BnPnMwU2m5uxjeV8Fet43RGvyTd_2MBpU7_fSfROQa0yD3svw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Persistent connection between slave and master when connecting through JNLP + command line

[Custodia]

I have just setup a powershell script for windows slaves that install 
everything required for builds and automatically connects the slave to it's 
master based on the parameters given when the script was executed. This 
works fine until I close the powershell window or need to reboot the 
computer. Immediately when I close the window the slave connection dies.

I haven't got much experience with this JNLP connection so I have a few 
questions. Does the web interface version reconnect when the slave machine 
is rebooted? Would there be any differences between a manual connection and 
the scripted one if the script output was hidden in a background process? 
And the biggest one, how do people manage holding persistent connections 
between master and slave where the slave machine might be restarted?

My current idea was to instead of launching the connection at the end of 
the script save it in a executable and execute that everytime the machine 
is booted.

-- 
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/b465b78e-997e-491b-84e7-27b5b8c56c0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Parameterized build, REST, one parameter with new value rest with default

[Daniel Olausson]

Hi,

I have a job that I would like to trigger via REST where I have one 
parameter that I want to change every time and the other ones I would like 
to use the default values for. If I do a POST to /build it just ignores the 
default values and set them to empty. If I do a post to 
/buildWithParameters I can't set the new value for the parameter I want, 
the default values for all parameters are taken.

How can I achieve this? First do a GET to get the default values, and then 
do a POST to /build with all the parameters even if they are just the 
default? 

-- 
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/1a9bc9c4-be67-4549-8fd2-99ed92827bf7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multibranch Pipeline: Using notifyCommit does not indicate an SCM change

[Sverre Moe]

Created
https://issues.jenkins-ci.org/browse/JENKINS-37406

mandag 15. august 2016 06.30.34 UTC+2 skrev James Dumay følgende:
>
> Hi Sverre,
>
> Hmm, that doesn't sound like we are doing the right thing there. Could you 
> please provide us with a detailed bug report on 
> https://issues.jenkins-ci.org ? Any reproduction steps, examples, 
> screenshots, etc would be greatly appreciated. 
>
> On Friday, August 12, 2016 at 4:50:22 PM UTC+10, Sverre Moe wrote:
>>
>> There is no longer an SCM change when using Multibranch Pipeline.
>> "Started by an SCM change"
>>
>> Instead when the git server executes notifyCommit the branch that has 
>> changes shows "Branch indexing" and a question mark. Though at least the 
>> changes from SCM are shown on each build.
>>
>> Its just that Branch indexing with a Question mark does not look good. 
>> Though when the build completes the question mark is gone. Better yet the 
>> --/++ badge icon indicating an SCM change should be used. At least when I 
>> start a build manually it shows "Started by user *" as tooltip on the 
>> user badge icon.
>>
>

-- 
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/ca9589f8-ca0f-45e9-a7db-6f68d9571f7d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.