Re: Help request: Naming things is hard (JENKINS-43426)

[Stephen Connolly]

On Fri 21 Apr 2017 at 22:57, Martin d'Anjou 
wrote:

> Disclaimer: I do not use those plugins.
>
>
> *Can you suggest a better UI name for this trait than "Discover branches"?*
>
>
> No.
>
>>
>> *Does "Discover branches" scream out what it does?*
>
>
> Yes.
>
>
>>
>> *Can you suggest a better UI name for the "Strategy" field in "Discover
>> branches"?*
>
>
> No.
>
>>
>>- *Can you suggest better names for any of the 3 strategy options?*
>>
>> Anything that contains something resembling a double negative confuses
> me, e.g. "only that are not also", so if I understand correctly the types
> of branches that may exist, this is my suggestion:
> * Only PR branches
> * Only non-PR branches
> * All branches
>
>
>>- Currently the GitHub Branch Source has two check boxes to control
>>both whether it discovers pull requests originating from the repository
>>itself and how to build those pull requests.
>>
>>I have replaced these two checkboxes with a trait. The trait has a
>>drop-down configuration. Selecting either the 1st or the 2nd of these
>>options will build either the merge or the head commit and will call the
>>branches PR-xxx. Selecting the 3rd of these options will build two 
>> branches
>>for every PR one called PR-xxx-merge and one called PR-xxx-head.
>>
>>*Can you suggest a better UI name for this trait than "Discover pull
>>requests from origin"?*
>>*Does "Discover pull requests from origin" scream out what it does?*
>>*Can you suggest a better UI name for the "Strategy" field in
>>"Discover pull requests from origin"?*
>>*Can you suggest better names for any of the 3 strategy options?*
>>
>>
>> Ditto and:
> In BitBucket Server, pull-requests exist on the upstream, not on the
> origin. But what does "origin" refer to here?
> In terms of better names for the strategies:
> * Checkout target branch and merge pull-request to it
> * Checkout pull-request
> * Do both (in separate builds) - (this is my understanding and I could be
> wrong)
>

Not just separate builds, separate jobs. One job for PR-head and one job
for PR-merge


>
>
>>
>>- *Can you suggest a better UI name for this trait than "Discover
>>pull requests from forks"?*
>>*Does "Discover pull requests from forks" scream out what it does?*
>>*Can you suggest a better UI name for the "Strategy" field in
>>"Discover pull requests from forks"?*
>>*Can you suggest better names for any of the 3 strategy options?*
>>
>> Ditto.
>
> But now I am confused. Pull-requests in BitBucket Server have 4
> coordinates: source repo, source branch, target repo and target branch.
> This results in the target branch being created on the target repo. And the
> target repo is the only place where the pull-request can be discovered, as
> far I as I know. So I am not sure what "discovering pull-requests on forks"
> means vs. "discover pull requests from origin".
>

So this is discovering PRs where the source repo != target repo


>
> To me, a Jenkins Job should have a single purpose, and to me a single
> purpose is to merge a pull request to a single possible destination. If the
> Jenkins Job is able to merge to different destinations, then it's not the
> same Job because it does not serve the same purpose.
>

Each "head" gets their own Job


>
>
>>- *Can you suggest a better UI name for the "Trust" field in
>>"Discover pull requests from forks"?*
>>*Can you suggest better names for any of the current base default 3
>>strategy options: "Collaborators", "None" and "Everyone"?*
>>
>> Who is the list of collaborators and how does someone get there?
> None -> Nobody?
>
>
>>
>>- Currently, hidden in the advanced box there is an Includes/Excludes
>>option. There are a lot of requests for different syntaxes of specifying
>>includes / excludes. Due to backwards compatibility we cannot change the
>>syntax, so my solution is to allow plugins to extend and add traits for 
>> the
>>different syntaxes.
>>
>>To retain backwards compatibility of existing configurations, we need
>>to provide one that uses the current wildcard (without globs) matching.
>>
>>*Can you suggest a better UI name for this trait than "Filter by name
>>(with wildcards)"?*
>>
>> What is being filtered by name? The name of the pull-request branch? The
> name of the pull-request?
>
> Hope this helps,
> Martin
>
> --
> 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/a6551467-5575-44f1-a0be-4ce644422668%40googlegroups.com
> 
> .
> For more options, 

Re: Help request: Naming things is hard (JENKINS-43426)

[Martin d'Anjou]

Disclaimer: I do not use those plugins.

*Can you suggest a better UI name for this trait than "Discover branches"?*


No. 

>
> *Does "Discover branches" scream out what it does?*


Yes.
 

>
> *Can you suggest a better UI name for the "Strategy" field in "Discover 
> branches"?*


No. 

>
>- *Can you suggest better names for any of the 3 strategy options?*
>
> Anything that contains something resembling a double negative confuses me, 
e.g. "only that are not also", so if I understand correctly the types of 
branches that may exist, this is my suggestion:
* Only PR branches
* Only non-PR branches
* All branches


>- Currently the GitHub Branch Source has two check boxes to control 
>both whether it discovers pull requests originating from the repository 
>itself and how to build those pull requests.
>
>I have replaced these two checkboxes with a trait. The trait has a 
>drop-down configuration. Selecting either the 1st or the 2nd of these 
>options will build either the merge or the head commit and will call the 
>branches PR-xxx. Selecting the 3rd of these options will build two 
> branches 
>for every PR one called PR-xxx-merge and one called PR-xxx-head.
>
>*Can you suggest a better UI name for this trait than "Discover pull 
>requests from origin"?*
>*Does "Discover pull requests from origin" scream out what it does?*
>*Can you suggest a better UI name for the "Strategy" field in 
>"Discover pull requests from origin"?*
>*Can you suggest better names for any of the 3 strategy options?*
>
>
> Ditto and:
In BitBucket Server, pull-requests exist on the upstream, not on the 
origin. But what does "origin" refer to here?
In terms of better names for the strategies:
* Checkout target branch and merge pull-request to it
* Checkout pull-request
* Do both (in separate builds) - (this is my understanding and I could be 
wrong)
 

>
>- *Can you suggest a better UI name for this trait than "Discover pull 
>requests from forks"?*
>*Does "Discover pull requests from forks" scream out what it does?*
>*Can you suggest a better UI name for the "Strategy" field in 
>"Discover pull requests from forks"?*
>*Can you suggest better names for any of the 3 strategy options?*
>
> Ditto.

But now I am confused. Pull-requests in BitBucket Server have 4 
coordinates: source repo, source branch, target repo and target branch. 
This results in the target branch being created on the target repo. And the 
target repo is the only place where the pull-request can be discovered, as 
far I as I know. So I am not sure what "discovering pull-requests on forks" 
means vs. "discover pull requests from origin".
 
To me, a Jenkins Job should have a single purpose, and to me a single 
purpose is to merge a pull request to a single possible destination. If the 
Jenkins Job is able to merge to different destinations, then it's not the 
same Job because it does not serve the same purpose.


>- *Can you suggest a better UI name for the "Trust" field in "Discover 
>pull requests from forks"?*
>*Can you suggest better names for any of the current base default 3 
>strategy options: "Collaborators", "None" and "Everyone"?*
>
> Who is the list of collaborators and how does someone get there?
None -> Nobody?
 

>
>- Currently, hidden in the advanced box there is an Includes/Excludes 
>option. There are a lot of requests for different syntaxes of specifying 
>includes / excludes. Due to backwards compatibility we cannot change the 
>syntax, so my solution is to allow plugins to extend and add traits for 
> the 
>different syntaxes. 
>
>To retain backwards compatibility of existing configurations, we need 
>to provide one that uses the current wildcard (without globs) matching.
>
>*Can you suggest a better UI name for this trait than "Filter by name 
>(with wildcards)"?*
>
> What is being filtered by name? The name of the pull-request branch? The 
name of the pull-request?  

Hope this helps,
Martin

-- 
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/a6551467-5575-44f1-a0be-4ce644422668%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Scripts not permitted to use staticMethod in Extensible Choice System Groovy

[Victoria Kozel]

Victor,
 thank you so much for your help! I already had Script Security Plugin 
installed, and all the methods I tried to execute unsuccessfully were 
conveniently added in the Method Authorization queue! All i needed to do is 
just approved them. Worked like a charm. Thank you!!

On Thursday, April 20, 2017 at 5:09:54 PM UTC-7, Victoria Kozel wrote:
>
> Hello,
>
> I am writing a simple groovy script to display role-based choices in the 
> Extensible Choice. I get 
>
> org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts 
> not permitted to use staticMethod jenkins.model.Jenkins getInstance
>
>
> when calling 
>
>
> def authStrategy = Jenkins.instance.getAuthorizationStrategy()
>
>
> I am not sure I understand the reason for this, but my question is - Is there 
> a workaround for this error?
>
>
> Thank you!!
>
> Vicki
>
>

-- 
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/b84f6e6e-9b68-4ef9-9d34-aafda5caedc8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: What is difference between script pending approval and signature pending approval in In-process Script Approval(Plugin)

[Victor Martinez]

You can find those details much better explained in the below wiki:
- https://wiki.jenkins-ci.org/display/JENKINS/Script+Security+Plugin

But basically: script is the whole 'script' while the signature is just the 
method. Signatures are just a subset of the scripts. More fine granularity 
while using signatures rather than scripts, but on the other hand more 
tedious though.

I hope I could explain that correctly.

Cheers

On Tuesday, 18 April 2017 02:01:02 UTC+1, Sree Kanth wrote:
>
> Manage Jenkins'
> |
> In-process Script Approval(Plugin)
> |
> What is difference between script pending approval and signature pending 
> approva
>

-- 
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/c5ec45e8-8c4b-480a-b88a-ad54d4ee2f47%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to approve pending signatures?

[Victor Martinez]

That's related to the 
plugin: https://wiki.jenkins-ci.org/display/JENKINS/Script+Security+Plugin 
therefore you can approve those functions/methods in the global settings. 

An administrator may now go to *Manage Jenkins » In-process Script Approval* 
where a list of scripts pending approval will be shown. Assuming nothing 
dangerous-looking is being requested, just click *Approve* to let the 
script be run henceforth.

Then you don't need to change the xml manually and reboot Jenkins

Cheers

On Thursday, 20 April 2017 10:08:29 UTC+1, Maciej Gawinecki wrote:
>
> Hi,
>
> I have pipeline that downloads Groovy script from Git, but Groovy script 
> fails with
>
>   org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: 
> Scripts not permitted to use method java.net.URL openStream
>
> I found /var/lib/jenkins/scriptApproval.xml file with the following excerpt:
>
>
>
>   
>   ...
>   
> 
>   
>   method java.net.URL openStream
>   true
> 
>   
> ...
> 
>
>
> I have editted the script into
>
>   
>   method java.net.URL openStream
>   
> ...
> 
>
> but after Jenkins restart and re-running the pipeline it get overwritten.
>
> How do I approve pending signatures?
>
> Regards,
> Maciej
>

-- 
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/d7cbc30a-5dd6-455f-b72b-3407e4409ad0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins BuildHistory | MBs of space is consumed

[Victor Martinez]

https://wiki.jenkins-ci.org/display/JENKINS/Disk+Usage+Plugin is enabled in 
that particular Jenkins instance, you can find further details in that link 
about what the plugin does.

Cheers

On Thursday, 20 April 2017 11:43:20 UTC+1, thomas@teamaol.com wrote:
>
> I would assume that is the size (sum) of your build artifacts.
> When you click in one history entry you should see the build artifacts 
> (and its size)
>
> On Wednesday, April 19, 2017 at 12:17:35 PM UTC+2, LnT wrote:
>>
>> Hi,
>>
>> one of my job's history show like below.
>> What are these statistics under trend ?
>>
>> why such MBs of space is consumed ?
>> Any cluse
>>
>>
>> Regards,
>> LnT
>>
>

-- 
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/2927be1c-f054-4e77-b54c-69124f631e30%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Connecting Jenkins to Moodle

[Mark Waite]

A casual glance at the Moodle competency API 
(https://docs.moodle.org/dev/Competency_API) hints that you might be able 
to have the student create a Jenkins job which compiles and runs a program 
(written by the student) which includes a library call (library provided by 
you) that register the results of the student effort (compilation and 
running of that program) with the Moodle competency API.

You might provide your library in several different languages so that the 
students create and experience Jenkins with multiple languages and/or 
multiple platforms.

Another (possibly simpler) approach would be to point the students to one 
or more source code repositories (GitHub) which they will use to create 
something with Jenkins (compile, run tests, etc.).  You can include your 
"report back to Moodle" in those source code repositories.  When it 
compiles successfully, it will notify Moodle that the student has completed 
the lesson.

Mark Waite

On Friday, April 21, 2017 at 5:33:54 AM UTC-6, dursun...@gmail.com wrote:
>
> Hello erveyone,
>
> at the moment I am writing my bachelor thesis on the topic "Connecting 
> software development tools to an e-learning platform". The E-Learning 
> platform in this case is 'Moodle'. The Tools would be for example 
> 'Jenkins'. 
>
> My task is to find out, whether following szenario is possible:
> You are a Moodle participant and you have chosen the course for learning 
> how to use 'jenkins'. First you are reading general things on slides in 
> Moodle. After reading and getting a picture of Jenkins functionalities, the 
> next task in moodle would be to open the tool jenkins and do a specific 
> task there. Problem is how does the Moodle trainer know that this task has 
> been done? 
>
> My aim is to find out how the Moodle trainer knows that the task in the 
> external tool is done.
>
> Could this be done via web services e.g. Rest since Jenkins has the REST 
> interface? In Jenkins it should be checked whether a certain task has been 
> done, if so an email should be sent to the Moodle Trainer.
>
> This is the only possibility I can imagine at the moment.
>
> Maybe it would also be possible to do that through a URL which gets the 
> information form Jenkins and the trainer can always check the URL?...
>
> Is that possible?
> Do you have other approaches?
> I am grateful for any help!
>
> greetings
> Jüli
>

-- 
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/13d6ed96-789d-442c-b8c4-aca3ba344805%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Git Parameter Plug-in does not list Git commit Ids

[Victor Martinez]

For any Cloudbees product related topics/issues please contact Cloudbees 
support.

Cheers

On Thursday, 20 April 2017 16:31:45 UTC+1, Sukumar Reddy wrote:
>
> Hello All,
>
> we are using jenkins 2.7.22.0.3 (cloudbees version)
> Configured build parameterized job and i am able to view the git commit 
> ids in git parameter box
>
> Attached images for better understanding. Please suggest me if any one has 
> come across similar 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/40046f1b-9b56-4b24-a939-492bd5d3d36f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: email-ext circular dependency

[Victor Martinez]

As far as I see there was a comment about:
- 
https://wiki.jenkins-ci.org/display/JENKINS/Email-ext+plugin#Email-extplugin-2.40.3(May20,2015)

If you downgrade the version to 2.40.3, does it work?
- http://updates.jenkins-ci.org/download/plugins/email-ext/2.40.3/email-ext.hpi

If so, then raise a jira ticket with those details then they can narrow 
down what diffs are between 2.57.2 and 2.40.3

Cheers

On Friday, 21 April 2017 19:51:15 UTC+1, Chanda Unmack wrote:
>
> Hi all,
>
>  
>
> Our Jenkins instance has been unstable ever since we’ve moved it to RHEL 
> so I’ve been watching the logs to see if there is anything I can find to 
> correlate the crashes. (already filed a bug on all the npes we’re getting)
>
> I now see an error in the log when it’s become unresponsive that is 
> related to email-ext plugin. I did a search and found an old bug with the 
> same error [JENKINS-28402] but it was on a different version and has been 
> closed with some back and forth that didn’t seem to address the issue.
>
>  
>
> Jenkins 2.46.1
>
> Email-ext 2.57.2
>
>  
>
> WARNING: Failed to instantiate 
> Key[type=hudson.plugins.emailext.ExtendedEmailPublisherDescriptor, 
> annotation=[none]]; skipping this component
>
> com.google.inject.ProvisionException: Unable to provision, see the 
> following errors:
>
>  
>
> 1) Tried proxying hudson.plugins.emailext.ExtendedEmailPublisherDescriptor 
> to support a circular dependency, but it is not an interface.
>
>  
>
> 1 error
>
> at 
> com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:52)
>
> at 
> com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
>
> at 
> hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1.get(ExtensionFinder.java:424)
>
> at 
> com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
>
> at 
> com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
>
> at 
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)jjj
>
> at 
> com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
>
> at 
> hudson.ExtensionFinder$GuiceFinder._find(ExtensionFinder.java:386)
>
> at 
> hudson.ExtensionFinder$GuiceFinder.find(ExtensionFinder.java:377)
>
> at 
> hudson.ClassicPluginStrategy.findComponents(ClassicPluginStrategy.java:472)
>
> at hudson.ExtensionList.load(ExtensionList.java:365)
>
> at hudson.ExtensionList.ensureLoaded(ExtensionList.java:303)
>
> at hudson.ExtensionList.getComponents(ExtensionList.java:168)
>
> at 
> hudson.DescriptorExtensionList.load(DescriptorExtensionList.java:191)
>
> at hudson.ExtensionList.ensureLoaded(ExtensionList.java:303)
>
> at hudson.ExtensionList.iterator(ExtensionList.java:157)
>
> at hudson.model.User.load(User.java:201)
>
> at hudson.model.User.(User.java:155)
>
> at hudson.model.User.getOrCreate(User.java:463)
>
> at hudson.model.User.getById(User.java:534)
>
> at hudson.model.User.get(User.java:518)
>
> at hudson.model.User.current(User.java:502)
>
> at 
> org.jenkinsci.plugins.scriptsecurity.scripts.ApprovalContext.withCurrentUser(ApprovalContext.java:73)
>
> at 
> hudson.plugins.emailext.ExtendedEmailPublisherDescriptor.setDefaultPostsendScript(ExtendedEmailPublisherDescriptor.java:514)
>
> at 
> hudson.plugins.emailext.ExtendedEmailPublisherDescriptor.(ExtendedEmailPublisherDescriptor.java:183)
>
> at 
> hudson.plugins.emailext.ExtendedEmailPublisherDescriptor$$FastClassByGuice$$5dfa54d0.newInstance()
>
> at 
> com.google.inject.internal.cglib.reflect.$FastConstructor.newInstance(FastConstructor.java:40)
>
> at 
> com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:61)
>
> at 
> com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:105)
>
> at 
> com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:85)
>
> at 
> com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267)
>
> at 
> com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
>
> at 
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
>
> at 
> com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
>
> at 
> com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
>
> at 
> hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1.get(ExtensionFinder.java:424)
>
> at 
> com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
>
> at 
> 

email-ext circular dependency

[Chanda Unmack]

Hi all,

Our Jenkins instance has been unstable ever since we've moved it to RHEL so 
I've been watching the logs to see if there is anything I can find to correlate 
the crashes. (already filed a bug on all the npes we're getting)
I now see an error in the log when it's become unresponsive that is related to 
email-ext plugin. I did a search and found an old bug with the same error 
[JENKINS-28402] but it was on a different version and has been closed with some 
back and forth that didn't seem to address the issue.

Jenkins 2.46.1
Email-ext 2.57.2

WARNING: Failed to instantiate 
Key[type=hudson.plugins.emailext.ExtendedEmailPublisherDescriptor, 
annotation=[none]]; skipping this component
com.google.inject.ProvisionException: Unable to provision, see the following 
errors:

1) Tried proxying hudson.plugins.emailext.ExtendedEmailPublisherDescriptor to 
support a circular dependency, but it is not an interface.

1 error
at 
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:52)
at 
com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
at 
hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1.get(ExtensionFinder.java:424)
at 
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at 
com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at 
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)jjj
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at hudson.ExtensionFinder$GuiceFinder._find(ExtensionFinder.java:386)
at hudson.ExtensionFinder$GuiceFinder.find(ExtensionFinder.java:377)
at 
hudson.ClassicPluginStrategy.findComponents(ClassicPluginStrategy.java:472)
at hudson.ExtensionList.load(ExtensionList.java:365)
at hudson.ExtensionList.ensureLoaded(ExtensionList.java:303)
at hudson.ExtensionList.getComponents(ExtensionList.java:168)
at hudson.DescriptorExtensionList.load(DescriptorExtensionList.java:191)
at hudson.ExtensionList.ensureLoaded(ExtensionList.java:303)
at hudson.ExtensionList.iterator(ExtensionList.java:157)
at hudson.model.User.load(User.java:201)
at hudson.model.User.(User.java:155)
at hudson.model.User.getOrCreate(User.java:463)
at hudson.model.User.getById(User.java:534)
at hudson.model.User.get(User.java:518)
at hudson.model.User.current(User.java:502)
at 
org.jenkinsci.plugins.scriptsecurity.scripts.ApprovalContext.withCurrentUser(ApprovalContext.java:73)
at 
hudson.plugins.emailext.ExtendedEmailPublisherDescriptor.setDefaultPostsendScript(ExtendedEmailPublisherDescriptor.java:514)
at 
hudson.plugins.emailext.ExtendedEmailPublisherDescriptor.(ExtendedEmailPublisherDescriptor.java:183)
at 
hudson.plugins.emailext.ExtendedEmailPublisherDescriptor$$FastClassByGuice$$5dfa54d0.newInstance()
at 
com.google.inject.internal.cglib.reflect.$FastConstructor.newInstance(FastConstructor.java:40)
at 
com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:61)
at 
com.google.inject.internal.ConstructorInjector.provision(ConstructorInjector.java:105)
at 
com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:85)
at 
com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:267)
at 
com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
at 
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1103)
at 
com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
at 
com.google.inject.internal.SingletonScope$1.get(SingletonScope.java:145)
at 
hudson.ExtensionFinder$GuiceFinder$FaultTolerantScope$1.get(ExtensionFinder.java:424)
at 
com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
at 
com.google.inject.internal.InjectorImpl$2$1.call(InjectorImpl.java:1016)
at 
com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1092)
at com.google.inject.internal.InjectorImpl$2.get(InjectorImpl.java:1012)
at hudson.ExtensionFinder$GuiceFinder._find(ExtensionFinder.java:386)
at hudson.ExtensionFinder$GuiceFinder.find(ExtensionFinder.java:377)
at 
hudson.ClassicPluginStrategy.findComponents(ClassicPluginStrategy.java:472)
at hudson.ExtensionList.load(ExtensionList.java:365)
at hudson.ExtensionList.ensureLoaded(ExtensionList.java:303)
at hudson.ExtensionList.iterator(ExtensionList.java:157)
at jenkins.model.Jenkins.getDescriptorByType(Jenkins.java:1519)
at 

Re: BlueOcean: missing visual pipeline editor

[R. Tyler Croy]

(replies inline)

On Fri, 21 Apr 2017, Ramanathan Muthaiah wrote:

> Hello,
> 
> In the BlueOcean UI, I chose Git and provided the repo name hosted within 
> organization umbrella. However, with this choice, visual pipeline editor is 
> not visible.
> 
> Does anyone why is this and what am missing ?


Git is not yet fully supported for the editor, only GitHub, see:
https://issues.jenkins-ci.org/browse/JENKINS-43148

- R. Tyler Croy

--
 Code: 
  Chatter: 
 xmpp: rty...@jabber.org

  % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F
--

-- 
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/20170421163238.4lre6nvdk5xvkjkm%40blackberry.coupleofllamas.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Help request: Naming things is hard (JENKINS-43426)

[Stephen Connolly]

Famously, in computer science there are only two hard problems:

1. Cache invalidation
2. Naming things
3. Off-by-one counting bugs

In the GitHub Branch Source and Bitbucket Branch Source plugins I am
currently trying to refactor the UI with a number of goals:

1. Make it easier for users to understand what the different configuration
options do
2. Make it easier for plugin developers to enhance the functionality and
provide more complex variants.
3. Add some configuration aspects that are currently not possible.

In terms of the code structure for this refactoring I have a good idea as
to the shape of the solution that will work *within the constraints of the
Jenkins Classic UI paradimes*.

Here is an animated GIF showing the approximate shape of the solution.



What I now need to solve, while also refactoring this UI to share
commonality between Bitbucket and GitHub (as well as allowing e.g. Gogs and
GitLab to leverage this same commonality) is *the naming of things*. This
is where you can come in.

I need good names for things.

   - There are a pile of things that will be able to be attached to a
   branch source. In the code I am calling these Traits. That name does not
   make good sense for users. In the above animation I call them Behaviours.

   The list of ones will also include a subset of the Git SCM "Additional
   Behaviours" such as clean before/after checkout, etc

   *Can you suggest a better UI name for traits than Behaviors?*

   - Currently the GitHub Branch Source has two check-boxes to control
   whether it discovers branches on the repository. If you check one of these
   two boxes then either you will get all the branches that are not also a PR
   or all the branches that are also a PR (this second one seems nuts but
   backwards compatibility). If you check both of the boxes you get all the
   branches.

   I have replaced these two checkboxes with a trait. The trait has a drop
   down configuration that lets you select the three combinations of which
   branches to build. The 4th combination (corresponding to not checking
   either of the checkboxes in the current UI) is to just remove the trait.

   *Can you suggest a better UI name for this trait than "Discover
   branches"?*
   *Does "Discover branches" scream out what it does?*
   *Can you suggest a better UI name for the "Strategy" field in "Discover
   branches"?*
   *Can you suggest better names for any of the 3 strategy options?*

   - Currently the GitHub Branch Source has two check boxes to control both
   whether it discovers pull requests originating from the repository itself
   and how to build those pull requests.

   I have replaced these two checkboxes with a trait. The trait has a
   drop-down configuration. Selecting either the 1st or the 2nd of these
   options will build either the merge or the head commit and will call the
   branches PR-xxx. Selecting the 3rd of these options will build two branches
   for every PR one called PR-xxx-merge and one called PR-xxx-head.

   *Can you suggest a better UI name for this trait than "Discover pull
   requests from origin"?*
   *Does "Discover pull requests from origin" scream out what it does?*
   *Can you suggest a better UI name for the "Strategy" field in "Discover
   pull requests from origin"?*
   *Can you suggest better names for any of the 3 strategy options?*

   - Currently the GitHub Branch Source has two check boxes to control both
   whether it discovers pull requests originating from forks of the repository
   and how to build those pull requests

   I have replaced these two checkboxes with a trait.

   The trait has a drop-down configuration for selecting what to build.
   Selecting either the 1st or the 2nd of these options will build either the
   merge or the head commit and will call the branches PR-xxx. Selecting the
   3rd of these options will build two branches for every PR one called
   PR-xxx-merge and one called PR-xxx-head.

   The trait also has a drop down configuration for selecting how to
   "trust" pull requests from forks. *New feature*. Currently only pull
   requests from collaborators are trusted. This new feature will enable
   control on how a pull request gets trusted. Along with additional features
   - such as being able to block automatic builds of non-trusted pull requests
   - this should enable a lot more control (e.g. an extension plugin could
   only trust pull requests where a collaborator had added a comment with a
   magic string or assigned a label)

   *Can you suggest a better UI name for this trait than "Discover pull
   requests from forks"?*
   *Does "Discover pull requests from forks" scream out what it does?*
   *Can you suggest a better UI name for the "Strategy" field in "Discover
   pull requests from forks"?*
   *Can you suggest better names for any of the 3 strategy options?*
   *Can you suggest a better UI name for the "Trust" field in "Discover
   pull requests from forks"?*
   *Can you suggest better 

Connecting Jenkins to Moodle

[dursun . julide]

Hello erveyone,

at the moment I am writing my bachelor thesis on the topic "Connecting 
software development tools to an e-learning platform". The E-Learning 
platform in this case is 'Moodle'. The Tools would be for example 
'Jenkins'. 

My task is to find out, whether following szenario is possible:
You are a Moodle participant and you have chosen the course for learning 
how to use 'jenkins'. First you are reading general things on slides in 
Moodle. After reading and getting a picture of Jenkins functionalities, the 
next task in moodle would be to open the tool jenkins and do a specific 
task there. Problem is how does the Moodle trainer know that this task has 
been done? 

My aim is to find out how the Moodle trainer knows that the task in the 
external tool is done.

Could this be done via web services e.g. Rest since Jenkins has the REST 
interface? In Jenkins it should be checked whether a certain task has been 
done, if so an email should be sent to the Moodle Trainer.

This is the only possibility I can imagine at the moment.

Maybe it would also be possible to do that through a URL which gets the 
information form Jenkins and the trainer can always check the URL?...

Is that possible?
Do you have other approaches?
I am grateful for any help!

greetings
Jüli

-- 
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/8ad9259f-cdf2-4bea-a55c-ca81b4df0dd8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: Pipeline jobs: How are return codes handled?

[David Aldrich]

Thanks for your reply but I am still confused.  Looking at:

https://jenkins.io/doc/pipeline/steps/workflow-durable-task-step/#code-sh-code-shell-script

returnStatus (optional)
Normally, a script which exits with a nonzero status code will cause the step 
to fail with an exception. If this option is checked, the return value of the 
step will instead be the status code. You may then compare it to zero, for 
example.

So if I specify that option I get the status code, but will Jenkins fail the 
pipeline if the code is non-zero or do I have to do that myself?

If I don’t specify that option I will get an exception on a failure.  Will that 
fail the job neatly or will I get an exception trace?

From: Ramanathan Muthaiah [mailto:rus.cah...@gmail.com]
Sent: 21 April 2017 11:05
To: Jenkins Users 
Cc: David Aldrich 
Subject: Re: Pipeline jobs: How are return codes handled?

On Friday, April 21, 2017 at 3:22:49 PM UTC+5:30, David Aldrich wrote:
Hi

In a conventional Jenkins job, my understanding is that the job will fail if 
the last command of a shell build step indicates an error.

I am now experimenting with pipeline jobs and have something like:

node {
stage('Checkout') {}

sh returnStatus: true, script: '''cd software
  make cleanall
  make '''
}

I am not sure what is happening here.


1)  Will the same rule apply that the job will fail if the last command of 
the sh step fails?

2)  What is ‘returnStatus: true, script’ doing?

Regd item 2), returnStatus will return the execution completion status of 
commands enclosed within "script: "

It can be either 127 (if the command is not found) or 1 for failed valid 
command or 0 for valid command that has been executed successfully.

Refer to these links for more info:

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

https://jenkins.io/doc/pipeline/steps/workflow-durable-task-step/#code-sh-code-shell-script

http://stackoverflow.com/questions/36956977/how-to-execute-a-command-in-a-jenkins-2-0-pipeline-job-and-then-return-the-stdou

http://stackoverflow.com/questions/36547680/how-to-do-i-get-the-output-of-a-shell-command-executed-using-into-a-variable-fro

https://support.cloudbees.com/hc/en-us/articles/218554077-How-to-set-current-build-result-in-Pipeline


Click 
here
 to report this email as spam.

-- 
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/20a2d132608c4d7bac0918129029e45c%40EUX13SRV1.EU.NEC.COM.
For more options, visit https://groups.google.com/d/optout.

Re: Pipeline jobs: How are return codes handled?

[Ramanathan Muthaiah]

On Friday, April 21, 2017 at 3:22:49 PM UTC+5:30, David Aldrich wrote:
>
> Hi
>
>  
>
> In a conventional Jenkins job, my understanding is that the job will fail 
> if the last command of a shell build step indicates an error.
>
>  
>
> I am now experimenting with pipeline jobs and have something like:
>
>  
>
> node {
>
> stage('Checkout') {}
>
>  
>
> sh returnStatus: true, script: '''cd software
>
>   make cleanall
>
>   make '''
>
> }
>
>  
>
> I am not sure what is happening here.
>
>  
>
> 1)  Will the same rule apply that the job will fail if the last 
> command of the sh step fails?
>
> 2)  What is ‘returnStatus: true, script’ doing?
>

Regd item 2), returnStatus will return the execution completion status of 
commands enclosed within "script: " 

It can be either 127 (if the command is not found) or 1 for failed valid 
command or 0 for valid command that has been executed successfully.

Refer to these links for more info:

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

https://jenkins.io/doc/pipeline/steps/workflow-durable-task-step/#code-sh-code-shell-script

http://stackoverflow.com/questions/36956977/how-to-execute-a-command-in-a-jenkins-2-0-pipeline-job-and-then-return-the-stdou

http://stackoverflow.com/questions/36547680/how-to-do-i-get-the-output-of-a-shell-command-executed-using-into-a-variable-fro

https://support.cloudbees.com/hc/en-us/articles/218554077-How-to-set-current-build-result-in-Pipeline

-- 
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/befed8e7-cc85-4fb7-a585-bb7e31d41cb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Pipeline jobs: How are return codes handled?

[David Aldrich]

Hi

In a conventional Jenkins job, my understanding is that the job will fail if 
the last command of a shell build step indicates an error.

I am now experimenting with pipeline jobs and have something like:

node {
stage('Checkout') {}

sh returnStatus: true, script: '''cd software
  make cleanall
  make '''
}

I am not sure what is happening here.


1)  Will the same rule apply that the job will fail if the last command of 
the sh step fails?

2)  What is 'returnStatus: true, script' doing?


Best regards

David

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

Pipeline job: How to build entire script from SCM?

[David Aldrich]

Hi

The deprecated pipeline tutorial:

https://github.com/jenkinsci/pipeline-plugin/blob/master/TUTORIAL.md

states:

'Building Entire Script from SCM: The easiest way to do this is to select 
Pipeline script from SCM when defining the pipeline.'

When I create a new pipeline job I don't see an option 'Pipeline script from 
SCM'.

How can I specify that the script is to be retrieved from SCM (I am using 
subversion) ?

Best regards

David

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

BlueOcean: missing visual pipeline editor

[Ramanathan Muthaiah]

Hello,

In the BlueOcean UI, I chose Git and provided the repo name hosted within 
organization umbrella. However, with this choice, visual pipeline editor is 
not visible.

Does anyone why is this and what am missing ?

/Ram

-- 
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/054bdf78-ad12-4825-860a-a5dc84c9e642%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Scripts not permitted to use staticMethod in Extensible Choice System Groovy

[Victor Martinez]

It seems 
the https://wiki.jenkins-ci.org/display/JENKINS/Script+Security+Plugin has 
been installed and enabled, therefore you need to whitelist those methods. 
Or even using 
the 
https://wiki.jenkins-ci.org/display/JENKINS/Permissive+Script+Security+Plugin 
plugin in case you would like to grant access to all those internal methods.

Cheers

On Friday, 21 April 2017 01:09:54 UTC+1, Victoria Kozel wrote:
>
> Hello,
>
> I am writing a simple groovy script to display role-based choices in the 
> Extensible Choice. I get 
>
> org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts 
> not permitted to use staticMethod jenkins.model.Jenkins getInstance
>
>
> when calling 
>
>
> def authStrategy = Jenkins.instance.getAuthorizationStrategy()
>
>
> I am not sure I understand the reason for this, but my question is - Is there 
> a workaround for this error?
>
>
> Thank you!!
>
> Vicki
>
>

-- 
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/5d8b5c6f-660d-4be2-8e85-dfdc4218fa81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Blue Ocean - Page not found

[Dan Tran]

looks like i found it https://issues.jenkins-ci.org/browse/JENKINS-41500

>
>

-- 
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/34b2fb71-738a-4b40-8909-986cfc523f33%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Blue Ocean - Page not found

[Dan Tran]

My Blue Ocean button pops me the below dialog.

Page not found (404)
Jenkins could not find the page you were looking for. Check the URL for 
errors or press the back button.
Open Dashboard 


Is there a way to fix this?

Thanks

-Dan


-- 
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/94d1fa28-1755-4c0f-bb3c-389ae53e0ce9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.