Re: Proposal: Emeritus maintainers

[Stephen Connolly]

On Monday, 2 March 2020 12:56:10 UTC, Daniel Beck wrote:
>
>
>
> On Mon, Mar 2, 2020 at 1:50 PM Stephen Connolly  > wrote:
>
>>
>> Similarly, if I come back in 2 years and see that Bob who adopted the 
>> foobar plugin from me has done nothing with it in the past year... should I 
>> need to wait for bob's timeout of two weeks to pick up the plugin?
>>
>> For sure if Bob is maintaining the plugin actively and has commits etc 
>> then Bob should be respected... but if Bob is don;t nothing and hasn't 
>> moved himself to Emeritus, should he be entitled to block me from picking 
>> the plugin back up?\
>>
>
> This all makes sense in a way, but then we get to choose between a really 
> complex decision tree (what even counts as actively maintained?), or just 
> improvising every time (i.e. have a vaguely defined judgment call in there 
> somewhere).
>
>
I'm fine with "have a vaguely defined judgment call in there somewhere" for 
whether Emeritus gets fast track or not in the presence of active 
maintainers.

The important part for me is that I don't have to worry in the case that 
the plugin is not actively maintained

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/12bd482f-cc57-420c-b02b-9d3d6e55f151%40googlegroups.com.

Re: Proposal: Emeritus maintainers

[Stephen Connolly]

On Monday, 2 March 2020 12:47:35 UTC, Stephen Connolly wrote:
>
>
>
> On Monday, 2 March 2020 12:44:37 UTC, Baptiste Mathus wrote:
>>
>>
>>
>> Le lun. 2 mars 2020 à 13:40, Stephen Connolly  a 
>> écrit :
>>
>>>
>>>
>>> On Monday, 2 March 2020 11:19:07 UTC, Daniel Beck wrote:
>>>>
>>>>
>>>>
>>>> On Mon, Mar 2, 2020 at 12:02 PM Stephen Connolly <
>>>> stephen.a...@gmail.com> wrote:
>>>>
>>>>> If all maintainers of a plugin are emeritus and someone wants to claim 
>>>>> ownership then the emeritus maintainers can short-circuit the transfer of 
>>>>> ownership rather than having to wait out the full period.
>>>>>
>>>>
>>>> Seems like this can trivially be accomplished by amending the usual 
>>>> adoption process (2 week timeout) to special-case "I used to maintain 
>>>> this". We've actually done that already in the past, when the last release 
>>>> pre-dated the cutoff date I used to initialize the permission files: The 
>>>> requester told us they maintained the plugin back 2012, they'd like to get 
>>>> permissions back. Nobody else was around to tell us "no" (i.e. no other 
>>>> co-maintainers recorded), so it was just done.
>>>>
>>>> My main question here is how this would impact plugins with active 
>>>> maintainers. If you remove yourself from credentials plugin, it is 
>>>> currently considered to be maintained jointly by seven people. Do you 
>>>> expect to get permissions back without any approval from any of them, if 
>>>> you decide to?
>>>>
>>>
>>> If there are active maintainers, they can veto within a fixed period of 
>>> time (say 72h or 1 week or whatever people want), but I think it would have 
>>> to be a veto not an approval. 
>>>
>>
>> Overall +1 with a strong concern from my side on the 'new and active 
>> maintainers' respect aspect.
>>
>> I think this is fine to move into a fast-forwardable veto system, however 
>> only taking in account a duration.
>> E.g. such "emeritus" maintainers would be able to get access back in a 
>> fast-track way only if they can show an activity in the last 12 months.
>> IOW I do not think someone who was not active in the last, say, 2 years 
>> should be able to get access back in less than the default timeout of 2 
>> weeks.
>>
>
> If that is scoped to actively maintained plugins, fine.
>

Similarly, if I come back in 2 years and see that Bob who adopted the 
foobar plugin from me has done nothing with it in the past year... should I 
need to wait for bob's timeout of two weeks to pick up the plugin?

For sure if Bob is maintaining the plugin actively and has commits etc then 
Bob should be respected... but if Bob is don;t nothing and hasn't moved 
himself to Emeritus, should he be entitled to block me from picking the 
plugin back up?\


> If the plugin is unmaintained an an emeritus maintainer steps up, they 
> should be back in action as soon as they request it IMHO
>
>  
>>
>>> -- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to jenkin...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/jenkinsci-dev/cb6de16c-7621-4244-a373-12dbbb62cd4c%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/cb6de16c-7621-4244-a373-12dbbb62cd4c%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/fd1e13c4-27c3-4672-b7f7-e6c03e42dece%40googlegroups.com.

Re: Proposal: Emeritus maintainers

[Stephen Connolly]

On Monday, 2 March 2020 12:44:37 UTC, Baptiste Mathus wrote:
>
>
>
> Le lun. 2 mars 2020 à 13:40, Stephen Connolly  > a écrit :
>
>>
>>
>> On Monday, 2 March 2020 11:19:07 UTC, Daniel Beck wrote:
>>>
>>>
>>>
>>> On Mon, Mar 2, 2020 at 12:02 PM Stephen Connolly  
>>> wrote:
>>>
>>>> If all maintainers of a plugin are emeritus and someone wants to claim 
>>>> ownership then the emeritus maintainers can short-circuit the transfer of 
>>>> ownership rather than having to wait out the full period.
>>>>
>>>
>>> Seems like this can trivially be accomplished by amending the usual 
>>> adoption process (2 week timeout) to special-case "I used to maintain 
>>> this". We've actually done that already in the past, when the last release 
>>> pre-dated the cutoff date I used to initialize the permission files: The 
>>> requester told us they maintained the plugin back 2012, they'd like to get 
>>> permissions back. Nobody else was around to tell us "no" (i.e. no other 
>>> co-maintainers recorded), so it was just done.
>>>
>>> My main question here is how this would impact plugins with active 
>>> maintainers. If you remove yourself from credentials plugin, it is 
>>> currently considered to be maintained jointly by seven people. Do you 
>>> expect to get permissions back without any approval from any of them, if 
>>> you decide to?
>>>
>>
>> If there are active maintainers, they can veto within a fixed period of 
>> time (say 72h or 1 week or whatever people want), but I think it would have 
>> to be a veto not an approval. 
>>
>
> Overall +1 with a strong concern from my side on the 'new and active 
> maintainers' respect aspect.
>
> I think this is fine to move into a fast-forwardable veto system, however 
> only taking in account a duration.
> E.g. such "emeritus" maintainers would be able to get access back in a 
> fast-track way only if they can show an activity in the last 12 months.
> IOW I do not think someone who was not active in the last, say, 2 years 
> should be able to get access back in less than the default timeout of 2 
> weeks.
>

If that is scoped to actively maintained plugins, fine.

If the plugin is unmaintained an an emeritus maintainer steps up, they 
should be back in action as soon as they request it IMHO

 
>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkin...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/cb6de16c-7621-4244-a373-12dbbb62cd4c%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/cb6de16c-7621-4244-a373-12dbbb62cd4c%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/44e2491c-2e26-4b37-b350-c6805d5e5b0f%40googlegroups.com.

Re: Proposal: Emeritus maintainers

[Stephen Connolly]

On Monday, 2 March 2020 11:19:07 UTC, Daniel Beck wrote:
>
>
>
> On Mon, Mar 2, 2020 at 12:02 PM Stephen Connolly  > wrote:
>
>> If all maintainers of a plugin are emeritus and someone wants to claim 
>> ownership then the emeritus maintainers can short-circuit the transfer of 
>> ownership rather than having to wait out the full period.
>>
>
> Seems like this can trivially be accomplished by amending the usual 
> adoption process (2 week timeout) to special-case "I used to maintain 
> this". We've actually done that already in the past, when the last release 
> pre-dated the cutoff date I used to initialize the permission files: The 
> requester told us they maintained the plugin back 2012, they'd like to get 
> permissions back. Nobody else was around to tell us "no" (i.e. no other 
> co-maintainers recorded), so it was just done.
>
> My main question here is how this would impact plugins with active 
> maintainers. If you remove yourself from credentials plugin, it is 
> currently considered to be maintained jointly by seven people. Do you 
> expect to get permissions back without any approval from any of them, if 
> you decide to?
>

If there are active maintainers, they can veto within a fixed period of 
time (say 72h or 1 week or whatever people want), but I think it would have 
to be a veto not an approval. 

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/cb6de16c-7621-4244-a373-12dbbb62cd4c%40googlegroups.com.

Re: Proposal: Emeritus maintainers

[Stephen Connolly]

On Monday, 2 March 2020 11:10:23 UTC, Oleg Nenashev wrote:
>
> I think it would be a great improvement to the current process. Maybe it 
> is better to add a new list to repository-permissions-updater 
> <https://github.com/jenkins-infra/repository-permissions-updater/> files 
> so that we can somehow credit the emeritus maintainers on the plugin site 
> once https://issues.jenkins-ci.org/browse/WEBSITE-658 is implemented 
> ("Use Repository Permission Updater as a source of the maintainer info").
>

Seems fine by me, though my proposal was limited to not actually requiring 
code changes so that it could be implemented quickly for my use case :-P


> In my case I also have several plugins which I de-facto maintain as 
> "emeritus maintainer" (read as: "I step in when something is really broken 
> there, but do not maintain it on a regular basis").
> Maybe it is a use-case for emeritus maintainers retaining their release 
> permissions.
>

I am fine with retaining release permissions as emeritus, *at least for the 
case where all maintainers are emeritus* but I think it would be better for 
the active maintainers that they not have to worry about emeritus 
maintainers coming in and releaseing stuff that they are not actively 
tracking.

To me, it is more about tracking that you can help if necessary, while 
signalling the intent to step back.


> P.S: It might be also good to explicitly mark plugins for adoption. Now it 
> can be done by just setting a GitHub topic: 
> https://jenkins.io/doc/developer/plugin-governance/adopt-a-plugin/
>
> BR, Oleg
>
> On Monday, March 2, 2020 at 12:06:21 PM UTC+1, Marky Jackson wrote:
>>
>> I like this idea so a +1 from me.
>>
>>
>> On Mar 2, 2020, at 3:02 AM, Stephen Connolly  
>> wrote:
>>
>> 
>> Can we add a concept of emeritus maintainer... by just commenting out 
>> their username in the corresponding repository-permissions-updater yaml 
>> file?
>>
>> An emeritus maintainer would be indicating that they are no longer 
>> active, but if they want to re-activate they do not need to wait for 
>> existing maintainers to approve... or in the case of unmaintained plugins 
>> they do not need to wait for the claim-ownership period.
>>
>> If all maintainers of a plugin are emeritus and someone wants to claim 
>> ownership then the emeritus maintainers can short-circuit the transfer of 
>> ownership rather than having to wait out the full period.
>>
>> My use case is that I currently wish to be marked emeritus for all 
>> plugins that I am a maintainer of *except*:
>>
>> - gitea (until I get the gitea token auth implemented, then I'll be 
>> looking for someone to adopt it)
>> - impersonation (until I decide whether to release it or kill it)
>> - mock-load-builder (needed for work commitments)
>> - random-job-builder (needed for work commitments)
>> - metrics (needed for work commitments)
>>
>> I may need to step back on the other plugins at shorter notice, so it 
>> would be annoying to have to go though recovering maintainer status... 
>> which is why I have not dropped those permissions.
>>
>> I do think we need to be able to reflect better the case where 
>> maintainers are not actively maintaining but do not want to drop 
>> permissions because it could trigger the plugin as completely unmaintained 
>> and thus a lot harder to reclaim... yet by not dropping permissions it 
>> leaves others who might be interested in adopting the impression that the 
>> plugin is actively maintained
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkin...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw0XFtd1PR00yuhJJ-q8B0s6LqHK%3DResjH8P%3Di%3DJ%2B-MTw%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw0XFtd1PR00yuhJJ-q8B0s6LqHK%3DResjH8P%3Di%3DJ%2B-MTw%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/e321ca52-5fd6-45c6-8078-1f7f5c07ffa9%40googlegroups.com.

Proposal: Emeritus maintainers

[Stephen Connolly]

Can we add a concept of emeritus maintainer... by just commenting out their
username in the corresponding repository-permissions-updater yaml file?

An emeritus maintainer would be indicating that they are no longer active,
but if they want to re-activate they do not need to wait for existing
maintainers to approve... or in the case of unmaintained plugins they do
not need to wait for the claim-ownership period.

If all maintainers of a plugin are emeritus and someone wants to claim
ownership then the emeritus maintainers can short-circuit the transfer of
ownership rather than having to wait out the full period.

My use case is that I currently wish to be marked emeritus for all plugins
that I am a maintainer of *except*:

- gitea (until I get the gitea token auth implemented, then I'll be looking
for someone to adopt it)
- impersonation (until I decide whether to release it or kill it)
- mock-load-builder (needed for work commitments)
- random-job-builder (needed for work commitments)
- metrics (needed for work commitments)

I may need to step back on the other plugins at shorter notice, so it would
be annoying to have to go though recovering maintainer status... which is
why I have not dropped those permissions.

I do think we need to be able to reflect better the case where maintainers
are not actively maintaining but do not want to drop permissions because it
could trigger the plugin as completely unmaintained and thus a lot harder
to reclaim... yet by not dropping permissions it leaves others who might be
interested in adopting the impression that the plugin is actively maintained

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw0XFtd1PR00yuhJJ-q8B0s6LqHK%3DResjH8P%3Di%3DJ%2B-MTw%40mail.gmail.com.

Re: Replace authorize-project-plugin

[Stephen Connolly]

On Tuesday, 27 August 2019 09:16:40 UTC+1, ikedam wrote:
>
> Hi, 
>
> I’m Ikedam,  a maintainer of authorize-project-plugin. 
> https://plugins.jenkins.io/authorize-project 
>
> Authorize-project-plugin doesn’t support features of modern Jenkins, such 
> as pipelines, multibranch and JCaC. 
> Making things worse, authorize-project-plugin is the only implementation 
> for QueueItemAuthenticator as far as I know. 
>
> Authorize-project-plugin is originally designed for legacy Jenkins, that 
> is, expected to use with freestyle projects and matrix projects, and 
> expected to configured with web browsers. And I believe it’s fundamentally 
> incompatible with modern Jenkins. 
>
> It might be possible to extend or redesign this plugin and to have it 
> applicable to modern Jenkins, but I’m afraid that it’s not reasonable as it 
> mainly costs not for new features, but rather for preserving backward 
> compatibilities. 
>
> What I want to do here are: 
>
> * Request a new plugin implementing QueueItemAuthenticator, supporting 
> modern Jenkins and which will replace and deprecate 
>  authorize-project-plugin. 
> * Unfortunately I won’t join that development. Sorry. 
>
> * Ask depelopers whether QueueItemAuthenticator is what we actually want, 
> or there can be alternate ways to control permissions of builds: 
> * I originally developed authorize-project-plugin for 
> copyartifact-plugin to control the permission to copy artifacts from other 
> builds. But I believe it’s easier to control that permission with 
> CopyArtifactPermissionProperty, which defines jobs allowed to access to 
> artifacts. 
> * I believe users want to define permissions not bound to actual 
> specific users such as those in LDAP, or Active Directory. But Jenkins 
> doesn’t provide mechanisms for authentications not bound to specific users, 
> like sevice accounts in Google Cloud Platform. 
>

So if you use the https://github.com/jenkinsci/impersonation-plugin that I 
wrote *but never actually got around to releasing* that will let a user 
impersonate any LDAP group they are a member of... then you can configure 
credentials and builds to run as that group... that way other users in the 
same group can configure etc.

It's not service accounts, but it is very close... otoh it requires a 
security realm with groups (e.g. LDAP or ActiveDirectory)
 

> * I expect QueueItemAuthenticator can be replaced with other 
> permission mechanisms not bound to specific users, like permissions between 
> jobs (generalizing CopyArtifactPermissionProperty) or permissions for 
> credentials from jobs (folder-scoped credentials might meet that). 
> * I don’t know actual usecases of QueueItemAuthenticatorcan and there 
> might be usecases that cannot be replaced with other mechanisms. 
>
> Regards, 
> Ikedam 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/6476f25d-197e-46e8-a2a4-02c087170497%40googlegroups.com.

Re: Looking to help maintain credentials plugin

[Stephen Connolly]

Conditional on getting *API* and *SPI* changes reviewed by me, +1. Once
you've demonstrated confidence on evolution of the API & SPI I'll be
overjoyed to release my veto, but as a critical plugin I believe it would
be remiss on my behalf to not supervise a transition.

Changes that do not affect either the API or the SPI method signatures, go
for it!

On Mon, 24 Jun 2019 at 15:29, Matt Sicker  wrote:

> It's hard for me to send this email, but yes, I'd like to help
> maintain this plugin. I've been working on some improvements to the
> user-scoped credentials features lately, and this plugin falls into my
> general category of security-related plugins that I've been working
> with more frequently.
>
> --
> Matt Sicker
> Senior Software Engineer, CloudBees
>


-- 
*Stephen Connolly*
Principal Software Engineer
CloudBees, Inc.

[image: CloudBees-Logo.png] <http://www.cloudbees.com>
E: sconno...@cloudbees.com
Twitter: @connolly_s <https://twitter.com/connolly_s>

<https://cloudbees.com/devops-world/san-francisco>
<https://cloudbees.com/devops-world/san-francisco>
DevOps World | Jenkins World
<https://cloudbees.com/devops-world/san-francisco>
August 12-15 :: San Francisco, CA
December 2-5 :: Lisbon, Portugal
*Use promotional code CBPROD20 to get a 20% discount*

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

Re: Third party dependencies, APIs, and Jenkins: Proposals

[Stephen Connolly]

On Wed 10 Apr 2019 at 21:55, Jesse Glick  wrote:

> On Wed, Apr 10, 2019 at 10:48 AM Matt Sicker 
> wrote:
> > 1. Shade in third party dependencies of Jenkins core into Jenkins with
> > a package rename. This will allow core to use the dependencies, but
> > plugins will still need to include the dependencies explicitly. This
> > could potentially be combined with a compatibility shim for plugins
> > that try to load a class that doesn't exist.
>
> You do not necessarily need to rename packages. It suffices for the
> plugin class loader defined in Jenkins core to decline to forward
> class loading requests for these libraries to the parent. (The
> implementation already exists to some extent, in the
> `pluginFirstClassLoader` option, but this is too extreme because it
> applies to _all_ class loads whereas we only want to decline certain
> names.) Combined with the existing detached plugin system for backward
> compatibility, you have a complete runtime solution, and rather easily
> at that.
>
> The problems are in the developer tooling. `compiler:compile` and
> `JenkinsRule` via `surefire:test` are going to pick up transitive
> dependencies of `jenkins-core` in a flat classpath. Thus if a plugin
> built against a new core baseline (one after the change) _does_
> declare an explicit dependency on the new library wrapper plugin,
> Maven will pick one or the other version to build & test against
> (depending on POM details of where this dependency appears in the tree
> relative to `jenkins-core`); if it does _not_, Maven will silently
> build & test against the library as bundled in core, even though at
> runtime this would be a `NoClassDefFoundError`. These problems make me
> think that shading is more practical.


If the “classboxed” dependencies have scope=provided then they shouldn’t be
transitive and you could leave them unshaded.

The JenkinsRule would just need to setup the classloaders from the war and
all would be fine

>
>
> > 4.alt. I don't know enough about JPMS, but perhaps it can be used to
> > help enforce something similar?
>
> Last I checked it was much less flexible than what we already have in
> Jenkins core, so it would be hard to migrate to. (Requiring Java 11+
> would be the least of our worries.)
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr285%2Bc7FnDwmes-H5T04kNX%2BhP5z_8JkY2heHYH_VXhzw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: Proposal: AWS Secrets Manager Credentials Provider plugin

[Stephen Connolly]

On Tue, 9 Apr 2019 at 11:57, Chris Kilding 
wrote:

> Hi Stephen,
>
> When I started building the plugin my basis was a combination of your
> guide and the Kubernetes Credentials Provider.
>
> The following sections of your guide were particularly valuable right from
> the start of development:
>
> - The caching strategy guide for remote credentials providers (cache
> metadata for N minutes, retrieve secret data live).
> - “Implementing a new Credentials type” (when and how to extend the
> standard types properly, when to make a new type).
>
> I’m finding the guide is becoming more understandable (and I can get more
> out of it) now I’ve learned the basic architecture of Jenkins plugins. In
> the beginning it’s easier to work off an existing plugin’s code, but now I
> can read more of your guide and see implementation mistakes that need to be
> corrected.
>
> Much like any other technical manual, its utility for the reader increases
> with the reader’s knowledge of the subject. Many thanks for writing it :)
>

Glad to hear. I wasn't happy moving my focus away from Jenkins plugins
without leaving guides to the community for the stuff I believe to be
important (credentials and scm-api). I am glad you have found (and are
still finding) utility in the content. Feel free to create PRs with any
suggested improvements as I am paying attention... just not as frequently
;-)

- Stephen


>
> Chris
>
> On Mon, 8 Apr 2019, at 8:00 PM, Stephen Connolly wrote:
>
> It would be great to get any feedback on the docs I left for writing such
> things:
>
> https://github.com/jenkinsci/credentials-plugin/blob/master/docs/implementation.adoc#implementing-a-new-credentialsprovider
>
> On Thu 4 Apr 2019 at 17:10, Chris Kilding 
> wrote:
>
>
> Hi,
>
> That sounds good - we’re happy to host in jenkinsci and make the plugin
> available through the built-in Jenkins plugin manager.
>
> As Jesse suggested we did indeed base our plugin on the Kubernetes
> credentials provider.
>
> Would we be able to do it all in a single Github repo inside the jenkinsci
> org? Or would we have to run a separate upstream repo in our own Github
> account, with a fork under jenkinsci? (We’d prefer to go with the first
> option and cut out the middleman, if that makes sense.)
>
> On Thu, 4 Apr 2019, at 4:51 PM, Daniel Beck wrote:
>
> Can't wait to check this out. Thanks for publishing it!
>
> > On 4. Apr 2019, at 16:21, Chris Kilding 
> wrote:
> >
> > We’re initially thinking it should be a Github repo under the
> ‘jenkinsci’ or ‘aws’ organisations, with our own engineers added to that
> repo as external collaborators. (These would seem to be the most natural
> homes for the plugin.) But we’re open to other suggestions :)
>
> We require that plugins distributed by the Jenkins project be hosted in
> the jenkinsci organization (with some exceptions grandfathered in). So if
> you want to make it as easy as possible to install with the built-in plugin
> manager, I would recommend you host in jenkinsci.
>
> Docs for this (these largely superseded the wiki):
> https://jenkins.io/doc/developer/publishing/requesting-hosting/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/4EDC20FF-07B6-4041-86F1-2FB8F547EE61%40beckweb.net
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/e5245e90-3492-4276-b3a4-fd220f71f45c%40www.fastmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/e5245e90-3492-4276-b3a4-fd220f71f45c%40www.fastmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
> --
> Sent from my phone
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMyBm9uqmYtsGePbNKi5n1AFmtWt03kffLonXnogyZd%3DUw%40mail.gmail.com
> <htt

Re: Proposal: AWS Secrets Manager Credentials Provider plugin

[Stephen Connolly]

It would be great to get any feedback on the docs I left for writing such
things:
https://github.com/jenkinsci/credentials-plugin/blob/master/docs/implementation.adoc#implementing-a-new-credentialsprovider

On Thu 4 Apr 2019 at 17:10, Chris Kilding 
wrote:

> Hi,
>
> That sounds good - we’re happy to host in jenkinsci and make the plugin
> available through the built-in Jenkins plugin manager.
>
> As Jesse suggested we did indeed base our plugin on the Kubernetes
> credentials provider.
>
> Would we be able to do it all in a single Github repo inside the jenkinsci
> org? Or would we have to run a separate upstream repo in our own Github
> account, with a fork under jenkinsci? (We’d prefer to go with the first
> option and cut out the middleman, if that makes sense.)
>
> On Thu, 4 Apr 2019, at 4:51 PM, Daniel Beck wrote:
>
> Can't wait to check this out. Thanks for publishing it!
>
> > On 4. Apr 2019, at 16:21, Chris Kilding 
> wrote:
> >
> > We’re initially thinking it should be a Github repo under the
> ‘jenkinsci’ or ‘aws’ organisations, with our own engineers added to that
> repo as external collaborators. (These would seem to be the most natural
> homes for the plugin.) But we’re open to other suggestions :)
>
> We require that plugins distributed by the Jenkins project be hosted in
> the jenkinsci organization (with some exceptions grandfathered in). So if
> you want to make it as easy as possible to install with the built-in plugin
> manager, I would recommend you host in jenkinsci.
>
> Docs for this (these largely superseded the wiki):
> https://jenkins.io/doc/developer/publishing/requesting-hosting/
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/4EDC20FF-07B6-4041-86F1-2FB8F547EE61%40beckweb.net
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/e5245e90-3492-4276-b3a4-fd220f71f45c%40www.fastmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: Why did Multiple SCMs Plugin get deprecated?

[Stephen Connolly]

ResolveSCM is for the use case where you want to checkout a matching branch
name in another repo... but fallback to other branches of it doesn’t exist.

Eg Apache Maven uses it so that you can add a feature to Core (main git
repo) and add integration tests (side git repo) and test them both in the
same build.

HTH

On Mon 1 Apr 2019 at 21:09, Martin Weber  wrote:

> Am Mittwoch, 27. März 2019, 21:35:44 CEST schrieb Mark Waite:
> > On Wed, Mar 27, 2019 at 2:02 PM Martin Weber  wrote:
> > > Am Dienstag, 13. November 2018, 20:40:41 CET schrieb Jesse Glick:
> > > > On Sat, Nov 10, 2018 at 12:12 PM Martin Weber 
> > >
> > > wrote:
> > > > > Pipeline offers a *different* way of checking out multiple
> > > > > SCMs. With the same branch seen in several SCMs, Pipeline only
> checks
> > >
> > > out
> > >
> > > > > the branch from the *first SCM* only.
> > > > >
> > > > > In contrast, Multiple SCMs Plugin checks out a branch from *each
> SCM*
> > >
> > > in
> > >
> > > > > parallel.
> > > >
> > > > Daniel’s response, as well as the phrasing of the initial question,
> > > > are mixing up two very different things: multibranch projects and
> > > > plain projects. `multiple-scms` addresses a limitation in plain
> > > > (freestyle) projects that you could not have multiple SCM checkouts
> in
> > > > your workspace. This is trivially addressed in (plain) Pipeline
> > > > projects simply by doing something like
> > > >
> > > > dir('first-repo') {
> > > >
> > > >   git 'http://git/first-repo'
> > > >
> > > > }
> > > > dir('second-repo') {
> > > >
> > > >   git 'http://git/second-repo'
> > > >
> > > > }
> > >
> > > Thanks, finally I got it working!
> > > Just for the records; here is what I did (The documentation of
> resolveScm
> > > is
> > > not very helpful and the snippet generator does not help much here)
> >
> > I think you may find it easier to use checkout without using resolveScm.
> > Can you help me understand why you chose to use resolveScm?
>
> D. Beck suggested that earlier in this thread.
>
> >
> > See the following examples for multiple checkouts in a single
> Jenkinsfile.
> >
> >
> https://github.com/MarkEWaite/jenkins-bugs/blob/JENKINS-43198/Jenkinsfile
> >
> https://github.com/MarkEWaite/jenkins-bugs/blob/JENKINS-47874/Jenkinsfile
>
> Hmmh, do these examples really monitor different SCMs for changes and
> trigger
> a build?
>
> Anyway, thanks for your response.
>
> Martin
>
> --
> E-Mails sollten Text sein, Text und nur Text.
> Wenn Gott gewollt hätte, dass E-Mails in HTML geschrieben würden,
> endeten Gebete traditionell mit .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/32380527.vBj4gx0osB%40linux
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: openid plugin up for adoption

[Stephen Connolly]

thanks

On Mon, 21 Jan 2019 at 12:08, Baptiste Mathus  wrote:

>
> https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin#AdoptaPlugin-HowcanImarkapluginforadoption
> ?
>
> Marked the plugin as orphaned for you.
> https://wiki.jenkins.io/display/JENKINS/OpenID+plugin
>
> Cheers!
>
> Le lun. 21 janv. 2019 à 12:38, Stephen Connolly <
> stephen.alan.conno...@gmail.com> a écrit :
>
>> I don't know how me cutting a maintenance release resulting from a
>> support ticket for a CloudBees customer many years ago has translated into
>> the illusion that I am maintaining this plugin.
>>
>> It is open for adoption. I am not currently paying sufficient attention
>> to the Jenkins community processes to know what further steps are required.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwigQwuiGD-oidY%2BKid0rMJk3E3%3DH665bx36wb7RUVpCA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwigQwuiGD-oidY%2BKid0rMJk3E3%3DH665bx36wb7RUVpCA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7OJOZcFQOLLPiGA9KCcsgf5_BvZ%3DCkU7rEqwruUkjnig%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS7OJOZcFQOLLPiGA9KCcsgf5_BvZ%3DCkU7rEqwruUkjnig%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

openid plugin up for adoption

[Stephen Connolly]

I don't know how me cutting a maintenance release resulting from a support
ticket for a CloudBees customer many years ago has translated into the
illusion that I am maintaining this plugin.

It is open for adoption. I am not currently paying sufficient attention to
the Jenkins community processes to know what further steps are required.

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

Re: Using Jenkins JIRA to record development priorities for a plugin?

[Stephen Connolly]

On Sun 9 Dec 2018 at 15:35, Mark Waite  wrote:

>
>
> On Sun, Dec 9, 2018 at 8:18 AM Daniel Beck  wrote:
>
>>
>>
>> > On 9. Dec 2018, at 15:34, Mark Waite  wrote:
>> >
>> > Is it allowed to use issues.jenkins-ci.org for that type of tracking?
>> >
>>
>> I don't see why it would not be, or do you need access to features, or
>> plugins installed, that you currently don't have?
>>
>>
> I am not aware of needing anything more than is already available to me.
> However, I haven't tried the experiment yet, so I'm not 100% certain.
>
>
>> FWIW any user can reorder issues on boards ("rank"), or change their
>> priority, so neither is probably a good choice.
>>
>>
> I think that might actually be a positive rather than a negative.  If
> someone is willing to find the board and use it to adjust priority
> settings, I'd like to see their results.  If it were abused, I could always
> keep a local snapshot of the priorities, or place a snapshot in some other
> location.
>

Rank is *global* so if someone has another board and your issues show on
that board too, any rank adjustments will ripple AIUI


>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/5A128BE7-EF96-40DC-9E2D-2A459B0494DD%40beckweb.net
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Thanks!
> Mark Waite
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH3uO4bGPaCbxJEmpJtZ8sn5BYZ5%2BXJ4Jn%3DUB1CuEUePA%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: Detect Matrix Project

[Stephen Connolly]

In the config pages, there will not be a ‘build’ context variable.

What you want is to either check ‘it.descriptor’ as being the matrix
project descriptor or check ‘it’ as being the matrix project class.

But don’t even go there, in your descriptor override ‘isApplicable’ to
return false for matrix project (compare by classname) and you won’t even
need a warning because it will never appear in the list of options in the
first place.

HTH

On Thu 11 Oct 2018 at 05:40, Nikhil Bhoski  wrote:

> Yes , that's correct my descriptor  is
> extending BuildStepDescriptor  is that the reason why i am not
> getting descriptor.getMatrix() is not returning any values in jelly ?
>
> On Wednesday, 10 October 2018 19:55:31 UTC+5:30, Jesse Glick wrote:
>>
>> On Wed, Oct 10, 2018 at 8:57 AM Nikhil Bhoski 
>> wrote:
>> > i have plugin with proper UI elements which will be invoked through
>> build step for all project types including freestyle/Matrix etc . i have
>> intention of supporting it to pipeline as well but its in future .
>> currently my intention is not to support pipeline
>>
>> Are you overriding
>>
>>
>> https://javadoc.jenkins.io/hudson/tasks/BuildStepDescriptor.html#isApplicable-java.lang.Class-
>>
>> ? (This is not used by Pipeline, but you can effectively decline to
>> support Pipeline merely by not implementing `SimpleBuildStep`.)
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/c3dc9400-da34-41e4-a4fa-60a12093%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMx%2BHRavtQL0CEEvpQNk42%2BUTYC7XssuJZY-Ek%2Bm5rf-4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Looking to be added as a maintainer for pam-auth-plugin

[Stephen Connolly]

I have no recollection of ever being a maintainer of that plugin

On Fri, 17 Aug 2018 at 15:51, Matt Sicker  wrote:

> CCing Jesse and Stephen who seem to be the two most active maintainers
> historically for this plugin.
>
> On Fri, Aug 17, 2018 at 6:45 AM Oleg Nenashev 
> wrote:
>
>> Please reach out to the maintainer and get his explicit confirmation in
>> this thread.
>> If you want to request ownership transfer, the process is described here:
>> https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin#AdoptaPlugin-Requestcommitaccess
>>
>> BR, Oleg
>>
>> On Thursday, August 16, 2018 at 9:22:39 PM UTC+2, Matt Sicker wrote:
>>>
>>> I've got an open PR there, and I'd like to be added as a maintainer.
>>>
>>> --
>>> Matt Sicker
>>> Software Engineer, CloudBees
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/66d8deb8-1661-44c9-8efe-c2fdcfbe8cc0%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/66d8deb8-1661-44c9-8efe-c2fdcfbe8cc0%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Matt Sicker
> Software Engineer, CloudBees
>


-- 
*Stephen Connolly*
Software Developer & Architect
CloudBees, Inc.

[image: CloudBees-Logo.png] <http://www.cloudbees.com>
E: sconno...@cloudbees.com
Twitter: @connolly_s <https://twitter.com/connolly_s>

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

Re: Suggestion: versioning the schema for Configuration as Code

[Stephen Connolly]

But I still think you should include the (let’s invent a different name to
show the purpose) meta-schema version

Most likely the meta-schema version will always be 1, but if you ever need
to revise then you will thank Jesse and I for suggesting it.

CaaC has a schema for generating the schema at runtime... this is the
meta-schema... it says things like: Java Maps are represented by , use
the @Symbol as a , etc

That is what the meta-schema version represents. If it changes then you are
saying the way of binding between yaml and runtime (in the general sense)
has changed.

On Tue 15 May 2018 at 19:30, nicolas de loof 
wrote:

> I've added a section on this topic in JEP-201:
> https://github.com/jenkinsci/jep/tree/master/jep/201#versioning
>
> We can already generate a json-schema you can use to validate your yaml
> file(s) before applying configuration.
> What you miss is a tool to convert jenkins-core + plugins.spec -> json
> schema.
> This is something we could package as well (something comparable to
> jenkinsfile-runner) or even provide "as a service".
>
> We could also get such a tool both generate a schema and validate your
> config, as it seems there's not  (yet) so much text editors to support
> json schema validation in yaml
>
> Would this help ?
>
> 2018-05-15 20:19 GMT+02:00 R. Tyler Croy :
>
>> (replies inline)
>>
>> On Tue, 15 May 2018, nicolas de loof wrote:
>>
>> > 2018-05-15 0:20 GMT+02:00 Liam Newman :
>> >
>> > >
>> > > Putting all that aside (as that is not the original point of this
>> thread),
>> > > the original suggestion was to include a version field in the CasC
>> YAML.
>> > > You said it would not work because the version would have to take into
>> > > account the core version and versions of all plugins, otherwise it
>> might
>> > > break. Does that mean the CasC YAML could break _any time_  I upgrade
>> any
>> > > component? Doesn't that rather defeats the purpose of CasC?
>> > >
>> >
>> > Yes indeed. CasC doesn't have it's own model, everything is based on
>> actual
>> > java code discovery at runtime. So upgrading core or any plugin is
>> changing
>> > this model. CasC targets reproducibility and immutability use-cases. If
>> you
>> > want to upgrade anything you need to test it before.
>>
>>
>> Testing of changes between plugin versions was something I had great
>> difficulty
>> with for Groovy-scripting-based configuration, which was much more common
>> prior
>> to Configuration as Code. Do you have suggestions for administrators such
>> as
>> myself on how I might validate that my configuration YAML is
>> correct/applies
>> between any core or plugin upgrades?
>>
>> This gets to the underlying concern I had in mind when starting this
>> thread, as
>> an administrator, how will I know that my configuration applies correctly
>> between any core or plugin upgrades? My initial thought was
>> schema-versioning,
>> but I'm certainly open to other suggestions.
>>
>>
>>
>> Cheers
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/20180515181926.GB3395%40grape.lasagna.io
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJz%3D9BjgA8OA%2B0Sg9HfToF2v5rueuVjHR128o41%3D3cU056g%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: Upcoming JEP for usage of Incrementals repository

[Stephen Connolly]

To be clear, this is a joint response from myself and James


On Wed 16 May 2018 at 12:14, James Nord  wrote:

> So the objection I have is that as it stands in JEP-305 the versions are
> releases and these are expected to be garbage collected.
>
> Anyone also wanting to consume incrementals via a proxy would need to
> write tooling to garbage collect releases and there is also the Maven
> principal that you never garbage collect releases, let alone the impact
> this will have on other pipelines that do canary builds by picking up the
> latest **release** of a artifacts/plugins in order to do bleeding edge
> testing in our pipelines. And that is also discounting the ability once it
> is in our mirror for things to accidentally depend on these releases.
>
> So, in analysing the proposal we believe that you can accomplish this with
> SNAPSHOTS.
> You do not need to use timestamped snapshots (which is the main objection
> in JEP-305) against SNAPSHOTS - you just add -SNAPSHOT on to the end of the
> version you already have (such that 1.7-rc1652.cd45427eb4e2 becomes
> {{1.7-rc1652.cd45427eb4e2-SNAPSHOT}
>
> e.g. the equivalent command to generate the changelist setting becomes:
>
> -Pproduce-incrementals -Dchangelist=-rc$(git rev-list --first-parent
> --count HEAD).$(git rev-parse --short=12 HEAD)-SNAPSHOT
>
> then in the dependencies you depend on the xxx-SNAPSHOT and not the
> timestamped snapshot version which allows the version to be used from the
> local repo cache and not to have to download it from the hosted repo
> (artifaactory etc).
>
> Because the changelist produced starts with the ("-rc" git rev list) it
> becomes monotonically increasing and ends with "-SNAPSHOT" we can garbage
> collect without any additional tooling. Because it ends in -SNAPSHOT it
> will not be picked up by canary builds or have the possibility of being
> included in releases, which will then allow us to include it in the mirror
> by default so there would be no need to change any settings.xml.
>
> If you have a separate artifactory repo to have incremental snapshots then
> you can just scan this repo to find the latest versions for an update
> center. It may be possible in artifactory to also change the "snapshots"
> repo into a group and use routing rules to efficiently serve these whilst
> still maintaining compatability for users deploying snapshots with existing
> settings.
>
>
> The change in the JEP of the version being $(git rev-parse --short=12
> HEAD) to being $(version.removeEnd('-SNAPSHOT')}-rc$(git rev-list
> --first-parent --count HEAD).$(git rev-parse --short=12 HEAD) removed a
> lot of my spider-sense objections... but I think we need to have the
> deployed version include -SNAPSHOT to get something that aligns with the
> semantics of the incrementals repo from a Maven perspective
>
>
> Regards
>
> /James
>
> On Saturday, April 28, 2018 at 2:09:39 AM UTC+1, Jesse Glick wrote:
>
>> A little status update here.
>>
>> On Thu, Apr 19, 2018 at 9:27 AM, Jesse Glick 
>> wrote:
>> > I am working on server-side deployment.
>>
>> Thanks to the boundless patience of Tyler and others, this is live!
>>
>>
>> https://github.com/jenkinsci/pom/blob/master/incrementals.md#usage-in-plugin-poms
>>
>> describes how to get started in a plugin repository;
>>
>> https://github.com/jenkinsci/jenkins/pull/3394
>>
>> would make it work in core.
>>
>> To deploy your patch, just make sure the repository is configured as
>> above, then file a pull request from a repository fork. If build &
>> tests pass, and the PR is up to date with the target branch, the
>> artifacts should be deployed for you, and you will see a commit status
>> check to that effect in the PR.
>>
>> At that point you can use the artifacts as a dependency in any other
>> POM, or download them from Artifactory, or whatever. If you do not
>> care to wait for the CI builder, you can also build equivalent
>> artifacts locally, as described in the guide above.
>>
>> Note: currently commits on branches in the origin repository do not
>> get deployed. This should be fixed once a new Git plugin release is
>> cut and ci.jenkins.io updates to it.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/315af002-b836-4480-b053-beed9d05eacf%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an 

Re: Suggestion: versioning the schema for Configuration as Code

[Stephen Connolly]

On Fri 11 May 2018 at 17:32, Jesse Glick  wrote:

> On Fri, May 11, 2018 at 11:14 AM, nicolas de loof
>  wrote:
> > we discover "jenkins" has a "securityRealm" attribute and some
> > implementation can be used to set this attribute. This directly defines
> the
> > yaml tree. But the codebase has no reference to this structure.
>
> Right. So, again, the version would not be referring to the existence
> or semantics of a `securityRealm` attribute. It would be referring to
> the logic that governs how the `Jenkins.getSecurityRealm()` method is
> mapped to a YAML attribute of that name, and how a particular
> `SecurityRealm` subtype is identified in its value. Now the case of
> the attribute name is pretty simple, of course—JavaBeans naming
> convention—but there can be more subtle cases: handling of symbol
> annotations or lack of them (which already comes up in the handling of
> `ldap` in this example!), collection types, getter/setter/constructor
> type mismatches, handling of secrets¹, convenience aliases, deprecated
> members, and so on.
>
> Experience with the `structs` plugin and its binding to Pipeline
> Script in `workflow-cps` indicates that there are plenty of hard
> problems to solve and it is not uncommon for the surface syntax to
> need to be changed in response. For Pipeline (talking about Scripted
> now) we never had a formal “language version” or anything like that,
> which has caused plenty of headaches trying to maintain compatibility
> with old scripts. I think JCasC will hit analogous issues.
>
>
> ¹Whenever that is actually formalized. As it needs to be, IMO, for
> 1.0—you cannot just say that the Credentials plugin maintainer is
> going to solve this for you.


Yeah, I advise against relying on me to fix schema version problems for you
:-P

>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr23zwVvy3RQxD7F_POsgDZxMtSt2vgM%3DGugGF913RTS%2Bw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: FYI: On naming SCM implementation and extension plugins

[Stephen Connolly]

On Tue 17 Apr 2018 at 17:18, Jesse Glick  wrote:

> On Tue, Apr 17, 2018 at 11:10 AM, Carles Capdevila Tejada
>  wrote:
> > should I change it before into gitblit-scm?
>
> According to the doc, since
>
> https://plugins.jenkins.io/gitblit
>
> does not exist, you should use that.


The doc Jesse is referring to is:
https://github.com/jenkinsci/scm-api-plugin/blob/master/docs/implementation.adoc#naming-your-plugin

On the basis that there is no gitblit plugin currently, use gitblit


>
> > I hope it doesn't
> > prevent users from finding it as its naming deviates
>
> Users will not typically find plugins by `shortName`; rather by
> display name and tags.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0PQm_Gx9kahT_CSxf5BrAKkg36-JhE7%2BiayAgQ5J4S-A%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: Anything wrong with storing expanded plugin data in var cache?

[Stephen Connolly]

I see nothing wrong with it... but I would say that having added the
--pluginroot option myself iirc ;-)

On 24 March 2018 at 00:29, Sam Gleske  wrote:

> I normally store expanded plugin metadata within
> /var/cache/jenkins/plugins similar to how WAR filre metadata is stored in
> /var/cache/jenkins/war.
>
> Is there any particular reason the Jenkins packages don't do this?  Are
> there any drawbacks?  I'm curious if others have any opinions on this.
>
> I've been running Jenkins quite a while like this.
>
> [1]: https://github.com/samrocketman/jenkins-bootstrap-shared/blob/
> 1a409cad89007f56ed36342427b767dd4e88fbd9/packaging/docker/run.sh.in#L38
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/05beb1e5-a824-428c-b980-07a4e343acdc%
> 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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw%2BeDUdC4eGaBDk9k4dA6t7FHhFQv2-%2B8N14SBQZMFzuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multibranch event listener for Github PR labels

[Stephen Connolly]

On Mon 19 Mar 2018 at 08:39, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> On Mon 19 Mar 2018 at 08:13, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>>
>> On Mon 19 Mar 2018 at 00:50, Steven F <stevengfos...@gmail.com> wrote:
>>
>>> I locally modified GHBS to make the constructors for PullRequestSCMHead
>>> and PullRequestSCMRevision public which has seemingly solved the problem.
>>>
>>
>> What did I do in Gitea plugin?
>>
>> If I made the constructor public there, then that’s what we should
>> probably be doing in GitHub/ Bitbucket
>>
>> (Gitea is my “no hacks or legacy migration complexity reference
>> implementation”)
>>
>> So to be clear:
>>
>> 1. You have a filter trait that restricts PRs based on the
>> presence/absence of a number of labels. With that, scanning should work. PR
>> commit updates should work (ie if the PR meets the label criteria and
>> someone updates the commit)
>> 2. You want to have an event listener for PR labelled and unlabelled
>> events. This event listener will return heads with a revision when the PR
>> starts matching the label criteria and heads with a null revision when they
>> stop. All other PR events can continue to be processed as before
>>
>> Ideally you’d allow things like:
>>
>> * only discover PRs labelled with “needs-check”
>> * ignore PRs labelled with “work-in-progress”
>>
>> And a final question, would a BranchBuildStrategy work better (ie
>> discover all PRs but only build one with the matching label criteria) -
>> more asking to see what your use case is
>>
>
> Thinking out loud:
>
> The branch build strategy would allow all PRs to be discovered, but only
> build the ones with the label criteria match. As such, it could miss some
> of the “labelled” and “unlabelled” changes unless the branch revision has
> also changed since last build... need to think that through
>

Ok thought experiment:

PR has label criteria already, revision updated, so because revision !=
last build revision => consult strategy

PR has label criteria and transitions to no label criteria, so no revision
change => no need to rebuild anyway

PR does not have label criteria, revision updated and still no label
criteria. Because revision != last build revision => consult strategy
(which says “no build” because does not meet label criteria)

PR does not have label criteria and transitions to having label criteria.
This is the case where we could have issues... now would we?

If no previous build (should be the normal case) revision != last build
revision => consult strategy

If previous build (because there was a manual build, or the label was
removed & added again): we may have the case where revision == last build
revision, in which case, no build triggered.

So we can lose build events if either the label criteria is broken and
restored without a revision change to the PR or if a manual build of the PR
was triggered *before* the label criteria is established.

Neither case seems particularly worrisome as they are “defensible”...

Though, if the user has configured the Jenkinsfile to behave differently
depending on the labels, the user *may* want to trigger a rebuild on label
change... but perhaps we can address that in branch-api by consulting the
branch build strategies even when the revision matches the last built
revision...

NOTE TO SELF: TL;DR probably do not need to add labels to
PullRequestSCMHead, rather return them as an action from fetchActions...
that would be much less risky for build storms


> Another approach could be to add the labels to the PullRequestSCMHead as a
> mixin. This would make the label info part of the equality contract, so
> changing labels would trigger a rebuild... but would enable categories
> based on PR labels... and a BranchBuildStrategy could suppress the rebuild
> on label change.
>
> In any case, I see a cohort of users who do not want to have PRs that do
> not match the label criteria to even be displayed (even though displaying
> without auto-build would allow manual builds of PRs without label criteria,
> the users may not want the distraction) so I see a SCMFilterTrait and
> corresponding event listener to fill the event gap as a Good Thing™️, but
> we may need think about the other lines of attack for the other cohorts of
> users too!
>
>
>> (I think it would be really cool if you get this enabled as an extension
>> plugin By The Way, and kudos to you)
>>
>> So:
>>
>> * if gitea has public constructors for PR head and revision, please file
>> a PR against GitHub to make constructors public. Mention that this PR is
>> “an enabling 

Re: Multibranch event listener for Github PR labels

[Stephen Connolly]

On Mon 19 Mar 2018 at 08:13, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

>
> On Mon 19 Mar 2018 at 00:50, Steven F <stevengfos...@gmail.com> wrote:
>
>> I locally modified GHBS to make the constructors for PullRequestSCMHead
>> and PullRequestSCMRevision public which has seemingly solved the problem.
>>
>
> What did I do in Gitea plugin?
>
> If I made the constructor public there, then that’s what we should
> probably be doing in GitHub/ Bitbucket
>
> (Gitea is my “no hacks or legacy migration complexity reference
> implementation”)
>
> So to be clear:
>
> 1. You have a filter trait that restricts PRs based on the
> presence/absence of a number of labels. With that, scanning should work. PR
> commit updates should work (ie if the PR meets the label criteria and
> someone updates the commit)
> 2. You want to have an event listener for PR labelled and unlabelled
> events. This event listener will return heads with a revision when the PR
> starts matching the label criteria and heads with a null revision when they
> stop. All other PR events can continue to be processed as before
>
> Ideally you’d allow things like:
>
> * only discover PRs labelled with “needs-check”
> * ignore PRs labelled with “work-in-progress”
>
> And a final question, would a BranchBuildStrategy work better (ie discover
> all PRs but only build one with the matching label criteria) - more asking
> to see what your use case is
>

Thinking out loud:

The branch build strategy would allow all PRs to be discovered, but only
build the ones with the label criteria match. As such, it could miss some
of the “labelled” and “unlabelled” changes unless the branch revision has
also changed since last build... need to think that through

Another approach could be to add the labels to the PullRequestSCMHead as a
mixin. This would make the label info part of the equality contract, so
changing labels would trigger a rebuild... but would enable categories
based on PR labels... and a BranchBuildStrategy could suppress the rebuild
on label change.

In any case, I see a cohort of users who do not want to have PRs that do
not match the label criteria to even be displayed (even though displaying
without auto-build would allow manual builds of PRs without label criteria,
the users may not want the distraction) so I see a SCMFilterTrait and
corresponding event listener to fill the event gap as a Good Thing™️, but
we may need think about the other lines of attack for the other cohorts of
users too!


> (I think it would be really cool if you get this enabled as an extension
> plugin By The Way, and kudos to you)
>
> So:
>
> * if gitea has public constructors for PR head and revision, please file a
> PR against GitHub to make constructors public. Mention that this PR is “an
> enabling change for extension plugin”
> * check that your extension plugin is only filling the event gap (ie
> labelled and unlabelled events) otherwise it will conflict with the other
> events
>
> Really cool feature. Glad the docs helped you. Please file PRs for any
> docs improvements you can think of.
>
>
> It is also correctly scoping the source request to the PR involved in the
>> event. I don't know enough about GHBS to know if exposing these
>> constructors would cause issues though. It seems like the package-private
>> decision was made here
>> <https://github.com/jenkinsci/github-branch-source-plugin/commit/996cd93f9146329c34791b6db4a3e42e6e32c4a8#diff-27ddccdb50cf2a720dcbf7561d45c9edR45>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/c8805fee-82e4-4fbd-861b-586cfae41c58%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/c8805fee-82e4-4fbd-861b-586cfae41c58%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> Sent from my phone
>
-- 
Sent from my phone

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

Re: Multibranch event listener for Github PR labels

[Stephen Connolly]

On Mon 19 Mar 2018 at 00:50, Steven F  wrote:

> I locally modified GHBS to make the constructors for PullRequestSCMHead
> and PullRequestSCMRevision public which has seemingly solved the problem.
>

What did I do in Gitea plugin?

If I made the constructor public there, then that’s what we should probably
be doing in GitHub/ Bitbucket

(Gitea is my “no hacks or legacy migration complexity reference
implementation”)

So to be clear:

1. You have a filter trait that restricts PRs based on the presence/absence
of a number of labels. With that, scanning should work. PR commit updates
should work (ie if the PR meets the label criteria and someone updates the
commit)
2. You want to have an event listener for PR labelled and unlabelled
events. This event listener will return heads with a revision when the PR
starts matching the label criteria and heads with a null revision when they
stop. All other PR events can continue to be processed as before

Ideally you’d allow things like:

* only discover PRs labelled with “needs-check”
* ignore PRs labelled with “work-in-progress”

And a final question, would a BranchBuildStrategy work better (ie discover
all PRs but only build one with the matching label criteria) - more asking
to see what your use case is

(I think it would be really cool if you get this enabled as an extension
plugin By The Way, and kudos to you)

So:

* if gitea has public constructors for PR head and revision, please file a
PR against GitHub to make constructors public. Mention that this PR is “an
enabling change for extension plugin”
* check that your extension plugin is only filling the event gap (ie
labelled and unlabelled events) otherwise it will conflict with the other
events

Really cool feature. Glad the docs helped you. Please file PRs for any docs
improvements you can think of.


It is also correctly scoping the source request to the PR involved in the
> event. I don't know enough about GHBS to know if exposing these
> constructors would cause issues though. It seems like the package-private
> decision was made here
> 
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/c8805fee-82e4-4fbd-861b-586cfae41c58%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: plugin development: add global environment settings

[Stephen Connolly]

On Sat 10 Mar 2018 at 15:04, Daniel Beck  wrote:

>
> > On 9. Mar 2018, at 09:43, Johann  wrote:
> >
> > guys nobody can help me? Should I show some more of my code


Global.jelly is to configure the descriptor rather than the instance

To use global.jelly you need to expose the getters and setters on your
descriptor. Then you need to override the configure method on your
descriptor to parse the submitted json (typically you can just say
something like req.bind(this,json) if you keep your descriptor “simple” and
then call save()... you’ll need to override the descriptor’s constructor to
call load() too)

The more modern alternative is to use the GlobalConfiguration stuff... that
will have you using a regular config.jelly but iirc you still need some
sort of configure(req,json) method to pull the top level in


>
> I think this would be useful.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/720A9221-83C1-4D26-8481-DD55FBC1A0FA%40beckweb.net
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: Trademark sublicense request: CloudBees Jenkins Metrics

[Stephen Connolly]

I personally find that the proposed name could cause confusion with the 
Metrics plugin, however given that the Metrics plugin was developed on 
company time, I feel it would be disingenuous of me to leverage a 
side-effect of being paid to do that development that has resulted in me 
being the maintainer of the plugin in order to apply my personal opinions 
to the same company.

In any case, as an employee of CloudBees, I feel I have to recuse myself 
from the debate.

On Thursday, 8 March 2018 12:46:22 UTC, Oleg Nenashev wrote:
>
> Generally the request looks good to me.
> OTOH it would be great to get feedback from the maintainer of the Metrics 
> Plugin <https://wiki.jenkins.io/display/JENKINS/Metrics+Plugin> (Stephen 
> Connolly?).
> If CloudBees plans to release a "CloudBees Jenkins Metrics Plugin" as a 
> part of this new product, it may cause some confusion.
>
> BR, Oleg
>
> On Wednesday, March 7, 2018 at 5:29:40 PM UTC+1, Kohsuke Kawaguchi wrote:
>>
>> On behalf of CloudBees, I’d like to request the permission to use the 
>> following name that uses ‘Jenkins’ in it:
>>
>>- CloudBees Jenkins Metrics
>>
>> To help people understand how this name is going to be used, let me 
>> describe a bit about the effort for which we’d like to use this name.
>>
>> Back several years ago, we have requested the sublicense to use 
>> ‘CloudBees Jenkins Analytics,’ which was subsequently approved 
>> <https://wiki.jenkins.io/display/JENKINS/Approved+Trademark+Usage>. It 
>> is a feature that is a part of our products. It has evolved since then, and 
>> we’d like to give it a new name to more accurately reflect what it is. 
>>
>> When we look at name approval requests like this, a key criteria is to 
>> make sure it doesn’t create confusion about the origin of the effort. From 
>> that perspective, this name has ‘CloudBees’ clearly in front of it, and it 
>> is consistent with other names that are already approved. The situation and 
>> the considerations that led to the approval of the past requests hasn't 
>> really changed, so I hope the new name doesn’t raise any eyebrows and 
>> result in a smooth approval.
>>
>> I’ve put this up as an agenda for Mar 14th project meeting to be able to 
>> get a decision there. If you have any concerns or objections, please chime 
>> in on this thread prior to the meeting, so that we can address them.
>>
>> -- 
>> Kohsuke Kawaguchi
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/a24547c6-32e1-4a75-9fc9-a1666ef8cf5a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Evergreen packaging for Jenkins Essentials

[Stephen Connolly]

Looks good to me.

My only concern is mixing three VMs in the one container. Python, node and
java... would be nicer if that could be reduced... but ack that it’s
non-trivial to do so

On Wed 7 Feb 2018 at 21:28, R. Tyler Croy  wrote:

> In the same vein as my previous email, I've written up a design document
> which
> outlines the current approach for packaging I intend to use for Jenkins
> Essentials:
>
> https://github.com/jenkinsci/jep/tree/master/jep/301
>
> I think it should be fairly straight-forward and understandable why I'm
> taking
> the approach described, but if there any ambiguity do let me know.
>
> Please take a look at the document and let me know what you think on this
> thread :)
>
>
>
> Cheers
> - 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 Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/20180207212838.ndyahjf7psu5obk2%40blackberry.coupleofllamas.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Eh why are we suggesting such a complex reverse proxy configuration?

[Stephen Connolly]

https://twitter.com/connolly_s/status/961223121981399040

for example, here is a working haproxy configuration without any crazy
rewrite rules:

frontend jenkins
mode http
bind *:80
use_backend jenkins

frontend jenkins-tls
mode https
bind *:443 crt /path/to/server.pem
use_backend jenkins

backend jenkins
mode http
option forwardfor
http-request set-header X-Forwarded-Host %[req.hdr(Host)]
http-request del-header X-Forwarded-Port
http-request set-header X-Forwarded-Proto https if { ssl_fc }
server jenkins jenkins.internal.example.com:8080 check

and that works perfectly fine, no reverse proxy warnings, all urls
generated correctly irrespective of the url you access the reverse proxy
with.

I would love to know why we are pushing much more complex and brittle (and
probably subtly broken... *cough*
https://issues.jenkins-ci.org/browse/JENKINS-44006 and similar *cough*
*cough*

Don't get me started on how complex all the other configurations are for
apache, iis, squid, nginx, etc

I suspect all could be simplified to just set X-Forwarded-Host to the Host
header (and remove any X-Forwarded-Port that evil hacker injected in their
request to the reverse proxy) or parse the Host header and set
X-Forwarded-Host to the parsed requested hostname and X-Forwarded-Port to
the parsed requested port... no rewrite rules... and everyone would be
happy.

Thoughts?

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

[ANN] Basic Branch Build Strategies plugin

[Stephen Connolly]

If you are using Multibranch, you may be interested in:

https://github.com/jenkinsci/basic-branch-build-strategies-plugin

Checkout the documentation:

https://github.com/jenkinsci/basic-branch-build-strategies-plugin/blob/master/docs/user.adoc

This extension plugin will enable things like:

* Not rebuilding PRs if only the target branch changed

* Automatically building tags that were "created" within a specific time
window

If somebody wants to take their hand at implementing
https://issues.jenkins-ci.org/browse/JENKINS-48792 this would be very
welcome. Until there is an implementation of JENKINS-48792 we cannot kill
off https://issues.jenkins-ci.org/browse/JENKINS-47859 and I am not sure
when I will next get a window to code stuff up...

But anyway!

Enjoy (once the release is synced)

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

Re: Calling a DSL extension resulting in error

[Stephen Connolly]

The "I have a created a DSL plugin" at the start of the mail is the hint I
am looking at... now it may be a script approval issue, but that may
actually instead point to a question as to how to annotate a newly
developed extension to mark the script safe methods... or it may be plain
script approval... but we are starting from "I have a created a DSL plugin"

On 3 January 2018 at 09:11, Victor Martinez 
wrote:

> Sorry if I misunderstood this question, but I though that particular
> stacktrace was related to the usage of the script approval process.
>
> Cheers
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/b58a38fc-dc97-40d1-8fe1-75349a0c8005%
> 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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMx-d7RERG0XAGPXs3AMzPvwDuXBqExi0jt%3DP9UnxAtbDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Calling a DSL extension resulting in error

[Stephen Connolly]

On Wed 3 Jan 2018 at 08:24, Victor Martinez 
wrote:

> Please ask to the jenkinsci-users mailing list:
> https://jenkins.io/mailing-lists/
>

The poster is *clearly* asking a question about plugin development.

This is the correct list for that.

The users list is clearly incorrect in that regards


>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/c60356da-ef68-4202-adc5-3c2023004bbc%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: slf4j & TaskListener.getLogger intercept

[Stephen Connolly]

Running build related things in the Jenkins JVM is kind of an anti-pattern
IMHO. Better to fork a JVM that you have complete control over the
classloader, in which case the logging goes to STDOUT and you just pipe
that to the build log

On 18 December 2017 at 20:16, Shaun Thompson  wrote:

> I'm looking to output external logging, API's that use slf4j, to the build
> logs.
>
> On Monday, December 18, 2017 at 8:16:18 AM UTC-6, Jesse Glick wrote:
>>
>> On Sat, Dec 16, 2017 at 2:18 PM, Shaun Thompson 
>> wrote:
>> > intercept logging in a Pipeline
>> > coming from the TaskListener.PrintStream getLogger() for other API's
>> that
>> > are using slf4j.
>>
>> Not sure what you are talking about. Build logs (`TaskListener`) and
>> the system log (`java.util.logging`) are unrelated.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/1a003078-f2a5-4e6d-b42a-782be39da94e%
> 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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMyYHjFTetotjKngHO-hzn0PQNt-%3DmEouk4mK0KKh7RmFw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Adding config when plugin updates

[Stephen Connolly]

What you might need to do is set a flag that signals at least one
readResolve method has assigned an id (or better have a set of newly
assigned ids). Then have a @Initializer that fires after Jobs loaded and it
checks the flag (or set non-empty) and if set then it iterates all jobs
saving ones that have been changed (which is why the set of newly assigned
ids is better because: 1. if the config does not have an id in the set then
skip; 2. remove entries as you save each job and when the set is empty you
can stop without processing all jobs)

On 12 December 2017 at 06:11, Richard Bywater  wrote:

> I'm one step closer with Baptiste's help but I'm still stuck on persisting
> the id once I generate it in the readResolve method. This is necessary as
> its not a default value but instead a random id value that needs to be
> maintained between Jenkins restarts.
>
> Does anyone have an idea about how this is done? I did try calling
> 'getDescriptor.save()' but that doesn't seem to help presumably as this is
> a job level configuration and not the system configuration (although I
> always get confused between Descriptor/Describables/etc.so that is probably
> to be expected :) )
>
> Richard.
>
> On Mon, 11 Dec 2017 at 06:55 Richard Bywater  wrote:
>
>> Great thanks. That's the page I remember seeing a while back but just
>> couldn't find it again :)
>>
>> Richard.
>>
>> On Mon, 11 Dec 2017, 2:19 AM Baptiste Mathus,  wrote:
>>
>>> https://wiki.jenkins.io/display/JENKINS/Hint+on+retaining+backward+
>>> compatibility#Hintonretainingbackwardcompatibility-Scenario:
>>> Addinganewfield ?
>>>
>>> 2017-12-10 4:26 GMT+01:00 Richard Bywater :
>>>
 Hi

 I'm making a change to my plugin that will require all instances of a
 configuration to have a new persistent "id" variable.

 I've dealt with the creation case by having a hidden field and a
 DataBoundConstructor that sees the id is empty and creates one, but I'd
 like all instances of the config to have a id variable added in a similar
 manner when the plugin is updated.

 Is this possible or can this id variable only be added when the
 configuration page is visited and the config re-saved?

 Any pointers to docs or previous threads gratefully received - I've
 hunted around but not been able to use my Google-fu to find anything yet.

 Thanks
 Richard.

 --
 You received this message because you are subscribed to the Google
 Groups "Jenkins Developers" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to jenkinsci-dev+unsubscr...@googlegroups.com.
 To view this discussion on the web visit https://groups.google.com/d/
 msgid/jenkinsci-dev/CAMui9462bD%2BQ81%2B_9Ye%
 2BgAaxQVJcBkwfCCb2OS9%2BqdFLG-%3DS2g%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 Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/jenkinsci-dev/CANWgJS5-KSJ_gqeU3w3wR%
>>> 3DqimH945TLYOTGO5sY9sEBUF3EpNA%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 Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/CAMui947tE8Pp-QL_oidc%3D2g1ep8yGnV9FhtjFGetrYMxZC%
> 3DcMw%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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxBqO9q-e47VpCfmn1Ui9sgsqE3uMJsgfJkpKBQKdYvfA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub MultiBranch building when I create a tag

[Stephen Connolly]

On Sat 9 Dec 2017 at 23:14, Mark Waite  wrote:

> Stephen added tag discovery as a response to user requests.  Building from
> a tag is likely to require different specialized behaviors for different
> users.
>
> Some users won't mind if a tag is built more than once.  Others will want
> ways to reduce the risk that a tag is built more than once, even if the
> Jenkins server is completely reset.  Some users will only want the most
> recent tag.  Other users will want to consider all tags, but only within a
> certain date range.  Other users may want tags only accessible from a
> specific branch or set of branches.  Other users may want to consider only
> tags which have a specific message, or a specific tag name format.
>
> Considering the many varied use cases for building tags, I believe his
> intent is that plugins are the right way to allow users to select which
> special cases they want, without adding all those special cases to a single
> plugin.
>

Mostly correct.

We worked very hard to tame the explosion of checkboxes for everyone’s pet
scenario.

I don’t want to block people’s pet scenarios because they are important to
them, but the 90% of users will not share those specific use-cases.

With extension plugins we let each Jenkins instance only install the
extension plugins they actually need and consequently tame the UI
configuration options presented to users. It cannot be a perfect taming as
some instances may need different strategies for different groups of
users... but it will be better than presenting a wall of checkboxes.

In addition, we can make the testing easier as the core plugin will test
the extension point api against its contract which reduces the untested
surface for the extension plugin. For example with the branch build
strategy, branch-api has tests for all the functionality that a bbs could
do (no bbs, a bbs that says build, a bbs that says don’t build) so when
writing a bbs you just need to verify that it returns true/false for the
appropriate conditions.

Finally, by defining a contract we reduce the plugin upgrade risk, as we
can maintain the original well defined contract as we evolve.

The down-side is discovery of potential traits that could be installed...
but I may have a solution for that... namely if we add a link to a wiki
page that uses confluence tags/labels to list all the extension plugins
that could be installed.

With small extension plugins, they should have very few dependencies, and
hence can be installed without restart in the vast majority of cases...
which lowers the barrier for the Admin-User, who is typically tasked with
forging the path as to how to map Jenkins features to business requirements.

-Stephen


> Mark Waite
>
> On Sat, Dec 9, 2017 at 4:46 PM Ryan Campbell 
> wrote:
>
>> I see that in JENKINS-34395
>>  that we added
>> support for discovering tags. However, I don't see a way to build
>> automatically when a tag is made.
>>
>> According to the release notes
>> ,
>> we see:
>>
>>
>>> If you want tags to build automatically, you will need an extension
>>> plugin for Branch API that implements at least one BranchBuildStrategy,
>>> see AngryBytes/jenkins-build-everything-strategy-plugin
>>>  for
>>> a prototype example of such an extension plugin.
>>
>>
>> Is this the intention going forward? It seems rather awkward to install a
>> plugin for something that should be a checkbox. Do we have plans to come
>> back to this topic?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/f1f83e88-7b95-4f68-b7c1-c20288199750%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 Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtEQ2iLbvZNQtSUWsu-5V-AuFtjE2-9D_Z3JYF4GUVsB7g%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

-- 
You received this message because you 

Re: Removing the Everyone team in the jenkinsci GitHub org

[Stephen Connolly]

On Fri 1 Dec 2017 at 15:49, Daniel Beck  wrote:

>
> > On 29. Nov 2017, at 14:52, Daniel Beck  wrote:
> >
> > Details TBD. I currently plan to make people collaborators with write
> access. This will need to be cleaned up some time in the future, but
> speculatively granting additional permissions (most per-repo teams grant
> admin access) doesn't sit right with me.
>
> The GitHub API currently will always send invitations when adding people
> as collaborators to repositories programmatically, even if they're in the
> org (different from the UI), and even if they already have the same access
> (which replacing 'Everyone' would do). I'm in contact with GitHub support
> about this, but no ETA for this to change.
>
> Based on my previous scan, 182 users would get a total of ~950 invitations
> to repositories (98x1, 24x2, 19x3, 7x5, 34x six or more).
>
> On the one hand, it's spammy, and the invitations don't allow me to
> explain what's going on, so someone not actively reading this list might be
> very confused or concerned.
>
> On the other hand, basically everyone receiving 6+ invitations is either
> really inactive (so can probably be excluded to begin with) or active
> enough to have seen this, and it would allow us to remove permissions from
> inactive accounts by cancelling these invitations after a month or so.
>
> I don't really see an alternative though: Creating non-admin teams for
> each of the affected 494 repos (401 of these with just 1-2 members) doesn't
> look like a good idea either.
>
> In case someone's curious, @jglick wins, with exactly 100 invitations.


Now you’ve got me all competitive... how far was I off Jesse?


>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/DB63E3DA-46EF-4C60-9D99-1F6C9C8D13E7%40beckweb.net
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: [PROPOSAL] Change core logging from Java Utils Logging

[Stephen Connolly]

On Mon 27 Nov 2017 at 22:51, Jesse Glick <jgl...@cloudbees.com> wrote:

> On Wed, Nov 22, 2017 at 2:07 PM, Stephen Connolly
> <stephen.alan.conno...@gmail.com> wrote:
> > there is the logging of incorrect values
>
> I guess this is a concern according to the handler.
> `Logger.log(LogRecord)` calls `Handler.publish` synchronously. And
> typical handlers would then format the message synchronously if they
> log it at all. In Jenkins, the problematic handler is
> `RingBufferLogHandler`, which formats messages asynchronously, or
> rather allows callers such as `Functions.printLogRecordHtml` to do so.
> It could instead call `setMessage` synchronously with the result of
> `SimpleFormatter.formatMessage` (and then call `setParameters(null)`
> to clean up). This would actually have another benefit, even if no one
> ever abused the lambda form: avoiding nasty memory leaks, which I have
> personally encountered.


Or any other user provided handler could have the same issue.

Much better if we just switch to a decent logging framework and be done

>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr2Wxxy5RUatk4E8b80tvPydHUCGP2B-BraFH3ehR-V2Lg%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMyUj-D0_YN34xYUBcR37R%3D1O9tnpmth-DYmM3-25qZBXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: SCM plugin not appearing as SCM option in project configuration

[Stephen Connolly]

On Fri 24 Nov 2017 at 08:13, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

>
> On Fri 24 Nov 2017 at 00:40, José Lamas Ríos <j...@genexus.com> wrote:
>
>> Hi,
>>
>> Newbie here, newbie on Jenkins and even newbie on Java :)
>>
>> I'm trying to write a new SCM plugin.
>>
>> // com.genexus.gxserver/GeneXusServerSCM.java
>> public class GeneXusServerSCM extends SCM implements Serializable{
>>
>> [...]
>>
>> @Override
>> public DescriptorImpl getDescriptor() {
>> return (DescriptorImpl) super.getDescriptor();
>> }
>>
>> @Extension
>> public static class DescriptorImpl extends
>> SCMDescriptor {
>>
>
> Override getDisplayName() and return a name... otherwise it is “invisible”
> and cannot be selected.
>
> Are you following the implementation guide in scm-api
> https://github.com/jenkinsci/scm-api-plugin/blob/master/docs/implementation.adoc
>  because
> if I missed mentioning that it would be great if you could file a PR to
> update the docs
>

The section applicable to this case is “Implementing hudson.scm.SCM”

>
>
>> @Override
>> public boolean isApplicable(Job project) {
>> return true;
>> }
>>
>> public DescriptorImpl() {
>> super(GeneXusServerSCM.class, null);
>> load();
>> }
>>
>> [...]
>>
>> }
>>
>> I can see my plug-in appear as installed on
>> http://localhost:8080/jenkins/pluginManager/installed but don't see it
>> as an option on the Source Code Management section of a project
>> configuration (ie:
>> http://localhost:8080/jenkins/job/GXserverProjectTest/configure).
>>
>> My project includes a config.jelly
>>
>> // com.genexus.gxserver.GeneXusServerSCM/config.jelly
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>>
>> It only includes a simple 'Label' for now, but as I said above it doesn't
>> even appear as an available SCM option ("None" and "Subversion" do appear).
>>
>> I guess I'm missing some very basic thing, I've been looking at SVN and
>> TFS implementations, but couldn't figure it out.
>>
>> Any hint? How does Jenkins gets the list of available SCMs? Do I have a
>> chance to debug that code?
>>
>> Thanks in advance,
>>
>>
>>
>> --
>> JLR
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/a156f150-cd96-4d59-b54e-70d17f7b1963%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/a156f150-cd96-4d59-b54e-70d17f7b1963%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> Sent from my phone
>
-- 
Sent from my phone

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

Re: SCM plugin not appearing as SCM option in project configuration

[Stephen Connolly]

On Fri 24 Nov 2017 at 00:40, José Lamas Ríos  wrote:

> Hi,
>
> Newbie here, newbie on Jenkins and even newbie on Java :)
>
> I'm trying to write a new SCM plugin.
>
> // com.genexus.gxserver/GeneXusServerSCM.java
> public class GeneXusServerSCM extends SCM implements Serializable{
>
> [...]
>
> @Override
> public DescriptorImpl getDescriptor() {
> return (DescriptorImpl) super.getDescriptor();
> }
>
> @Extension
> public static class DescriptorImpl extends
> SCMDescriptor {
>

Override getDisplayName() and return a name... otherwise it is “invisible”
and cannot be selected.

Are you following the implementation guide in scm-api
https://github.com/jenkinsci/scm-api-plugin/blob/master/docs/implementation.adoc
because
if I missed mentioning that it would be great if you could file a PR to
update the docs


> @Override
> public boolean isApplicable(Job project) {
> return true;
> }
>
> public DescriptorImpl() {
> super(GeneXusServerSCM.class, null);
> load();
> }
>
> [...]
>
> }
>
> I can see my plug-in appear as installed on
> http://localhost:8080/jenkins/pluginManager/installed but don't see it as
> an option on the Source Code Management section of a project configuration
> (ie: http://localhost:8080/jenkins/job/GXserverProjectTest/configure).
>
> My project includes a config.jelly
>
> // com.genexus.gxserver.GeneXusServerSCM/config.jelly
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> It only includes a simple 'Label' for now, but as I said above it doesn't
> even appear as an available SCM option ("None" and "Subversion" do appear).
>
> I guess I'm missing some very basic thing, I've been looking at SVN and
> TFS implementations, but couldn't figure it out.
>
> Any hint? How does Jenkins gets the list of available SCMs? Do I have a
> chance to debug that code?
>
> Thanks in advance,
>
>
>
> --
> JLR
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/a156f150-cd96-4d59-b54e-70d17f7b1963%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: [PROPOSAL] Change core logging from Java Utils Logging

[Stephen Connolly]

On Wed 22 Nov 2017 at 17:26, Jesse Glick <jgl...@cloudbees.com> wrote:

> On Mon, Nov 20, 2017 at 10:32 AM, Stephen Connolly
> <stephen.alan.conno...@gmail.com> wrote:
> > log(Level.FINE, ()-> "simple concat " + localVar)
> >
> > is worse when not logging than either of
> >
> > log(Level.FINE, "simple concat {0}", localVar)
> > log(Level.FINE, "simple concat {0}", new Object[]{localVar})
>
> Worth comparing the more interesting case of two or more format
> parameters (when the logger is at INFO+):
>
> fine(() -> local1 + " and " + local2);
>
> vs.
>
> log(Level.FINE, "{0} and {1}", new Object[] {local1, local2});
>
> I.e., the case where the `Object[]` constructor is required if you are
> avoiding lambdas. The last time I checked (very informally!), the
> lambda variant was slower for initial calls, and then became faster
> after a large number of repetitions, presumably due to JIT effects.


Well JMH does many iterations to allow for inclining...

But irrespective of perf there is the logging of incorrect values that a
lambda makes trivial given the action at a distance.


>
> At any rate, my broader question stands. Is there actual evidence for
> a pervasive performance drain in typical Jenkins workloads across a
> large number of call sites caused by suboptimal logging calls? If the
> number of performance-sensitive call sites is moderately small, it is
> far less intrusive to just optimize those (for example, gating with
> `isLoggable`) and move on to some more important work.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr14-fLB-W_iujqR69dWqJWRT3vq_0aSkAPOC7Q-RwjKyQ%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: [PROPOSAL] Change core logging from Java Utils Logging

[Stephen Connolly]

JMH is the micro benchmarking tool.

INDY is invoke dynamic

I have blog posts already published showing that when capturing local
variables,

log(Level.FINE, ()-> "simple concat " + localVar)

is worse when not logging than either of

log(Level.FINE, "simple concat {0}", localVar)
log(Level.FINE, "simple concat {0}", new Object[]{localVar})

If you are using field variables, then INDY does not need to capture state
and the performance is better... *but* you don't want to do that as then
you are logging the state at the point in time when the log message is
being logged not the point in time when the log method was called.

I argue that the

() -> expr

pattern is exceedingly dangerous because of the ease with which you can end
up logging mutable state. In addition it is slower. Please stop promoting
it.

On 20 November 2017 at 14:50, Jesse Glick <jgl...@cloudbees.com> wrote:

> On Fri, Nov 17, 2017 at 10:41 AM, Stephen Connolly
> <stephen.alan.conno...@gmail.com> wrote:
> > JMH says Indy is slower
>
> Sorry, what are “JMH” and “Indy”?
>
> Where is the evidence that there is any actual performance issue in
> production Jenkins installations which is not trivially corrected by a
> change of idiom in a few hot spots? That would justify spending
> engineering time on implementing and testing a significant framework
> change?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/CANfRfr3RL6pU%3DNeNHKJHxWjVuv0aMhfv4tJ6XYVC5
> 0K6T-E1xg%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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMyHNWZiLv0SwhsH5yqo94dCiY0fjnnKPU4GPMfPpoW8qg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Propose a workaround of missing multiple security realm feature

[Stephen Connolly]

On Mon 20 Nov 2017 at 14:10, Daniel Beck <m...@beckweb.net> wrote:

>
> > On 20. Nov 2017, at 10:24, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
> >
> > In group membership is going to be tricky (not impossible) as you will
> need to know which delegate realm the group came from and only match
> against users from that same realm.
> >
> > In general the group support is going to be where you have the worst time
> >
>
> Can probably store the source realm for a user as a UserProperty, and tie
> it to that? Unless the admin enables 'fallback mode' that just checks every
> realm for a user -- but may result in problems from overlapping user names
> if not deliberately selected.
>

Nah... worse than that... most of the critical API calls drop down to
String. :-(


> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/F2C7D297-D671-4423-ADCF-BD01096824E8%40beckweb.net
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: Propose a workaround of missing multiple security realm feature

[Stephen Connolly]

On 18 November 2017 at 14:57,  wrote:

> Jenkins currently does not support multiple security realm.
> However, it should be a reasonable use case that allow both AD / LDAP
> logins for individuals (e.g. developers) and logins local Jenkins' own user
> database for administrative roles (e.g. user maintenance team) and
> emergency situations (e.g. AD server out of work) in a sizable organization.
>
> I have searched the issue list and found the following related / similar
> issues, and no :
> JENKINS-3404 mix LDAP and local Hudson users
> 
> JENKINS-15063 support for multiple security realms with failover
> 
> JENKINS-29162 Jenkins internal user in order to be able to log-in under an
> authentication failure with LDAP AD, ...
> 
>
> Since I have not seen any existing solution such as Jenkins API
> enhancement or new plugin to support multiple security realms, I want to
> kick start the discussion by proposing my workaround idea.
>
> The idea is simple: create a new security realm (composite) which
> delegates methods calls to some chosen security realms (components).
> Here is the prototype: Composite security realm plugin
> 
>
> For the prototype, the following assumptions are made:
> 1. It only supports password-based component security realms.
> 2. The user name collision among different security realms is avoided by
> using the order in the configuration as the precedence.
>

In evaluating the chain, if one delegate realm is off-line, no subsequent
delegate realms can be considered on-line.

In group membership is going to be tricky (not impossible) as you will need
to know which delegate realm the group came from and only match against
users from that same realm.

In general the group support is going to be where you have the worst time


> 3. To avoid account locking because of same user name with different
> passwords in different component security realms, the method 
> SecurityRealm.loadUserByUsername(String
> username) should work properly instead of throwing exception.
>
> Please share your points of view regarding to the workaround, whether it
> is feasible or has fatal issues.
> If you have implemented a more mature private plugin for support of
> multiple security realm and are willing to make it open source, you may
> also post the link of the source code here for discussion.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/7c1b5996-d1af-439a-890d-341514a1ebab%
> 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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxsjw%2BegdcFpa859-_Z0h7DpxOwqWe2zeuAm6MNGT4p3g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] Change core logging from Java Utils Logging

[Stephen Connolly]

On Fri 17 Nov 2017 at 15:34, Jesse Glick  wrote:

> On Fri, Nov 17, 2017 at 8:47 AM, James Nord  wrote:
> > I just found myself having to write a
> > LogRecord to log a paramaterized log with an exception...
>
> LOGGER.log(Level.FINE, ex, () -> "so why did you bother making a
> LogRecord for " + this + " common task?");


JMH says Indy is slower


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

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

[ANN] Credentials Plugin 2.2.0 to require Jenkins 2.60.1+

[Stephen Connolly]

>From http://stats.jenkins.io/pluginversions/credentials.html

28% of people have upgraded credentials to 2.1.16

91% of installations of credentials 2.1.16 are using Jenkins 2.60.1 or newer

It is 2 months since the 2.1.16 release of the credentials plugin. The 72%
of people who have not upgraded to credentials 2.1.16 are more than likely
not feeling the need to upgrade, the plugin works well enough for them.
Consequently, I shall exclude them from my decision on what the baseline
Jenkins requirements are for the next release of the plugin... just because
I release a newer version, does not mean they need to upgrade... as
evidenced by their not upgrading ;-)

My (previously undocumented) 90% threshold has been passed with Jenkins
2.60.1, consequently the Credentials plugin is moving its baseline to 2.60.1

*This is not a debate*, *as maintainer of the plugin I have made the
decision*. If somebody wants to maintain a 2.1.x line and take the work of
back-porting any fixes, I will consider supporting them in that task, but
the time I have will be focused on the 2.2.x line.

Some of the improvements to the credentials API that I want to make require
features of Java 8, hence given that the 90% threshold has been passed, I
am pulling the trigger.

The reason I am sending this announcement is to alert all downstream plugin
developers.

If (after I cut a 2.2.x release) you update your dependency on Credentials
API to 2.2.0 or newer, you will also be moving your Jenkins baseline to
2.60.1+ and your Java baseline version to 8. Please assess the impact to
your users.

An example,
  git, the version that is at least two months old is 3.5.1, the 90%
installation cut-off for git is Jenkins 2.46.1 thus according to my
completely made up decision point (plugin release must be available for at
least 2 months, 90% of users with the plugin installed must be using that
Jenkins version or newer) I would not update the git plugin past Jenkins
2.46.1 just yet... however the month and a half 3.6.0 does currently have
92% of users with Jenkins 2.60.1, so using my measure and assuming that the
december stats follow trend, I would think the git plugin could bump
Jenkins baseline in December... and consequently bump Credentials API
version too...

NOTE: I only co-maintain the git plugin and Mark is probably the decider on
the policy to follow with the git plugin.

I recommend that every plugin developer define their compatibility policy
on their wiki page. I have added my policy for the credentials plugin to
its wiki page:

At least 90% of installations using the most recent version of the plugin
that is at least 2 months old shall be able to upgrade to the latest
version of the plugin.


As a plugin maintainer, the policy you pick is entirely your choice, but I
strongly recommend picking a policy and documenting it as I have done (and
I will be applying the same/similar policy to the other plugins I maintain)

P.S. it may be some time before I cut a 2.2.0 release of credentials... or
it could be quite soon... I have made the decision and I think it fair to
provide warning as early as possible

-Stephen

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

Re: Request for feedback: Jenkins Enhancement Proposal (JEP)

[Stephen Connolly]

animal sniffer could be adapted to assist, for example

On 31 October 2017 at 16:32, Jesse Glick  wrote:

> On Tue, Oct 31, 2017 at 11:43 AM, Robert Sandell 
> wrote:
> > Not having to
> > also browse through potentially thousands of lines of code in one or more
> > PRs
>
> I fully agree that this can be painful; my suggestion was however that
> the list of API changes be mechanically verified in a PR build. Do you
> really trust that a textual JEP has been kept exactly up to date with
> the API spec after dozens of commits? To be a good reviewer you would
> need to double-check the API in the PRs anyway.
>
> As a strawman proposal, suppose that you can optionally add a file to
> the sources of Jenkins core or your plugin which specifies the
> complete expected signature of all `public` and `protected` members in
> the module, in a compact text file. A build-time process would verify
> that the actual signature matches the expected signature. There would
> also be a second file in the same format listing the signature as of
> the last release (perhaps the release profile would enforce that the
> two files are identical?); and a CI build would also verify that the
> current signature is binary-compatible with the previous signature.
>
> Thus if you proposed a PR which added to the API, you would need to
> reflect those changes in the current signature file in order to get a
> passing build, and PR reviewers could easily glance at this part of
> the diff to confirm that the additions are reasonable. If you proposed
> to remove an API (under dire circumstances!), you would delete that
> member from the release signature file, and that would be quite
> apparent in the PR.
>
> AFAICT `clirr-maven-plugin` does not support such a workflow, but I
> believe https://docs.oracle.com/javacomponents/sigtest-3-1/
> user-guide/part1.htm
> would, and there are probably other suitable tools.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/CANfRfr3jndHrP0AeytpGmyBqMu55%
> 3DB8yihfjCrWUr%3DP9oSdS8w%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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMyXpRKg%2BYF0mwVt6YjQE%2BHwHpMB0iP21zD7Q-zUCcsOPw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: My video tutorial series on plugin dev for Jenkins at Apache

[Stephen Connolly]

Actually Hervé Boutemy at Maven was wondering how we (Maven) could use
Jenkins more effectively.

My email description was not doing justice, and I realised that people
needed a new series on plugin development.

Blogs can take a lot of effort to write, plus sometimes it’s better to see
someone solving something going wrong rather than been shown a perfect lit
path...

Hence, live, unscripted and unedited!

Glad to hear you like them!

On Mon 30 Oct 2017 at 20:15, Joseph P <joseph...@gmail.com> wrote:

> Stephen awesome vids :)
>
> Is this another attempt at getting me to implement SCM Source for Accurev?
> :P
> I'll definitely keep a eye out for these videos <3
>
> Once work allows me to focus on Accurev Plugin, sure.
>
>
> Den mandag den 30. oktober 2017 kl. 19.56.36 UTC+1 skrev Stephen Connolly:
>>
>> I’ve been recording a series of (approx 20min) videos focused on getting
>> better usage of Jenkins at Apache.
>>
>> The first episode is live.
>>
>> https://youtu.be/W8BRtJmq_2Y
>>
>> The second is a “double episode” as I wanted to get to an MVP.
>>
>> If you are interested in plugin development you might like the series
>> --
>> Sent from my phone
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/c859b056-f36c-400a-b40d-787c18dc0821%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/c859b056-f36c-400a-b40d-787c18dc0821%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: My video tutorial series on plugin dev for Jenkins at Apache

[Stephen Connolly]

Oh and these are all live, unscripted and unedited. Stuff goes wrong and
stuff even goes unexpectedly right (episode 3) but I believe that’s more
interesting as it shows how to solve issues with developing in Jenkins

On Mon 30 Oct 2017 at 18:56, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I’ve been recording a series of (approx 20min) videos focused on getting
> better usage of Jenkins at Apache.
>
> The first episode is live.
>
> https://youtu.be/W8BRtJmq_2Y
>
> The second is a “double episode” as I wanted to get to an MVP.
>
> If you are interested in plugin development you might like the series
> --
> Sent from my phone
>
-- 
Sent from my phone

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

My video tutorial series on plugin dev for Jenkins at Apache

[Stephen Connolly]

I’ve been recording a series of (approx 20min) videos focused on getting
better usage of Jenkins at Apache.

The first episode is live.

https://youtu.be/W8BRtJmq_2Y

The second is a “double episode” as I wanted to get to an MVP.

If you are interested in plugin development you might like the series
-- 
Sent from my phone

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

Re: Dynamically populate drop down in builder interface

[Stephen Connolly]

On Sun 29 Oct 2017 at 06:43, 'Marco Brondani' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Hello,
> I have a plug-in that uses Jenkins credentials to store API key and
> details necessary to make requests when the plug in runs.
> However, to improve the Builder interface, I'd like to use the credentials
> to make a request to the API and automatically populate the drop down in
> the builder itself.
> How can I do that?
>
> The credentials are not accessible in the jelly so I can't just set a js
> script to make the Ajax.
>
> Any help would be greatly helpful.
>

It’s a fairly standard pattern, you just have the doFill___Items method in
the DescriptorImpl reference the required fields with @QueryParam

Eg see doFillRepositoryItems in
https://github.com/jenkinsci/gitea-plugin/blob/master/src/main/java/org/jenkinsci/plugin/gitea/GiteaSCMSource.java


>
> Thank you,
> Marco
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/HE1P195MB018878B3F690F248A739D586F5580%40HE1P195MB0188.EURP195.PROD.OUTLOOK.COM
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: Jenkins.createProject - ACL

[Stephen Connolly]

On 24 October 2017 at 19:11, Jesse Glick  wrote:

> On Tue, Oct 24, 2017 at 1:23 PM, Shaun Thompson  wrote:
> > By logged in user, I'm referring to the user that initiated the plugin
> > installation.
>
> There is no information available to that effect, if such a concept
> were even reliably meaningful, which it is not.
>
> Clearly anyone able to install a plugin can do whatever they like—they
> must be an administrator. So if your plugin wishes to create a job
> during installation (again, a bad idea as a rule),


Just so that you are aware...

We have not told you that you are holding a fully armed rocket launcher
with a hair trigger... you are pointing that rocket launcher at your
foot... By all means if you want to pull the trigger... but I would not
recommend it.


> just do so. You
> should be running as `SYSTEM`, which can do anything.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/CANfRfr0c6gy19LuiN%2BOWiEAoNAeP369VMYM6at7dtD4um3
> dO%2Bg%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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMxN0TwLy7pevPE0Ya626DW908qQBN4kbH7_UZj84a_RaQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: freestyle-multibranch, multibranch, scm-api questions

[Stephen Connolly]

On 20 October 2017 at 21:14, Kanstantsin Shautsou <kanstantsin@gmail.com
> wrote:

>
>
> On Friday, October 20, 2017 at 2:16:41 PM UTC+3, Stephen Connolly wrote:
>>
>>
>>
>> On 20 October 2017 at 04:02, Kanstantsin Shautsou <kanstan...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> 2017-10-20 11:50 GMT+03:00 Stephen Connolly <stephen.al...@gmail.com>:
>>>
>>> On 19 October 2017 at 17:42, Kanstantsin Shautsou <kanstan...@gmail.com>
>>>> wrote:
>>>>
>>>>> Trying to make multibranch support with not messed buildhistory by
>>>>> reusing my flexible github triggering code and experience.
>>>>>
>>>>
>>>> Unclear what you mean by "not messed build history"... with
>>>> multibranch, each branch gets its own clean history... the only issue that
>>>> I know about build history is that when a new branch is discovered, its
>>>> first build will have an empty history (we'd like to have it link to the
>>>> other branch that this new branch was forked from... though that may not
>>>> always be possible)
>>>>
>>>> Or are you referring to the crazy of having git build many branches of
>>>> in a single job that drove me to develop multibranch in the first place.
>>>>
>>> Yes, i mean that it good to have separated history.
>>>
>>>>
>>>>
>>>>> Have some questions after first scm/branch/freestyle API reading
>>>>> impression:
>>>>> - Why uncategorized view is primary 
>>>>> jenkins.branch.MultiBranchProjectViewHolder#getViews
>>>>> and how to set own primary view?
>>>>>
>>>>
>>>> Because the "standard" SCMHeads should not have a category.
>>>>
>>> Why?
>>>
>>
>> because categories are a mix-in. Some SCMs will not have different types
>> of "branch like" things that can be discovered.
>>
>>
>>>
>>>>
>>>>
>>>>> - Why uncategorized DEFAULT view (category) is named "Branch" by
>>>>> default?
>>>>>
>>>>
>>>> That is a decision for the SCMSource. If Accurev gets around to
>>>> implementing SCM API then that would probably have its uncategorised
>>>> category called `Stream`
>>>>
>>>> If you then have a multibranch project with two sources, one github and
>>>> the other accurev then you would have:
>>>>
>>>> - `Branches / Streams` as the default view
>>>> - `Snapshots / Tags` if somebody has enabled tag discovery on both
>>>> SCMSources
>>>> - `Pull Requests` if you enable pull request discovery for GitHub but
>>>> there is no equivalent category for accurev... if accurev had an equivalent
>>>> functionality and it was enabled at the same time then you'd have this tab
>>>> called `Change Requests / Pull Requests` (in the event that Accurev uses
>>>> the term `Change Requests`... if they use the term `Pull Requests` then
>>>> this would be just `Pull Requests` as both sources would be agreeing on the
>>>> terminology.
>>>>
>>> AFAIR they will be in one view only when they will have one category
>>> that sounds weird to mix different sources in one view.
>>>
>>
>> So the expected case is that you only ever have one SCMSource... but
>> consider the case where you are migrating from one SCM to another for your
>> "project"
>>
>> In that case you might have both Accurev and GitHub with the maintenance
>> branches on one and the new development on another.
>>
>> Now when I need to go look at the status of a "branch" (and as a
>> developer I don't give a f*ck whether the SCM called that a "Stream" or a
>> "Branch") I want to go to one tab and see all of them together... same goes
>> for tag/snapshot and pull request/change request.
>>
>> So we group the same categories together... categories are a way of
>> grouping outside of the class hierarchy
>>
>>
>>>
>>>>
>>>>> - Freestyle-multibranch uses observer jenkins.branch.MultiB
>>>>> ranchProject.SCMHeadObserverImpl#observe  is it possible to replace
>>>>> it with custom logic?
>>>>>
>>>>
>>>> Why should it do custom logic? It's job is just to create the project

Re: freestyle-multibranch, multibranch, scm-api questions

[Stephen Connolly]

On 20 October 2017 at 04:02, Kanstantsin Shautsou <kanstantsin@gmail.com
> wrote:

>
>
> 2017-10-20 11:50 GMT+03:00 Stephen Connolly <stephen.alan.connolly@gmail.
> com>:
>
>> On 19 October 2017 at 17:42, Kanstantsin Shautsou <
>> kanstantsin@gmail.com> wrote:
>>
>>> Trying to make multibranch support with not messed buildhistory by
>>> reusing my flexible github triggering code and experience.
>>>
>>
>> Unclear what you mean by "not messed build history"... with multibranch,
>> each branch gets its own clean history... the only issue that I know about
>> build history is that when a new branch is discovered, its first build will
>> have an empty history (we'd like to have it link to the other branch that
>> this new branch was forked from... though that may not always be possible)
>>
>> Or are you referring to the crazy of having git build many branches of in
>> a single job that drove me to develop multibranch in the first place.
>>
> Yes, i mean that it good to have separated history.
>
>>
>>
>>> Have some questions after first scm/branch/freestyle API reading
>>> impression:
>>> - Why uncategorized view is primary 
>>> jenkins.branch.MultiBranchProjectViewHolder#getViews
>>> and how to set own primary view?
>>>
>>
>> Because the "standard" SCMHeads should not have a category.
>>
> Why?
>

because categories are a mix-in. Some SCMs will not have different types of
"branch like" things that can be discovered.


>
>>
>>
>>> - Why uncategorized DEFAULT view (category) is named "Branch" by default?
>>>
>>
>> That is a decision for the SCMSource. If Accurev gets around to
>> implementing SCM API then that would probably have its uncategorised
>> category called `Stream`
>>
>> If you then have a multibranch project with two sources, one github and
>> the other accurev then you would have:
>>
>> - `Branches / Streams` as the default view
>> - `Snapshots / Tags` if somebody has enabled tag discovery on both
>> SCMSources
>> - `Pull Requests` if you enable pull request discovery for GitHub but
>> there is no equivalent category for accurev... if accurev had an equivalent
>> functionality and it was enabled at the same time then you'd have this tab
>> called `Change Requests / Pull Requests` (in the event that Accurev uses
>> the term `Change Requests`... if they use the term `Pull Requests` then
>> this would be just `Pull Requests` as both sources would be agreeing on the
>> terminology.
>>
> AFAIR they will be in one view only when they will have one category that
> sounds weird to mix different sources in one view.
>

So the expected case is that you only ever have one SCMSource... but
consider the case where you are migrating from one SCM to another for your
"project"

In that case you might have both Accurev and GitHub with the maintenance
branches on one and the new development on another.

Now when I need to go look at the status of a "branch" (and as a developer
I don't give a f*ck whether the SCM called that a "Stream" or a "Branch") I
want to go to one tab and see all of them together... same goes for
tag/snapshot and pull request/change request.

So we group the same categories together... categories are a way of
grouping outside of the class hierarchy


>
>>
>>> - Freestyle-multibranch uses observer jenkins.branch.MultiB
>>> ranchProject.SCMHeadObserverImpl#observe  is it possible to replace it
>>> with custom logic?
>>>
>>
>> Why should it do custom logic? It's job is just to create the project and
>> trigger a build if and only if:
>>
>> 1. The SCMRevision is different from the previous
>>
> That wrong assumption locked all APIs to only this one possible thing in
> triggering branch/pr builds.
> Though i can try to hack it and control build triggering via it in
> deterministics and equals.
>
> 2. The BranchBuildStrategy gives the OK to build (or if there are no
>> branch build strategies then auto-build everything except tags)
>>
>>
>>> This observer is not flexible and not extendable, it can do only simple
>>> case comparison this vs that by revision. How to run the same build if it
>>> was already built? Revision+Head are not enough information.
>>>
>>
>> BranchBuildStrategy is the place for more complex decisions, multibranch
>> is opinionated and aims to remove the effect of 100 jobs trying to poll for
>> changes and replace that with (worst case)

Re: freestyle-multibranch, multibranch, scm-api questions

[Stephen Connolly]

On 19 October 2017 at 17:42, Kanstantsin Shautsou  wrote:

> Trying to make multibranch support with not messed buildhistory by reusing
> my flexible github triggering code and experience.
>

Unclear what you mean by "not messed build history"... with multibranch,
each branch gets its own clean history... the only issue that I know about
build history is that when a new branch is discovered, its first build will
have an empty history (we'd like to have it link to the other branch that
this new branch was forked from... though that may not always be possible)

Or are you referring to the crazy of having git build many branches of in a
single job that drove me to develop multibranch in the first place.


> Have some questions after first scm/branch/freestyle API reading
> impression:
> - Why uncategorized view is primary jenkins.branch.
> MultiBranchProjectViewHolder#getViews and how to set own primary view?
>

Because the "standard" SCMHeads should not have a category.


> - Why uncategorized DEFAULT view (category) is named "Branch" by default?
>

That is a decision for the SCMSource. If Accurev gets around to
implementing SCM API then that would probably have its uncategorised
category called `Stream`

If you then have a multibranch project with two sources, one github and the
other accurev then you would have:

- `Branches / Streams` as the default view
- `Snapshots / Tags` if somebody has enabled tag discovery on both
SCMSources
- `Pull Requests` if you enable pull request discovery for GitHub but there
is no equivalent category for accurev... if accurev had an equivalent
functionality and it was enabled at the same time then you'd have this tab
called `Change Requests / Pull Requests` (in the event that Accurev uses
the term `Change Requests`... if they use the term `Pull Requests` then
this would be just `Pull Requests` as both sources would be agreeing on the
terminology.


> - Freestyle-multibranch uses observer 
> jenkins.branch.MultiBranchProject.SCMHeadObserverImpl#observe
> is it possible to replace it with custom logic?
>

Why should it do custom logic? It's job is just to create the project and
trigger a build if and only if:

1. The SCMRevision is different from the previous
2. The BranchBuildStrategy gives the OK to build (or if there are no branch
build strategies then auto-build everything except tags)


> This observer is not flexible and not extendable, it can do only simple
> case comparison this vs that by revision. How to run the same build if it
> was already built? Revision+Head are not enough information.
>

BranchBuildStrategy is the place for more complex decisions, multibranch is
opinionated and aims to remove the effect of 100 jobs trying to poll for
changes and replace that with (worst case) one multibranch polling for
changes or (best case) one multibranch being pushed events


> (Probably this is an answer why there is still no smart messages for
> rebuilds.
>   if (rebuild) {
>
> listener.getLogger().format(
>
> "%s reopened: %s (%s)%n",)   < why API expects defined
> behavior? Again, what if i want rebuild by comment, date, other ifluence?
>

Freestyle-multibranch was an early experiment, probably needs some updating
to the latest code.


> One more place of decision making is SCMSourceCriteria... Oh, and
> Trait(?)... And BranchPropertyStrategy... How much places are designed for
> decision making and influence on final result?
>

The SCMSourceCriteria is to decide *is this a branch/tag/pr that should
have a project created*

The BranchPropertyStrategy is to decorate each child job

The BranchBuildStrategy is to decide when to build branches


> Can i  decide in one (my) place and just return to multibranch my
> decision: "this head, branch, etc should be built, please create views by
> corresponding SCMHeadCategory, etc" Or just not call observe and bypass it?
>

The Multibranch is supposed to create one view for each of the
(consolidated) categories that its SCMSources report are enabled. If you
don't like that then you can override `newFolderViewHolder` and return your
own view holder. Keep in mind that in an Org Folder the user will not be
able to configure the views for each repository, so the view holder must be
automatic.


> - Is State.class expected to be used as persistent storage of data for
> plugins? If yes, then how to control exceptions during xmlread to exclude
> data clearing?
>

It is intended to store the SCM-API state in order to allow the branch-api
to decide when to trigger rebuilds, etc

> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/5e646943-4151-4084-9f92-89788467a5ae%
> 40googlegroups.com
> 

FYI: On naming SCM implementation and extension plugins

[Stephen Connolly]

I have published my recommendations on naming SCM API implementation and
extension plugins:

https://github.com/jenkinsci/scm-api-plugin/blob/master/docs/implementation.adoc#naming-your-plugin

Also my guidance on where functionality should land:

https://github.com/jenkinsci/scm-api-plugin/blob/master/CONTRIBUTING.md#add-to-core-or-create-extension-plugin

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

Re: Warning during multi-branch Indexing

[Stephen Connolly]

Nope Nope Nope... it's
https://github.com/jenkinsci/pipeline-milestone-step-plugin/commit/7ecb946d1c54ed15a8f4bb9848cfaa9da7c6086f#diff-1918a0bfc343fead0364ffbc8e42b847
you just need pipeline-milestone-step 1.3.1 or newer

On 4 October 2017 at 03:26, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I think that is an issue in cloudbees-folders plugin
>
> On 4 October 2017 at 03:02, pallen <pal...@perforce.com> wrote:
>
>> Hi Guys,
>>
>> The p4-plugin shows a warning during multi-branch indexing when an old
>> branch is being removed:
>>
>>
>> Oct 04, 2017 10:19:46 AM hudson.model.listeners.ItemListener forAll
>> WARNING: failed to send event to listener of class
>> org.jenkinsci.plugins.pipeline.milestone.MilestoneStepExecution$CleanupJobsOnDelete
>>
>> java.lang.NullPointerException
>> at org.jenkinsci.plugins.pipeline.milestone.MilestoneStepExecut
>> ion$CleanupJobsOnDelete.onDeleted(MilestoneStepExecution.java:348)
>> at hudson.model.listeners.ItemListener$4.apply(ItemListener.java:205)
>> at hudson.model.listeners.ItemListener$4.apply(ItemListener.java:203)
>> at hudson.model.listeners.ItemListener.forAll(ItemListener.java:167)
>> at hudson.model.listeners.ItemListener.fireOnDeleted(ItemListener.java:203)
>>
>> at 
>> com.cloudbees.hudson.plugins.folder.AbstractFolder.onDeleted(AbstractFolder.java:949)
>>
>> at 
>> com.cloudbees.hudson.plugins.folder.AbstractFolder.onDeleted(AbstractFolder.java:135)
>>
>> at hudson.model.AbstractItem.delete(AbstractItem.java:583)
>> at hudson.model.Job.delete(Job.java:687)
>> at com.cloudbees.hudson.plugins.folder.computed.ComputedFolder.
>> updateChildren(ComputedFolder.java:198)
>> at com.cloudbees.hudson.plugins.folder.computed.FolderComputati
>> on.run(FolderComputation.java:139)
>> at hudson.model.ResourceController.execute(ResourceController.java:98)
>> at hudson.model.Executor.run(Executor.java:410)
>>
>>
>> I'm not sure if this is just due to me testing on an old Jenkins
>> (1.642.3) or if I have not implemented a cleanup method?
>>
>> Kind regards,
>> Paul
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/jenkinsci-dev/e2717b91-0803-4621-b1da-80e327381218%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/e2717b91-0803-4621-b1da-80e327381218%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: Warning during multi-branch Indexing

[Stephen Connolly]

I think that is an issue in cloudbees-folders plugin

On 4 October 2017 at 03:02, pallen  wrote:

> Hi Guys,
>
> The p4-plugin shows a warning during multi-branch indexing when an old
> branch is being removed:
>
>
> Oct 04, 2017 10:19:46 AM hudson.model.listeners.ItemListener forAll
> WARNING: failed to send event to listener of class org.jenkinsci.plugins.
> pipeline.milestone.MilestoneStepExecution$CleanupJobsOnDelete
> java.lang.NullPointerException
> at org.jenkinsci.plugins.pipeline.milestone.MilestoneStepExecution$
> CleanupJobsOnDelete.onDeleted(MilestoneStepExecution.java:348)
> at hudson.model.listeners.ItemListener$4.apply(ItemListener.java:205)
> at hudson.model.listeners.ItemListener$4.apply(ItemListener.java:203)
> at hudson.model.listeners.ItemListener.forAll(ItemListener.java:167)
> at hudson.model.listeners.ItemListener.fireOnDeleted(ItemListener.java:203)
>
> at com.cloudbees.hudson.plugins.folder.AbstractFolder.
> onDeleted(AbstractFolder.java:949)
> at com.cloudbees.hudson.plugins.folder.AbstractFolder.
> onDeleted(AbstractFolder.java:135)
> at hudson.model.AbstractItem.delete(AbstractItem.java:583)
> at hudson.model.Job.delete(Job.java:687)
> at com.cloudbees.hudson.plugins.folder.computed.
> ComputedFolder.updateChildren(ComputedFolder.java:198)
> at 
> com.cloudbees.hudson.plugins.folder.computed.FolderComputation.run(FolderComputation.java:139)
>
> at hudson.model.ResourceController.execute(ResourceController.java:98)
> at hudson.model.Executor.run(Executor.java:410)
>
>
> I'm not sure if this is just due to me testing on an old Jenkins (1.642.3)
> or if I have not implemented a cleanup method?
>
> Kind regards,
> Paul
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/e2717b91-0803-4621-b1da-80e327381218%
> 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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMzm_Ti4PQUsbcjxfgZ-CXNOTkTu8YXctq4toPy7hwjnnQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Speeding up the ATH

[Stephen Connolly]

On Thu 28 Sep 2017 at 20:33, Jesse Glick <jgl...@cloudbees.com> wrote:

> On Thu, Sep 28, 2017 at 2:51 PM, Stephen Connolly
> <stephen.alan.conno...@gmail.com> wrote:
> > writing good acceptance tests is a high skill and not something that
> > can be easily crowdsourced.
>
> Agreed. In particular we should not be asking GSoC contributors to
> write new acceptance tests. Every PR proposing a new test should be
> carefully reviewed with an eye to whether it is testing something that
>
> · could not reasonably be covered by lower-level, faster tests
> · is a reasonably important user scenario, for which an accidental
> breakage would be considered a noteworthy regression worth holding up
> or even blacklisting a release (of core or a plugin)
> · is sufficiently distinct from other scenarios already being tested
> that we think regressions might otherwise slip by
>

+1


> > there is a fundamental flaw in
> > using the same harness to drive as to verify *because* any change to that
> > harness has the potential to invalidate any tests using the modified
> > harness
>
> Probably true but does not seem to me like the highest priority facing us.


If we want high value tests, this is the direction I recommend. How we get
there is (or even if we get to my recommendation) is a matter for the
people driving the effort to decide. You have my advice and you appear to
understand why I recommend it. I am not driving this effort, so I will not
dictate anything about it.

>
>
> > it is all too easy to turn a good test into a test giving a false
> > positive
>
> I am not personally aware of any such historical cases (maybe I missed
> some). The immediate problems are slowness, flakiness (tests sometimes
> fail for no clear reason), and fragility (tests fail due to trivial
> code changes especially in the UI).


Well here’s the thing, unless we retest the tests with the feature under
test broken, we have no way of knowing. A false test will pass irrespective
of whether the feature works or not... likely rather features are working,
so nobody will question the passing tests that originally tested the
feature but now are simultaneously failing to test and failing to verify.

Fragile tests are a worse problem in my mind.

Useless slow tests are an even worse problem.

But that is just my opinion, how you apply your energy is your call.

>
>
> > We need an ATH that can be realistically run by humans in an hour or two
>
> Yes that seems like a good goal.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr04H5Zd4xoq2HHQH0XdUezCOnykcOgRM_9T7npwtwBA0Q%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: Speeding up the ATH

[Stephen Connolly]

On Thu 28 Sep 2017 at 19:11, Mark Waite  wrote:

> On Thu, Sep 28, 2017 at 11:43 AM Jesse Glick  wrote:
>
>> On Thu, Sep 28, 2017 at 10:42 AM, Mark Waite 
>> wrote:
>> > Do we have any way of associating historical acceptance test harness
>> > failures to a cause of those failures?
>>
>> Not that I am aware of.
>>
>> > could such data be gathered from some sample of recent runs of the
>> > acceptance test harness, so that we know which of the tests have been
>> most
>> > helpful in the recent past?
>>
>> Maybe. I doubt things are in good enough condition to do that kind of
>> analysis. AFAIK none of the CI jobs running the ATH have ever had a
>> single stable run, so there is not really a baseline.
>>
>>
> Ah, so that means the current acceptance test harness is unlikely to be
> trusted in its entirety by anyone.  A failure in the entire acceptance test
> harness is probably only used rarely to stop a release.
>
> I support deleting tests of questionable value.
>

I don’t want to knock the contributors to the ATH, but my long standing
view is that writing good acceptance tests is a high skill and not
something that can be easily crowdsourced.

Acceptance tests are, by their nature, among the slowest tests.

My long standing view of the ATH is that there is a fundamental flaw in
using the same harness to drive as to verify *because* any change to that
harness has the potential to invalidate any tests using the modified
harness... it is all too easy to turn a good test into a test giving a
false positive... I think an ATH that had two sets of tests, one driving by
the filesystem / CLI and verifying via the UI while the other drives by the
UI and verified by the filesystem / CLI would be much much stronger (and
faster too). In most cases you wouldn’t be changing the two harnesses at
the same time, so a failing test will indicate a failing test.

We need an ATH that can be realistically run by humans in an hour or two...
trim the test cases to get there, moving the tested functionality higher up
to be tests that run faster, eg JenkinsRule or better yet pure unit tests.

That’s just my view, feel free to ignore. (Because some people confuse my
interaction style I am going to try and clarify) I’m bowing out unless
someone specifically asks me for clarification on my recommendations or I
see people miss-representing my opinion... this is normally the way I
interact... just people have a real habit of dragging me back in and that
makes me look like someone who rabbits on and on.


> > Alternately, could we add a layering concept to the acceptance test
>> harness?
>> > There could be "precious" tests which run every time and there could be
>> > other tests which are part of a collection from which a few tests are
>> > selected randomly for execution every time.
>>
>> Yes this is possible.
>>
>> > is there a way to make the acceptance test harness run
>> > in a massively parallel fashion
>>
>> Yes. Does not help with the flakiness, and still wastes a tremendous
>> amount of cloud machine time.
>>
>>
> Would we consider a policy that flaky tests are deleted, rather than
> tolerated?  Possibly with an email notification to each committer that
> modified any line in the deleted test?
>
> I've understood that Kent Beck has mentioned that they delete flaky tests
> at facebook, rather than just tolerating them.  Seems dramatic, but
> increases trust in the acceptance test results, and encourages moving tests
> from the ATH into JenkinsRule or other locations where they may be easier
> to diagnose.
>
> Mark Waite
>
>
>> > As a safety check of that concept, did any of the current acceptance
>> tests
>> > detect the regression when run with Jenkins 2.80 (or Jenkins 2.80 RC)?
>>
>> Yes.
>>
>> > Is there a JenkinsRule test which could reasonably be written to test
>> for
>> > the conditions that caused the bug in Jenkins 2.80?
>>
>> Not really; that particular issue was unusual, since it touched on the
>> setup wizard UI which is normally suppressed by test harnesses.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0LJ6z%3DTiQe8Rt9P_D7RpZDEHt3XAWQxoq%3Dd0dVAD%2BG%3Dw%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 Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> 

Please retweet and vote

[Stephen Connolly]

https://twitter.com/asfmavenproject/status/906451059966693376
-- 
Sent from my phone

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

Re: [Announce] Gerrit CI workflow to become a brand-new Jenkins plugin

[Stephen Connolly]

I recommend using the gitea plugin as a "clean" example of a branch source,
as it is relatively feature complete (gaps are api gaps in gitea itself)
and free of the rate limit and class migration noise in github and
Bitbucket branch source plugins

On Thu 7 Sep 2017 at 23:00, Luca Milanesio  wrote:

>
> On 7 Sep 2017, at 14:48, Vacelet, Manuel 
> wrote:
>
> Hi Luca (congrats to the new gerrit maintainer BTW),
>
> It does answer the question but raise a new one ;)
> Have you an ETA in mind for all this ?
>
>
> We are talking about weeks for sure, as I want to ship something fully
> documented and working.
>
> I was planning to share it as "showcase" with a Docker compose containing:
> - Gerrit 2.15 (or a pre-release)
> - Jenkins 2.x with BlueOcean
>
> I believe the coupling of BlueOcean + PolyGerrit will give the "business
> case" for many people to start adopting the two tools instead of heading to
> GitLab or similar.
>
> Luca.
>
>
> Manuel
>
>
>
> On Thu, Sep 7, 2017 at 12:22 PM, Luca Milanesio 
> wrote:
>
>> Hi Manuel,
>> I discussed the topic with Robert at the Jenkins World conference last
>> week, and we agreed that:
>>
>> 1. More work is needed on the branch discovery side: I need to flag the
>> ones coming from Gerrit Changes with a specific label
>> 2. The plugin is going to be focused on the branch source API feature:
>> Gerrit-branch-source similarly to GitHub-branch-source
>> 3. Gerrit Trigger plugin will stay anyway for his specific use-case:
>> triggering the build based on a Gerrit stream event
>>
>> Does that answer your questions?
>>
>> Luca.
>>
>> On 7 Sep 2017, at 08:08, Vacelet, Manuel 
>> wrote:
>>
>> Hi Luca,
>>
>> Jenkins World Conference is over, did you manage to showcase this new
>> plugin ?
>> What's the status and what are the plans for the future ?
>>
>> Manuel
>>
>> On Fri, Aug 18, 2017 at 11:04 AM, Luca Milanesio <
>> luca.milane...@gmail.com> wrote:
>>
>>> Hi Gerrit and Jenkins Community,
>>> after over two years of iterations and improvements of the Gerrit CI
>>> workflow (https://gerrit-ci.gerritforge.com), I have decided that is
>>> about time to extract the logic of our workflow and make it available as a
>>> brand-new Jenkins plugin!
>>>
>>> *Why?*
>>> I wanted to use the Gerrit CI validation workflow with potentially any
>>> project, including Gerrit plugins or anybody else wanting to adopt it.
>>> I could just "copy & paste" our Groovy workflow, however, that does not
>>> seem a sensible and long-term approach.
>>> I wanted to have "something more" than a pure triggering mechanism: I
>>> wanted to extend the power of Jenkisfile with the Gerrit review workflow
>>> verbs.
>>>
>>> *Why not?*
>>> Why should I write yet another Gerrit/Jenkins plugin? Isn't Gerrit
>>> Trigger Plugin (https://wiki.jenkins.io/display/JENKINS/Gerrit+Trigger)
>>> enough?
>>> We couldn't use it against gerrit-review.googlesource.com because
>>> stream events are just not accessible.
>>>
>>> There are unresolved issues about:
>>> - Stability: stream-events are based on SSH, which isn't scalable,
>>> reliable against downtime, etc.
>>> - Usability: at every JenkinsWorld conference people still come to me
>>> asking "how do I setup correct the Gerrit Trigger plugin"?
>>> - Integration: using it inside a JenkinsFile isn't that straightforward
>>> and multi-branch projects aren't supported either
>>>
>>> *What would it be?*
>>> I will publish a new plugin named "Gerrit Pipeline Plugin."
>>> The new name indicates:
>>> - Deep integration with Jenkins Pipeline
>>> - Out-of-the-box integration with Gerrit validation workflow in the
>>> pipeline
>>>
>>> A simple example scripted Jenkinsfile would be:
>>>
>>> node {
>>> checkout scm
>>>
>>> gerrit.withServer("http://gerrit:8080/;, "gerrit") {
>>>
>>> try {
>>> docker.image('gerritforge/play-sbt-8-jdk-alpine').inside {
>>> stage('Build') {
>>> sh 'sbt compile'
>>> }
>>> stage('Test') {
>>> sh 'sbt 'test'
>>> }
>>> }
>>>
>>> gerrit.review("Verified", 1, "It works !")
>>> } catch (e) {
>>> gerrit.review("Verified", -1, "Breaks the build ;-(")
>>> throw e
>>> }
>>> }
>>> }
>>>
>>> (Where:
>>> - https://gerrit-review.example.com would be the Gerrit URL
>>> - mycredentialsid would be the id of the credentials to access Gerrit)
>>>
>>> One key-aspect will be: stateless, configuration-less (apart from the
>>> credentials stored in Jenkins keychain)
>>> That means that multiple Jobs, multiple branches of the same Job, can
>>> have their own Gerrit integration defined and working out-of-the-box.
>>>
>>> No more people asking "how do I configure the Gerrit integration"?
>>> You'll just define a gerrit.withServer() { } and ... it will just work.
>>>
>>> *When?*

Re: How to stop the current pipeline step?

[Stephen Connolly]

https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/steps/ErrorStep.java#L63
is one example from the existing codebase. You might find more

On 4 September 2017 at 12:42, Ivo Bellin Salarin <
ivo.bellinsala...@gmail.com> wrote:

> No, I wasn't throwing anything, since in the past the perform(Abstract
> build, ...) was returning a Boolean, and AFAIk a False was sufficient to
> stop the execution...
>
> Should the thrown exception belong to a definite set, or inherit from a
> specific base type?
>
> On lun. 4 sept. 2017 à 20:29 Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> On Mon 4 Sep 2017 at 17:47, Ivo Bellin Salarin <
>> ivo.bellinsala...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> I am implementing the pipeline functionality for an existing plugin.
>>> Currently, on an eventual error the plugin sets the build status to
>>> FAILURE: the build continues executing all the build steps after the
>>> current one, and its status is set to failure, as expected
>>>
>>
>> Are you throwing an exception after setting the build result?
>>
>> Iirc you should be throwing something if you want the execution to "stop"
>>
>> (Though finally-type behaviour should continue execution)
>>
>>> .
>>>
>>> But I would like the build to stop right after this step execution,
>>> skipping all the following steps . On some SO posts I have found that the
>>> ABORTED step should be preferred to FAILURE to obtain this behavior. Is
>>> this right? I am persuaded that the official Javadoc documentation is
>>> unclear. Has somebody a better explanation/documentation about the build
>>> Result(s) codes?
>>>
>>> Many thanks in advance,
>>> Ivo
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/jenkinsci-dev/CAPc4eF8Kif5jUUu9hf7h%2Bo%
>>> 3DzMuqPY8cXxzacRwzQcrG7hunkNg%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPc4eF8Kif5jUUu9hf7h%2Bo%3DzMuqPY8cXxzacRwzQcrG7hunkNg%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> Sent from my phone
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/jenkinsci-dev/CA%2BnPnMyHDhqnkO3MwkYmh0zBYUF%
>> 3DdyTFaLR4Rz8CbZ0NgZQhPg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMyHDhqnkO3MwkYmh0zBYUF%3DdyTFaLR4Rz8CbZ0NgZQhPg%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/CAPc4eF9KnxMLfEafznXvm3_DqgKJBrmxP6jHyJg2akj9uPKuLg%
> 40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPc4eF9KnxMLfEafznXvm3_DqgKJBrmxP6jHyJg2akj9uPKuLg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: How to stop the current pipeline step?

[Stephen Connolly]

On Mon 4 Sep 2017 at 17:47, Ivo Bellin Salarin 
wrote:

> Hi all,
>
> I am implementing the pipeline functionality for an existing plugin.
> Currently, on an eventual error the plugin sets the build status to
> FAILURE: the build continues executing all the build steps after the
> current one, and its status is set to failure, as expected
>

Are you throwing an exception after setting the build result?

Iirc you should be throwing something if you want the execution to "stop"

(Though finally-type behaviour should continue execution)

> .
>
> But I would like the build to stop right after this step execution,
> skipping all the following steps . On some SO posts I have found that the
> ABORTED step should be preferred to FAILURE to obtain this behavior. Is
> this right? I am persuaded that the official Javadoc documentation is
> unclear. Has somebody a better explanation/documentation about the build
> Result(s) codes?
>
> Many thanks in advance,
> Ivo
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAPc4eF8Kif5jUUu9hf7h%2Bo%3DzMuqPY8cXxzacRwzQcrG7hunkNg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: New SCMSource trait: filtering old git references

[Stephen Connolly]

On Thu 31 Aug 2017 at 08:37, Javier Delgado <witokondo...@gmail.com> wrote:

> Of course, I was expecting this trait to be included in a separate plugin
> (WIP already on https://github.com/witokondoria/git-aged-refs-trait-plugin
> )
>
> Those caches arent already implemented? What I feel I'm lacking is the
> commit date (and might be solved via the bitbucket and github api
> components)
>

I am not sure if the info you need is in one of the cached objects or not.

If it is already present, WIN!

If not present, I am happy to review PRs  on the "core" plugins that enable
the feature.


>
> El miércoles, 30 de agosto de 2017, 13:10:00 (UTC+2), Stephen Connolly
> escribió:
>>
>> On 30 August 2017 at 01:03, Javier Delgado <witoko...@gmail.com> wrote:
>>
>>> Following this comment
>>> <https://groups.google.com/forum/#!forum/jenkinsci-dev>, I was planning
>>> on creating a new scm trait for excluding references according to a date
>>> threshold.
>>>
>>> The idea after the trait would be leaving out from an analysis branches
>>> considered deprecated or unmantained. This way, a new github organization
>>> or bitbucket team project wouldn't create jobs for the whole references
>>> sitting at the repository but just for the recent ones.
>>>
>>> With this, the implementation seems it could be easy as hell, define a
>>> class extending from SCMSourceTrait that would add a (pre)filter according
>>> the defined threshold value. Here comes my question and request for help:
>>>
>>> * Does anyone feel this would be an invaluable feature or doable in
>>> other way?
>>>
>>
>> I know there are users who would buy you beers if you implemented it for
>> them.
>>
>> There are other users who couldn't care less, which is why this will need
>> to be an extension plugin not part of the core plugins
>>
>>
>>>
>>> I cant seem to be able to look for a commit creation date. I can get the
>>> SHA1 for a branch tip via org.kohsuke.github.GHBranch$Commit and
>>>  com.cloudbees.jenkins.plugins.bitbucket.api.BitbucketBranch. From where
>>> could I extract the modification time of this commit?
>>>
>>> What seems true is that I cant apply a SCMSourceContext prefilter so
>>> this trait wont avoid trips to the Github API
>>>
>>
>> Yep I think you will be hitting round-trips.
>>
>> I am fine with adding supporting changes to the GitHub Branch Source
>> plugin to add lazy caches to the request object... my rule is
>>
>> * Core plugin PRs that enable extension plugins are yes. Stuff that could
>> be an extension plugin should not go in core.
>>
> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to jenkinsci-de...@googlegroups.com.
>>
>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/5c30e3f7-7acb-4268-9d6c-c6bd91103304%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/5c30e3f7-7acb-4268-9d6c-c6bd91103304%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/f497407d-c330-47a2-968a-06eede877c11%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/f497407d-c330-47a2-968a-06eede877c11%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: New SCMSource trait: filtering old git references

[Stephen Connolly]

On 30 August 2017 at 01:03, Javier Delgado  wrote:

> Following this comment
> , I was planning
> on creating a new scm trait for excluding references according to a date
> threshold.
>
> The idea after the trait would be leaving out from an analysis branches
> considered deprecated or unmantained. This way, a new github organization
> or bitbucket team project wouldn't create jobs for the whole references
> sitting at the repository but just for the recent ones.
>
> With this, the implementation seems it could be easy as hell, define a
> class extending from SCMSourceTrait that would add a (pre)filter according
> the defined threshold value. Here comes my question and request for help:
>
> * Does anyone feel this would be an invaluable feature or doable in other
> way?
>

I know there are users who would buy you beers if you implemented it for
them.

There are other users who couldn't care less, which is why this will need
to be an extension plugin not part of the core plugins


>
> I cant seem to be able to look for a commit creation date. I can get the
> SHA1 for a branch tip via org.kohsuke.github.GHBranch$Commit and
>  com.cloudbees.jenkins.plugins.bitbucket.api.BitbucketBranch. From where
> could I extract the modification time of this commit?
>
> What seems true is that I cant apply a SCMSourceContext prefilter so this
> trait wont avoid trips to the Github API
>

Yep I think you will be hitting round-trips.

I am fine with adding supporting changes to the GitHub Branch Source plugin
to add lazy caches to the request object... my rule is

* Core plugin PRs that enable extension plugins are yes. Stuff that could
be an extension plugin should not go in core.

> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/5c30e3f7-7acb-4268-9d6c-c6bd91103304%
> 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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMywZLLHpnL%3DBfciKYPM3WhD4z6QzjvcBSvybMdy4yAuwg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Sortable tables with non existing value but different attributes

[Stephen Connolly]

Isn't it just a question of using the  attribute to have
sorting on that attribute?

On 1 August 2017 at 01:52, Victor Martinez 
wrote:

> Hi there,
>
> Any ideas how I can use the sortable type in a non value cell? I though I
> could use the "data-sort" attribute in the cell but it doesn't work.
>
> As you can see below, there is a table based on two columns, first column
> contains the value "${job.name}" while the second column is just a
> colorful cell
>
> 
> 
>   
>   Job Name
>   Status
>   
> 
> 
> 
> 
> ${job.name}
> 
> 
>
> 
>
> And its UI
>
>
> 
>
> I wish I could also order the Status column based on the colors but it
> seems the only sortable field is the value one: https://github.com/
> jenkinsci/jenkins/blob/master/war/src/main/webapp/scripts/sortable.js#L241
>
> Any ideas whether the sortable class can be used with hidden values or
> different cell attributes?
>
> Thanks
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/5899e2b8-d025-46a2-9a67-5df566aebb75%
> 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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwqGVTRcwJQ64nGx%3D89KAPD%3DqVAOSRLCoB3S%3DKuBEUQpg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Proposal - Disabling JNLP1/2 and CLI1 protocols by default in new Installations

[Stephen Connolly]

+1

On Fri 28 Jul 2017 at 08:53, Oleg Nenashev  wrote:

> Hi all,
>
> It is almost one year since the release of JNLP4 protocol in Remoting 3.0.
> This protocol is available in Jenkins LTS since 2.32.1, and so far it
> demonstrates good stability being compared to JNLP2 and especially to
> JNLP3. The protocol was enabled by default in 2.46.x, and we do not have
> confirmed JNLP4 issues since that.
>
> I propose to disable the previous protocols. I have created JENKINS-45841
>  for it.
>
>
> *Why?*
>
>- JNLP2 stability concerns
>   - There are known issues in JNLP2 connection management. The engine
>   is complex and barely diagnosable
>   - Examples:
>  - https://github.com/jenkinsci/remoting/pull/156
>  - JENKINS-31735
>   -
>  NioChannelHub thread dies sometimes
>  - JENKINS-24155
>   - Slaves
>  going offline in NIO mode
>   - In many cases update to JNLP4 was a resolution
>- JNLP1/JNLP2/CLI1 are known to be unencrypted
>   - Sam Gleske also made it explicit in UI, Jenkins 2.41+ (pull
>   request )
>   - It is not a security issue, they have been never claimed to be
>   encrypted
>   - Jenkins CERT team agreed that disabling protocols is reasonable
>   from the security hardening standpoint
>
> *How?*
>
>- UPD: When installation wizard is enabled && it runs in the new
>installation mode, disable the old protocols during the instance
>initialization
>   - It is similar to what we do for Remoting CLI disabling and the
>   default security initialization in Jenkins 2.0
>   - ADD: administrative monitor, which warns about obsolete Remoting
>protocols and points to the errata documents (like this one)
>- ADD: Explicit deprecation notice to the built-in HTML documentation
>
> *Compatibility concerns*
>
>- Old instances won't be affected, protocols will be still enabled for
>them
>- "New" Jenkins instances installed via setup wizard may be affected
>in age cases. Examples:
>   - Agents with Remoting older than 3.0 will be unable to connect.
>   - One may bundle old Remoting in his custom Docker images, AMIs,
>  etc.
>  - Swarm Plugin
>   : old
>   versions of Swarm Client (before 3.3) will be unable to connect, because
>   Remoting 2.x is bundled
>   - **Very** old jenkins-cli.jar without CLI2 support will be unable
>   to connect
>
> *Not affected:*
>
>- Newly installed instances created from scratch
>- Instances using the "-Djenkins.install.runSetupWizard=false" flag
>(all configuration-as-code instances)
>- SSH Slaves Plugin, any newly installed agent type,
>community-provided Docker packages for agents, etc.
>
> *Announcement*
>
>- It's a potentially breaking change, hence it should be announced in
>blog posts
>- The change and the corner cases should be addressed in the upgrade
>guide, which should be published within the blogpost
>
>
>
> *I think it's a good time to finally do this change. WDYT?Thanks in
> advance,Oleg Nenashev*
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/7a7e2b81-8795-48bd-b1c2-d0ee31123df3%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMw-mrET-X9xO4Y2B%3Dy2MfQ%3DyduKedp9wLiFL-Xk_eKYjQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[ANN] Credentials plugin documentation

[Stephen Connolly]

I have finally finished documenting the credentials plugin.

You can find the documentation at
https://github.com/jenkinsci/credentials-plugin/tree/master/docs

I have also uploaded PDF versions of the documentation to the plugin's wiki
page: https://wiki.jenkins.io/display/JENKINS/Credentials+Plugin

Specifically many people are probably looking for the user guide:
https://wiki.jenkins.io/download/attachments/59511751/user.pdf

The definitive version of the documentation is *always* the GitHub version,
though due to formatting issues in the GitHub Asciidoc preview, the PDFs
can be easier to follow.

This is essentially a brain-dump by me, so pull requests are most welcome...

-Stephen

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

Re: Request to join the Jenkins Security Team

[Stephen Connolly]

More the merrier IMHO, I am +1 on you joining

On 24 July 2017 at 06:04, 'Bruno P. Kinoshita' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Hi Oleg,
>
> I had seen the security advisory, and in the Wiki and GitHub I can see
> some progress made to fix some of the 5 issues.
>
> But I think the maintainer is the only one with access to read and comment
> in the SECURITY-XXX tickets.
>
> At least that's what I recall from when I worked on an SECURITY issue. My
> intention was to check the progress of tickets, see if there was a patch
> somewhere to be tested, or a discussion going on. And then try to help
> scriptler and any other plugin I use/used or that is a dependency in one of
> the plugins I use.
>
> But I can wait till the maintainer has made further progress on the
> issues. I will re-read the description of the security issues with more
> calm over the next days, check latest code and try to liaise directly with
> the maintainer if I have a patch.
>
> Cheers
> Bruno
>
>
> Sent from Yahoo Mail on Android
> 
>
> On Tue, 25 Jul 2017 at 0:06, Oleg Nenashev
>  wrote:
> Hi Bruno,
>
> Generally I am +1 with this request. Having more people is definitely
> useful.
>
> OTOH you probably do not need to be a member of the Security team if you
> *just* want to fix Scriptler. It's vulnerabilities are publicly listed in
> this advisory: https://jenkins.io/security/advisory/2017-04-10/ .
> Regarding plugins maintained by active contributors, we usually assign
> security issues to them. In all other cases like core fixes, yes it makes
> sense to join the security team.
>
> Best regards,
> Oleg
>
> суббота, 22 июля 2017 г., 12:38:12 UTC+3 пользователь kinow написал:
>
> Hi,
>
> I would like to request to be added to the Jenkins Security Team. My main
> interest is in helping to fix issues in any dependency of the plug-ins I
> maintain, as well as in the core. Right now Scriptler is a plug-in I would
> like to try and see if I could help, as it is blocking
> active-choices-plugin.
>
> GitHub with 2FA enabled: kinow
> CLA: https://github.com/jenkinsci/ infra-cla/pull/48
> 
> FreeNode user: kinow
>
> Thank you
> Bruno
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/20d20e3c-a222-4d53-8309-3dd6daee74a0%
> 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 Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/614930702.4539161.1500901468492%40mail.yahoo.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Help with blocking job execution per node

[Stephen Connolly]

May need to extend core to support advertising it.

If it's more than 100ms it is likely a new round

On Fri 21 Jul 2017 at 19:56, Martin Weber <fifteenknots...@gmail.com> wrote:

> Am Donnerstag, 20. Juli 2017, 21:01:13 CEST schrieb Stephen Connolly:
> > On Thu 20 Jul 2017 at 19:13, Martin Weber <fifteenknots...@gmail.com>
> wrote:
>
>
> > If 1:400 is too high, you'll need to bite the bullet and sort out the
> > concurrency to determine when a round starts and then only allow one per
> > round to be unblocked (pick a different one each round)
>
> How can I be informed when a round starts? Implement a QueueListener?
>
> --
> Cd wrttn wtht vwls s mch trsr.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/6949603.eISL3IcJ9R%40linux
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: Help with blocking job execution per node

[Stephen Connolly]

On Thu 20 Jul 2017 at 19:13, Martin Weber  wrote:

> Hi list,
>
> my plugins adds a build wrapper that starts and stop a daemon (similar to
> xvfb
> [1] plugin).
> Only one daemon instance can be run at a time on a single node, so I want
> to
> block job execution automatically, without forcing my users to install and
> configure Throttle Concurrent Builds plugin [2].
>
> I tried to implement a QueueTaskDispatcher that blocks if a job is running
> that also has my plugin wrapper enabled. It works mostly, but if I have 3
> jobs
> with my wrapper enabled in the queue and 2 executors on the node, *both* of
> the 2 blocked jobs start execution after the first job has finished.


Yep because both jobs transition at the same time.

What you need to do is keep track of if you let a job through and wait say
100ms before letting another go through (but round-robin which one you pick)

A cheap way might be to be use a 5% probability of letting a job through
when none are running...

That gives you a 1:400 chance of two jobs in the same "round" and most jobs
should start in under 1 second if they can while avoiding having to deal
with concurrency issues so much.

If 1:400 is too high, you'll need to bite the bullet and sort out the
concurrency to determine when a round starts and then only allow one per
round to be unblocked (pick a different one each round)

>
>
> Can anyone point me to the right direction to solve this (allow only one
> running job with my wrapper enabled per node)?
>
> TIA,
> Martin
>
> [1] https://plugins.jenkins.io/xvfb
> [2] https://plugins.jenkins.io/throttle-concurrents
>
> --
> Cd wrttn wtht vwls s mch trsr.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/6641805.XLH7yz7z48%40linux
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: Plugin/core version installation statistics

[Stephen Connolly]

So 73% of people using the credentials plugin are on the 2.1.x series.

5% of people on the 2.1.x series of the credentials plugin are using a
version of Jenkins older than 1.651 (23% of people using any version of the
credentials plugin as a whole are using a Jenkins version older than 1.651)
10% of people on the 2.1.x series of the credentials plugin are using a
version of Jenkins older than 2.7 (30% of people using any version of the
credentials plugin as a whole are using a Jenkins version older than 2.7)

I think I may consider updating the baseline for the credentials plugin to
either 2.7 or 1.651

On 19 July 2017 at 10:02, Stephen Connolly <stephen.alan.conno...@gmail.com>
wrote:

> Nice!
>
>
> On Wed 19 Jul 2017 at 16:52, Daniel Beck <m...@beckweb.net> wrote:
>
>> Hi everyone,
>>
>> A question that comes up regularly:  "What version of core should I
>> depend on in a plugin?".  Maybe you don't want to arbitrarily limit who can
>> use your plugin, but want newer core features?  This becomes more difficult
>> when your plugin has been around for a while, as now you have users that
>> may still be on older Jenkins releases.
>>
>> While we have some general guidelines in the wiki, we also have data that
>> can help understand usage patterns.  The data discussed below has always
>> been available on the stats site, it just wasn't very accessible.
>>
>> So I added additional output to the stats generator that can be used to
>> inform decisions where to take core dependencies for existing plugins:
>> Every plugin that has usage stats now also has a file like the following
>> with a giant table in it (just replace the plugin ID in the URL):
>>
>> http://stats.jenkins.io/pluginversions/workflow-job.html
>>
>> This table shows which release of a plugin is installed how often on
>> which core release.  The rows are Jenkins releases, the columns are plugin
>> releases (with the last column being the number of plugin installs for any
>> release on that core), and the values are number of installations.
>> Tooltips for each cell show what percentage of users are on any given core
>> or later for the current plugin release (or, in the 'Sum' column, any
>> plugin release).
>>
>> In this example (Pipeline: Job plugin), plugin releases 2.0 - 2.11.1
>> required only core 1.642.3.  How useful is such a low core release, as of
>> June?  Version 2.10 has been around since February, plenty of time to
>> update -- and 90% of users on plugin version 2.10 are on Jenkins 2.32.1 or
>> newer.  This seems to indicate that users on older cores generally don't
>> seem to care a lot about keeping their plugins updated.
>>
>> Some limitations:
>> - The numbers are off a bit compared to what you may be used to, as this
>> doesn't count releases like alpha/beta to keep the size of the table
>> manageable.
>> - Additionally, there's some weirdness going on with instances reporting
>> different core versions over time, so a handful of instances with
>> incompatible core releases may show up as using a given plugin release; I
>> expect that's not actually the case.
>> - It's still not easy to read the giant table for e.g. Git plugin, but
>> it's a start.
>>
>> Copying & pasting the page content from the browser allows transferring
>> the data into a spreadsheet with no further conversion, so you can perform
>> your own analysis pretty easily.
>>
>> The sources for this are in https://github.com/jenkins-
>> infra/infra-statistics -- it's basically all JavaScript in
>> https://github.com/jenkins-infra/infra-statistics/blob/master/
>> generateVersionDistribution-template.html, so easy to iterate on if you
>> want to improve the output format.
>>
>> Note that there's no directory index at https://stats.jenkins.io/
>> pluginversions/ (yet) -- my plan is to add links to plugins.jenkins.io
>> and make that the default entry point.
>>
>> I hope someone finds this useful.
>>
>> Daniel
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/
>> msgid/jenkinsci-dev/12163123-1269-45C0-B91E-116053E920C5%40beckweb.net.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> Sent from my phone
>

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

Re: Plugin/core version installation statistics

[Stephen Connolly]

Nice!


On Wed 19 Jul 2017 at 16:52, Daniel Beck  wrote:

> Hi everyone,
>
> A question that comes up regularly:  "What version of core should I depend
> on in a plugin?".  Maybe you don't want to arbitrarily limit who can use
> your plugin, but want newer core features?  This becomes more difficult
> when your plugin has been around for a while, as now you have users that
> may still be on older Jenkins releases.
>
> While we have some general guidelines in the wiki, we also have data that
> can help understand usage patterns.  The data discussed below has always
> been available on the stats site, it just wasn't very accessible.
>
> So I added additional output to the stats generator that can be used to
> inform decisions where to take core dependencies for existing plugins:
> Every plugin that has usage stats now also has a file like the following
> with a giant table in it (just replace the plugin ID in the URL):
>
> http://stats.jenkins.io/pluginversions/workflow-job.html
>
> This table shows which release of a plugin is installed how often on which
> core release.  The rows are Jenkins releases, the columns are plugin
> releases (with the last column being the number of plugin installs for any
> release on that core), and the values are number of installations.
> Tooltips for each cell show what percentage of users are on any given core
> or later for the current plugin release (or, in the 'Sum' column, any
> plugin release).
>
> In this example (Pipeline: Job plugin), plugin releases 2.0 - 2.11.1
> required only core 1.642.3.  How useful is such a low core release, as of
> June?  Version 2.10 has been around since February, plenty of time to
> update -- and 90% of users on plugin version 2.10 are on Jenkins 2.32.1 or
> newer.  This seems to indicate that users on older cores generally don't
> seem to care a lot about keeping their plugins updated.
>
> Some limitations:
> - The numbers are off a bit compared to what you may be used to, as this
> doesn't count releases like alpha/beta to keep the size of the table
> manageable.
> - Additionally, there's some weirdness going on with instances reporting
> different core versions over time, so a handful of instances with
> incompatible core releases may show up as using a given plugin release; I
> expect that's not actually the case.
> - It's still not easy to read the giant table for e.g. Git plugin, but
> it's a start.
>
> Copying & pasting the page content from the browser allows transferring
> the data into a spreadsheet with no further conversion, so you can perform
> your own analysis pretty easily.
>
> The sources for this are in
> https://github.com/jenkins-infra/infra-statistics -- it's basically all
> JavaScript in
> https://github.com/jenkins-infra/infra-statistics/blob/master/generateVersionDistribution-template.html,
> so easy to iterate on if you want to improve the output format.
>
> Note that there's no directory index at
> https://stats.jenkins.io/pluginversions/ (yet) -- my plan is to add links
> to plugins.jenkins.io and make that the default entry point.
>
> I hope someone finds this useful.
>
> Daniel
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/12163123-1269-45C0-B91E-116053E920C5%40beckweb.net
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: Create a user with ADMINISTER and without RUN_SCRIPTS permission (ATH test case)

[Stephen Connolly]

you need to turn on the separation of permissions... system property or
something like that

On 13 July 2017 at 03:55, Ullrich Hafner  wrote:

> How can I configure a user in an ATH test case who can edit the Jenkins
> global configuration (i.e., has ADMINISTER permission), but has no
> RUN_SCRIPTS permission?  Seems that this permission is not available in the
> Matrix  based security.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/7D1DB319-54A5-491C-9EB2-B4F72A0D6278%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: GitHub and Bitbucket branch source UI refactoring

[Stephen Connolly]

FYI as Daniel is has now published the security advisory:
https://jenkins.io/security/advisory/2017-07-10/

The Git 3.4.0-beta-2 and GitHub Branch Source 2.2.0-beta-2 releases contain
the analogous fixes for the security issues.

We are waiting until Wednesday to allow admins that need to upgrade for
security reasons but do not want to be forced to update to the new UI/UX
just yet a couple of days to do so easily.

After Wednesday - all going according to plan - the GA releases of the
refactored UI will be made available, admins needing to hold back from the
UI/UX changes but needing the security fixes will just have to manually
download the plugin updates.

I was limited in what I could publicly say about the release plan until the
security advisory was published today

On 10 July 2017 at 06:46, Stephen Connolly <stephen.alan.conno...@gmail.com>
wrote:

> Current thinking is the GA release will be Wednesday
>
> On 10 July 2017 at 06:36, Joseph P <joseph...@gmail.com> wrote:
>
>> ETA on Release?
>>
>> Den mandag den 26. juni 2017 kl. 18.13.07 UTC+2 skrev Stephen Connolly:
>>>
>>> On 26 June 2017 at 08:14, Joseph P <jose...@gmail.com> wrote:
>>>
>>>> This UI is a lot better! Looking forward to the massive upgrade!
>>>>
>>>> Just wondering with the refactoring will it be possible for PRs to
>>>> rebuild when changes to target branch is notified?
>>>> When the option for Merge PR with Target branch is selected.
>>>>
>>>> That would be AWESOME!
>>>>
>>>
>>> So right now that would be a controversial feature...
>>>
>>> What I want to do is add the concept of interesting and non-interesting
>>> revisions to SCM-API
>>>
>>> I feel that it is necessary to have that concept in order to enable
>>> support for Tag discovery (because you certainly want old tags as
>>> non-interesting, if not all tags as non-interesting)
>>>
>>> Then the idea would be that the Branch-API's multi-branch project would
>>> not build non-interesting revisions by default.
>>>
>>> With the above changes then we could do things like:
>>>
>>> 1. Merge commits where only the target branch changes are
>>> non-interesting (which is a win for the people who do not want build storms
>>> on indexing)
>>> 2. Merge commits where the target branch changes are interesting (which
>>> is what you want)
>>>
>>> With some of the other changes in SCM-API it would then be safe to add
>>> multi-branch project triggering change requests when the target branch
>>> changes because we'd have https://github.com/jenkinsci/s
>>> cm-api-plugin/blob/master/src/main/java/jenkins/scm/api/mixi
>>> n/ChangeRequestSCMHead.java#L57 and https://github.com/jenkins
>>> ci/scm-api-plugin/blob/master/src/main/java/jenkins/scm/api/
>>> mixin/ChangeRequestSCMHead2.java#L45 so we'd know that the checkout
>>> strategy is merge and hence if https://github.com/jenkinsc
>>> i/scm-api-plugin/blob/master/src/main/java/jenkins/scm/api/m
>>> ixin/ChangeRequestSCMRevision.java#L65 has changed then we should
>>> re-fetch the effective head revision... and if it is interesting then we
>>> can rebuild.
>>>
>>> At least that is my current thinking...
>>>
>>> But right now there are two camps of people:
>>>
>>>- Those who want the build storm
>>>- Those who do not want the build storm
>>>
>>> Until I can satisfy both camps we will have to live with the current
>>> "build storm only on indexing" situation.
>>>
>>>
>>>>
>>>>
>>>> Den fredag den 23. juni 2017 kl. 15.32.54 UTC+2 skrev Stephen Connolly:
>>>>>
>>>>> How do you find the new UI compared with the previous one?
>>>>>
>>>>> On 23 June 2017 at 14:18, Joseph P <jose...@gmail.com> wrote:
>>>>>
>>>>>> Upgrade on "prod like" went smooth :)
>>>>>> Could we move the question for behaviours closer to the behaviours
>>>>>> text?
>>>>>>
>>>>>>
>>>>>> <https://lh3.googleusercontent.com/-6ZYEdujPA6I/WU0Ut447ZXI/Bro/MO4YEevB3rAPfGAWqoJnqkqruXW26SBFACLcBGAs/s1600/shot_170623_151622.png>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Den torsdag den 22. juni 2017 kl. 08.10.41 UTC+2 skrev Joseph P:
>&

Re: GitHub and Bitbucket branch source UI refactoring

[Stephen Connolly]

Current thinking is the GA release will be Wednesday

On 10 July 2017 at 06:36, Joseph P <joseph...@gmail.com> wrote:

> ETA on Release?
>
> Den mandag den 26. juni 2017 kl. 18.13.07 UTC+2 skrev Stephen Connolly:
>>
>> On 26 June 2017 at 08:14, Joseph P <jose...@gmail.com> wrote:
>>
>>> This UI is a lot better! Looking forward to the massive upgrade!
>>>
>>> Just wondering with the refactoring will it be possible for PRs to
>>> rebuild when changes to target branch is notified?
>>> When the option for Merge PR with Target branch is selected.
>>>
>>> That would be AWESOME!
>>>
>>
>> So right now that would be a controversial feature...
>>
>> What I want to do is add the concept of interesting and non-interesting
>> revisions to SCM-API
>>
>> I feel that it is necessary to have that concept in order to enable
>> support for Tag discovery (because you certainly want old tags as
>> non-interesting, if not all tags as non-interesting)
>>
>> Then the idea would be that the Branch-API's multi-branch project would
>> not build non-interesting revisions by default.
>>
>> With the above changes then we could do things like:
>>
>> 1. Merge commits where only the target branch changes are non-interesting
>> (which is a win for the people who do not want build storms on indexing)
>> 2. Merge commits where the target branch changes are interesting (which
>> is what you want)
>>
>> With some of the other changes in SCM-API it would then be safe to add
>> multi-branch project triggering change requests when the target branch
>> changes because we'd have https://github.com/jenkinsci/s
>> cm-api-plugin/blob/master/src/main/java/jenkins/scm/api/mixi
>> n/ChangeRequestSCMHead.java#L57 and https://github.com/jenkins
>> ci/scm-api-plugin/blob/master/src/main/java/jenkins/scm/api/
>> mixin/ChangeRequestSCMHead2.java#L45 so we'd know that the checkout
>> strategy is merge and hence if https://github.com/jenkinsc
>> i/scm-api-plugin/blob/master/src/main/java/jenkins/scm/api/
>> mixin/ChangeRequestSCMRevision.java#L65 has changed then we should
>> re-fetch the effective head revision... and if it is interesting then we
>> can rebuild.
>>
>> At least that is my current thinking...
>>
>> But right now there are two camps of people:
>>
>>- Those who want the build storm
>>- Those who do not want the build storm
>>
>> Until I can satisfy both camps we will have to live with the current
>> "build storm only on indexing" situation.
>>
>>
>>>
>>>
>>> Den fredag den 23. juni 2017 kl. 15.32.54 UTC+2 skrev Stephen Connolly:
>>>>
>>>> How do you find the new UI compared with the previous one?
>>>>
>>>> On 23 June 2017 at 14:18, Joseph P <jose...@gmail.com> wrote:
>>>>
>>>>> Upgrade on "prod like" went smooth :)
>>>>> Could we move the question for behaviours closer to the behaviours
>>>>> text?
>>>>>
>>>>>
>>>>> <https://lh3.googleusercontent.com/-6ZYEdujPA6I/WU0Ut447ZXI/Bro/MO4YEevB3rAPfGAWqoJnqkqruXW26SBFACLcBGAs/s1600/shot_170623_151622.png>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Den torsdag den 22. juni 2017 kl. 08.10.41 UTC+2 skrev Joseph P:
>>>>>>
>>>>>> I will try and get around to testing it today.
>>>>>>
>>>>>> Den onsdag den 21. juni 2017 kl. 20.30.03 UTC+2 skrev Stephen
>>>>>> Connolly:
>>>>>>>
>>>>>>> How many people have been able to try this so far?
>>>>>>>
>>>>>>> On Tue 20 Jun 2017 at 14:52, Stephen Connolly <
>>>>>>> stephen.al...@gmail.com> wrote:
>>>>>>>
>>>>>>>> If you are chomping at the bit, here are all the binaries:
>>>>>>>>
>>>>>>>> https://www.dropbox.com/sh/47weboatdzus22w/AADNF_aBniOyEeQi9
>>>>>>>> MvM82sMa?dl=0
>>>>>>>>
>>>>>>>> SHA1 checksums:
>>>>>>>> d9c346ac8db497a35825c7dbbb934842a2bc429a  branch-api.hpi
>>>>>>>> 16da429f09fb585fd1d744809ee22c8d612fb62c
>>>>>>>> cloudbees-bitbucket-branch-source.hpi
>>>>>>>> 234fa8eb88dad3241d620bb0116dd12fb9decbba  git.hpi
>>>>>>>> a68

Re: [Proposal] Making all things Stapler more declarative

[Stephen Connolly]

Ok, so that people can see code rather than just yapping on the M-L (and
given that we seem to be OK with the annotation names)

https://github.com/stapler/stapler/pull/121

Is where I am working on this proposal. We can continue the discussion in
either place as appropriate (general comments here, specific comments on
specific details of the code in the PR)

On 7 July 2017 at 03:06, Stephen Connolly <stephen.alan.conno...@gmail.com>
wrote:

> Yes I was thinking that a custom javadoc handler would be useful.
> Especially as there are inheritance of facets and fragments that we'd want
> to see documented correctly.
>
> On 7 July 2017 at 02:37, Robert Sandell <rsand...@cloudbees.com> wrote:
>
>> I agree with Stephen here; adding methods seems risky and could break
>> existing plugins, at least in a backwards compat sense.
>>
>> But I at the same time do like the idea of getting javadoc for the facets
>> and fragments. So can we get both somehow?
>> E.g. if there is a @StaplerFacet("login") or @StaplerFragment("main") there
>> should be a corresponding
>>
>> @facet login the login page.
>> @fragment main add this to change the main part of the configuration page.
>>
>> in the javadoc of the class?
>>
>> /B
>>
>> 2017-07-06 13:16 GMT+02:00 Stephen Connolly <
>> stephen.alan.conno...@gmail.com>:
>>
>>>
>>>
>>> On 5 July 2017 at 18:10, Kohsuke Kawaguchi <k...@kohsuke.org> wrote:
>>>
>>>> FWIW, I've already discussed this offline with Stephen and I'm
>>>> generally +1.
>>>>
>>>> One suggestion I had for him is to consider using a Java method
>>>> definition instead of @StaplerFacet and @StaplerFragment. That is, instead
>>>> of this:
>>>>
>>>> @StaplerFacets({
>>>>   @StaplerFacet("index"),
>>>>   @StaplerFacet("config")
>>>> })
>>>> @StaplerFragments({
>>>>   @StaplerFragment("main"),
>>>>   @StaplerFragment("side-panel"),
>>>>   @StaplerFragment(value="tasks",optional=true)
>>>> })
>>>> public class Widget { ... }
>>>>
>>>> Consider that:
>>>>
>>>> public class Widget {
>>>> @StaplerFacet protected void index() {}
>>>> @StaplerFacet protected void config() {}
>>>>
>>>> @StaplerFragment protected abstract void main();
>>>> @StaplerFragment("side-panel") protected abstract void sidepanel();
>>>> @StaplerFragment protected void tasks();
>>>> }
>>>>
>>>>
>>> Well at least this is a better explanation than you gave me verbally ;-)
>>>
>>>
>>>> I liked this better because ...
>>>>
>>>>- It fits with the original design thinking behind Stapler, which
>>>>is that views are like methods. Their inheritance and override semantics
>>>>are all modeled after methods.
>>>>- It avoids a long list of @StaplerFragment/@StaplerFacet at the
>>>>top of the class declaration. We have some objects in the core that has
>>>>quite a few views.
>>>>
>>>> So let's see:
>>>
>>> $ ( cd core/src/main/resources ; find . -name \*.jelly -exec dirname {}
>>> \; ; find . -name \*.groovy -exec dirname {} \; ) | sort | uniq -c | grep
>>> -v ./lib/ | sort -n | tail -n 10
>>>7 ./hudson/model/AbstractProject
>>>7 ./hudson/slaves/SlaveComputer
>>>7 ./jenkins/install/SetupWizard
>>>9 ./hudson/model/Run
>>>   11 ./hudson/PluginManager
>>>   11 ./hudson/security/HudsonPrivateSecurityRealm
>>>   12 ./hudson/model/Job
>>>   13 ./hudson/model/View
>>>   14 ./hudson/model/Computer
>>>   25 ./jenkins/model/Jenkins
>>>
>>> So there are not altogether too many classes in Jenkins having lots of
>>> fragments / facets
>>>
>>> I think an argument based on a couple of really big classes like Jenkins
>>> having 25 lines of
>>>
>>> @StaplerObject
>>> @StaplerFacet("_restart")
>>> @StaplerFacet("_safeRestart")
>>> @StaplerFacet("_script")
>>> @StaplerFacet("_scriptText")
>>> @StaplerFacet("accessDenied")
>>> @StaplerFacet("configure")
>>> @StaplerFacet("configureExecutors")
>>> @StaplerFacet("fingerprintCheck&q

Re: [Proposal] Making all things Stapler more declarative

[Stephen Connolly]

Yes I was thinking that a custom javadoc handler would be useful.
Especially as there are inheritance of facets and fragments that we'd want
to see documented correctly.

On 7 July 2017 at 02:37, Robert Sandell <rsand...@cloudbees.com> wrote:

> I agree with Stephen here; adding methods seems risky and could break
> existing plugins, at least in a backwards compat sense.
>
> But I at the same time do like the idea of getting javadoc for the facets
> and fragments. So can we get both somehow?
> E.g. if there is a @StaplerFacet("login") or @StaplerFragment("main") there
> should be a corresponding
>
> @facet login the login page.
> @fragment main add this to change the main part of the configuration page.
>
> in the javadoc of the class?
>
> /B
>
> 2017-07-06 13:16 GMT+02:00 Stephen Connolly <stephen.alan.connolly@gmail.
> com>:
>
>>
>>
>> On 5 July 2017 at 18:10, Kohsuke Kawaguchi <k...@kohsuke.org> wrote:
>>
>>> FWIW, I've already discussed this offline with Stephen and I'm
>>> generally +1.
>>>
>>> One suggestion I had for him is to consider using a Java method
>>> definition instead of @StaplerFacet and @StaplerFragment. That is, instead
>>> of this:
>>>
>>> @StaplerFacets({
>>>   @StaplerFacet("index"),
>>>   @StaplerFacet("config")
>>> })
>>> @StaplerFragments({
>>>   @StaplerFragment("main"),
>>>   @StaplerFragment("side-panel"),
>>>   @StaplerFragment(value="tasks",optional=true)
>>> })
>>> public class Widget { ... }
>>>
>>> Consider that:
>>>
>>> public class Widget {
>>> @StaplerFacet protected void index() {}
>>> @StaplerFacet protected void config() {}
>>>
>>> @StaplerFragment protected abstract void main();
>>> @StaplerFragment("side-panel") protected abstract void sidepanel();
>>> @StaplerFragment protected void tasks();
>>> }
>>>
>>>
>> Well at least this is a better explanation than you gave me verbally ;-)
>>
>>
>>> I liked this better because ...
>>>
>>>- It fits with the original design thinking behind Stapler, which is
>>>that views are like methods. Their inheritance and override semantics are
>>>all modeled after methods.
>>>- It avoids a long list of @StaplerFragment/@StaplerFacet at the top
>>>of the class declaration. We have some objects in the core that has 
>>> quite a
>>>few views.
>>>
>>> So let's see:
>>
>> $ ( cd core/src/main/resources ; find . -name \*.jelly -exec dirname {}
>> \; ; find . -name \*.groovy -exec dirname {} \; ) | sort | uniq -c | grep
>> -v ./lib/ | sort -n | tail -n 10
>>7 ./hudson/model/AbstractProject
>>7 ./hudson/slaves/SlaveComputer
>>7 ./jenkins/install/SetupWizard
>>9 ./hudson/model/Run
>>   11 ./hudson/PluginManager
>>   11 ./hudson/security/HudsonPrivateSecurityRealm
>>   12 ./hudson/model/Job
>>   13 ./hudson/model/View
>>   14 ./hudson/model/Computer
>>   25 ./jenkins/model/Jenkins
>>
>> So there are not altogether too many classes in Jenkins having lots of
>> fragments / facets
>>
>> I think an argument based on a couple of really big classes like Jenkins
>> having 25 lines of
>>
>> @StaplerObject
>> @StaplerFacet("_restart")
>> @StaplerFacet("_safeRestart")
>> @StaplerFacet("_script")
>> @StaplerFacet("_scriptText")
>> @StaplerFacet("accessDenied")
>> @StaplerFacet("configure")
>> @StaplerFacet("configureExecutors")
>> @StaplerFacet("fingerprintCheck")
>> @StaplerFacet("legend")
>> @StaplerFacet("load-statistics")
>> @StaplerFacet("login")
>> @StaplerFacet("loginError")
>> @StaplerFacet("manag_")
>> @StaplerFacet("manage")
>> @StaplerFacet("newView")
>> @StaplerFacet("noPrincipal")
>> @StaplerFacet("oops")
>> @StaplerFacet("opensearch.xml")
>> @StaplerFacet("projectRelationship-help")
>> @StaplerFacet("projectRelationship")
>> @StaplerFacet("systemInfo")
>> @StaplerFacet("threadDump")
>> @StaplerFragment("_api")
>> @StaplerFragment("downgrade")
>> @StaplerFragment("sidepanel")
>> public class Jenkins {
&

ATTN: Plugin developers who use IntelliJ

[Stephen Connolly]

Please vote for https://youtrack.jetbrains.com/issue/IDEA-175538 if you
want to be able to plugin run unit tests from IntelliJ using recent
versions of the plugin parent.

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

Re: [Proposal] Making all things Stapler more declarative

[Stephen Connolly]

t with
subclasses...

If we add

@StaplerObject
public abstract class Descriptor ... {
  ...
  @StaplerFragment protected abstract void config(); // doesn't really
matter if abstract or not here
  ...
}

we may make it impossible for a concrete subclass to have a

public MyDescriptor extends Descriptor ... {

  private MyConfig config;

  ...

  public MyConfig config() {
return config.clone();
  }

}

as they will be unable to retain binary compatibility with their existing
"config" method when they upgrade...

So that means we will need to do

@StaplerObject
public abstract class Descriptor ... {
  ...
  @StaplerFragment @StaplerPath("config") protected abstract void
_retrofit_config();
  ...
}

Thinking some more, I see issues with plugin authors being thereby forced
to add implementations when they upgrade core... ok so they are quick and
the IDE will help... but having to add all those

public MyDescriptor extends Descriptor ... {

  private MyConfig config;

  ...

  public MyConfig config() {
return config.clone();
  }

  @StaplerFragment @StaplerPath("config") protected void _retrofit_config()
{}
}

All the while hoping that the IDE has copied the method annotations
(otherwise the method is not annotated) and the plugin author has not opted
into @StaplerObject yet

That, to me, does not make for a compelling developer experience.

WDYT?

I am inclined to reject your method based idea and stick with class level
annotations... there are only 11 classes in all of Jenkins core with more
than 5 facets / fragments


>- It creates a nice to place to describe view as javadoc.
>- 'abstract' and 'final' provides convenient semantics and javac does
>that work for us. One less thing to do for our annotation processor
>
> Obvious downside is that those are not real methods.
>
> On Mon, Jul 3, 2017 at 5:21 AM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> I have been developing Jenkins plugins and changes to Jenkins core for
>> more than 10 years now. As such, I have internalized a lot of the knowledge
>> about how to develop against Jenkins and more specifically against Stapler.
>>
>> When I talk to people trying to start out development against Jenkins,
>> the magic of Stapler seems to be a big source of confusion - at least to
>> the people I have talked to.
>>
>> Prospective developers get confused:
>>
>>- between primary facets and facet fragments.
>>- where to put facets and facet fragments.
>>- which facet fragments are optional and which ones are mandatory
>>
>> (Did you even know that those jelly / groovy views are called facets and
>> that there are two kinds?)
>>
>> Some of those concerns affect me too... but I am a seasoned Jenkins
>> developer CMD+SHIFT+P, *, ENTER and IntelliJ is showing me a full list of
>> facets and facet fragments from the class hierarchy and I can search each
>> one looking for the  to
>> discover that there is an optional facet fragment... and then try and dig
>> through the Jelly / Groovy logic to determine when and why that fragment
>> should be included.
>>
>> It doesn't just stop there... There are those methods that we expect
>> Stapler to invoke for us... typically they are the doFillXYZItems() or
>> doCheckXYZ() methods. I find myself having to mark them up like:
>>
>> @SuppressWarnings("unused") // stapler
>> public FormValidation doCheckWidgetValue(@QueryParameter String value) {
>> ...
>> }
>>
>>
>> So that my IDE stops complaining about the dead code. It's not a big deal
>> in the grand scheme of things, but I'd much rather have an annotation on
>> the method to signify that we expect the method to be used by stapler...
>> Right now I could do that using
>>
>> @WebMethod(name="checkWidgetValue")
>> public FormValidation doCheckWidgetValue(@QueryParameter String value) {
>> ...
>> }
>>
>>
>> If I don't like that, I guess I could use the newer HTTP verb annotations
>> in stapler:
>>
>> @GET // stapler
>> public FormValidation doCheckWidgetValue(@QueryParameter String value) {
>> ...
>> }
>>
>>
>> But the simple @GET is not screaming out stapler to me, so I feel
>> compelled to add a // stapler comment to remind myself that the
>> annotation is used by stapler
>>
>> Then we hit the actual name that stapler exposes things on. There are
>> some conventions that stapler follows... and they are magic conventions...
>> so much so that I just keep http://stapler.kohsuke.org/reference.html as
>> the first bookmark in my bookmark bar.
>>
>> I think w

Re: github-branch-source 2.0.7 hpi missing

[Stephen Connolly]

https://issues.jenkins-ci.org/browse/INFRA-1266 filed

On 6 July 2017 at 02:39, Stephen Connolly <stephen.alan.conno...@gmail.com>
wrote:

> Baptiste reports that https://updates.jenkins.io/download/plugins/gitlab-
> plugin/ is also missing... something is going on very strange
>
> On 6 July 2017 at 02:26, Stephen Connolly <stephen.alan.conno...@gmail.com
> > wrote:
>
>> Yes, very strange.. seems to be missing from upstream too:
>> https://updates.jenkins.io/download/plugins/
>>
>> On 6 July 2017 at 01:32, <chris.ev...@paxport.net> wrote:
>>
>>> Hi,
>>>
>>>
>>> looks like the hpi is missing from github-branch-source 2.0.7 (which is 
>>> offered in my jenkins updateCenter)
>>>
>>>
>>> java.io.FileNotFoundException: 
>>> http://mirrors.jenkins-ci.org/plugins/github-branch-source/2.0.7/github-branch-source.hpi
>>>
>>> --
>>> 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/ms
>>> gid/jenkinsci-users/7952599c-d928-4fae-8632-69acc5bf9c44%40g
>>> ooglegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-users/7952599c-d928-4fae-8632-69acc5bf9c44%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>

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

Re: github-branch-source 2.0.7 hpi missing

[Stephen Connolly]

Baptiste reports that
https://updates.jenkins.io/download/plugins/gitlab-plugin/ is also
missing... something is going on very strange

On 6 July 2017 at 02:26, Stephen Connolly <stephen.alan.conno...@gmail.com>
wrote:

> Yes, very strange.. seems to be missing from upstream too:
> https://updates.jenkins.io/download/plugins/
>
> On 6 July 2017 at 01:32, <chris.ev...@paxport.net> wrote:
>
>> Hi,
>>
>>
>> looks like the hpi is missing from github-branch-source 2.0.7 (which is 
>> offered in my jenkins updateCenter)
>>
>>
>> java.io.FileNotFoundException: 
>> http://mirrors.jenkins-ci.org/plugins/github-branch-source/2.0.7/github-branch-source.hpi
>>
>> --
>> 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/ms
>> gid/jenkinsci-users/7952599c-d928-4fae-8632-69acc5bf9c44%
>> 40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-users/7952599c-d928-4fae-8632-69acc5bf9c44%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [Proposal] Making all things Stapler more declarative

[Stephen Connolly]

+jenkins-dev

On 5 July 2017 at 02:13, Ullrich Hafner <ullrich.haf...@gmail.com> wrote:

>
> Am 04.07.2017 um 18:44 schrieb Stephen Connolly <
> stephen.alan.conno...@gmail.com>:
>
> Ulli,
>
> What do you think on this proposal, given that you have contact with a lot
> of students who have been trying to get to grips with the Jenkins code base.
>
> Would it make their task easier?
>
>
> Up to now most students work in the area of testing (ATH), so this will
> not help them (they would love to see IDs for all entry fields, but that is
> a totally different topic).
>

So one aspect where this could help is in knowing what to test.

The annotations can be used to help identify the intent of the plugin
author / core and we could perhaps even develop tooling to identify ATH
coverage


>
> -Stephen
>
> On 3 July 2017 at 05:21, Stephen Connolly <stephen.alan.conno...@gmail.com
> > wrote:
>
>> I have been developing Jenkins plugins and changes to Jenkins core for
>> more than 10 years now. As such, I have internalized a lot of the knowledge
>> about how to develop against Jenkins and more specifically against Stapler.
>>
>> When I talk to people trying to start out development against Jenkins,
>> the magic of Stapler seems to be a big source of confusion - at least to
>> the people I have talked to.
>>
>> Prospective developers get confused:
>>
>>- between primary facets and facet fragments.
>>- where to put facets and facet fragments.
>>- which facet fragments are optional and which ones are mandatory
>>
>>
>>
> This indeed is one of the most confusing things when developing plug-ins.
> It cost a lot of time to get these things right (mostly by copying and
> pasting code from another plugin).
>
> I'm not sure if annotations are the correct way of dealing with these
> problems. I think you then need to know where to put an annotation and
> where not, this will also result in searching for other plugins that do it
> right.
>

Yes, I would also propose improving the stapler documentation in
conjunction with these changes so that it should be easier to find the
"recommended" patterns to follow.

Though how much energy I personally have to push documentation improvements
is another question entirely ;-)


>
>
> (Did you even know that those jelly / groovy views are called facets and
>> that there are two kinds?)
>>
>> Some of those concerns affect me too... but I am a seasoned Jenkins
>> developer CMD+SHIFT+P, *, ENTER and IntelliJ is showing me a full list of
>> facets and facet fragments from the class hierarchy and I can search each
>> one looking for the  to
>> discover that there is an optional facet fragment... and then try and dig
>> through the Jelly / Groovy logic to determine when and why that fragment
>> should be included.
>>
>> It doesn't just stop there... There are those methods that we expect
>> Stapler to invoke for us... typically they are the doFillXYZItems() or
>> doCheckXYZ() methods. I find myself having to mark them up like:
>>
>> @SuppressWarnings("unused") // stapler
>> public FormValidation doCheckWidgetValue(@QueryParameter String value) {
>> ...
>> }
>>
>>
>> So that my IDE stops complaining about the dead code. It's not a big deal
>> in the grand scheme of things, but I'd much rather have an annotation on
>> the method to signify that we expect the method to be used by stapler...
>> Right now I could do that using
>>
>> @WebMethod(name="checkWidgetValue")
>> public FormValidation doCheckWidgetValue(@QueryParameter String value) {
>> ...
>> }
>>
>>
>> If I don't like that, I guess I could use the newer HTTP verb annotations
>> in stapler:
>>
>> @GET // stapler
>> public FormValidation doCheckWidgetValue(@QueryParameter String value) {
>> ...
>> }
>>
>>
>>
> But do these annotations help to get rid of the unused code warnings? I
> think you still need to add a @SuppressWarnings.
>

Well you can configure IDEs to say "this annotation is used" and we can
even have the Stapler plugin for IntelliJ pre-register the annotations so
that IntelliJ users (I'm selfish ;-) ) don't even need to add the setting


>
> But the simple @GET is not screaming out stapler to me, so I feel
>> compelled to add a // stapler comment to remind myself that the
>> annotation is used by stapler
>>
>> Then we hit the actual name that stapler exposes things on. There are
>> some conventions that stapler follows... and they are magic conventions...
>> 

Re: [Proposal] Making all things Stapler more declarative

[Stephen Connolly]

Actually I nearly forgot Oleg you were driving the Google summer of code
last year, what do you think?

On Tue 4 Jul 2017 at 17:44, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> Ulli,
>
> What do you think on this proposal, given that you have contact with a lot
> of students who have been trying to get to grips with the Jenkins code base.
>
> Would it make their task easier?
>
> -Stephen
>
> On 3 July 2017 at 05:21, Stephen Connolly <stephen.alan.conno...@gmail.com
> > wrote:
>
>> I have been developing Jenkins plugins and changes to Jenkins core for
>> more than 10 years now. As such, I have internalized a lot of the knowledge
>> about how to develop against Jenkins and more specifically against Stapler.
>>
>> When I talk to people trying to start out development against Jenkins,
>> the magic of Stapler seems to be a big source of confusion - at least to
>> the people I have talked to.
>>
>> Prospective developers get confused:
>>
>>- between primary facets and facet fragments.
>>- where to put facets and facet fragments.
>>- which facet fragments are optional and which ones are mandatory
>>
>> (Did you even know that those jelly / groovy views are called facets and
>> that there are two kinds?)
>>
>> Some of those concerns affect me too... but I am a seasoned Jenkins
>> developer CMD+SHIFT+P, *, ENTER and IntelliJ is showing me a full list of
>> facets and facet fragments from the class hierarchy and I can search each
>> one looking for the  to
>> discover that there is an optional facet fragment... and then try and dig
>> through the Jelly / Groovy logic to determine when and why that fragment
>> should be included.
>>
>> It doesn't just stop there... There are those methods that we expect
>> Stapler to invoke for us... typically they are the doFillXYZItems() or
>> doCheckXYZ() methods. I find myself having to mark them up like:
>>
>> @SuppressWarnings("unused") // stapler
>> public FormValidation doCheckWidgetValue(@QueryParameter String value) {
>> ...
>> }
>>
>>
>> So that my IDE stops complaining about the dead code. It's not a big deal
>> in the grand scheme of things, but I'd much rather have an annotation on
>> the method to signify that we expect the method to be used by stapler...
>> Right now I could do that using
>>
>> @WebMethod(name="checkWidgetValue")
>> public FormValidation doCheckWidgetValue(@QueryParameter String value) {
>> ...
>> }
>>
>>
>> If I don't like that, I guess I could use the newer HTTP verb annotations
>> in stapler:
>>
>> @GET // stapler
>> public FormValidation doCheckWidgetValue(@QueryParameter String value) {
>> ...
>> }
>>
>>
>> But the simple @GET is not screaming out stapler to me, so I feel
>> compelled to add a // stapler comment to remind myself that the
>> annotation is used by stapler
>>
>> Then we hit the actual name that stapler exposes things on. There are
>> some conventions that stapler follows... and they are magic conventions...
>> so much so that I just keep http://stapler.kohsuke.org/reference.html as
>> the first bookmark in my bookmark bar.
>>
>> I think we can do better. I think we should do better, and here is my
>> proposal.
>>
>> We should introduce some annotations. Make them available against older
>> versions of Jenkins so that we don't have to wait for everyone to update
>> their plugin baseline. The annotations can be added as a plugin dependency
>> in the parent pom, that everyone can use them just by upgrading the plugin
>> parent pom.
>>
>> Here are the class annotations I think we need:
>>
>>- An annotation (I propose @StaplerObject) that says "This object is
>>expected to bound to a URL by Stapler, the Stapler annotations are
>>complete, check that there are no facets / fragments without a
>>corresponding annotation and no magic on this class please" (so if there
>>is, say a rename.jelly but no @StaplerFacet("rename") or
>>@StaplerFragment("rename") then you get an error)
>>- An annotation (I propose @StaplerFacet and the repeatable container
>>@StaplerFacets) that says "Here are the facets that this object is
>>expected to have" (doesn't have to be on a @StaplerObject but when
>>not on a @StaplerObject we can only check for missing expected
>>facets, we cannot check for "unexpected" facets - i.e. I created a facet
>

Re: [Proposal] Making all things Stapler more declarative

[Stephen Connolly]

Ulli,

What do you think on this proposal, given that you have contact with a lot
of students who have been trying to get to grips with the Jenkins code base.

Would it make their task easier?

-Stephen

On 3 July 2017 at 05:21, Stephen Connolly <stephen.alan.conno...@gmail.com>
wrote:

> I have been developing Jenkins plugins and changes to Jenkins core for
> more than 10 years now. As such, I have internalized a lot of the knowledge
> about how to develop against Jenkins and more specifically against Stapler.
>
> When I talk to people trying to start out development against Jenkins, the
> magic of Stapler seems to be a big source of confusion - at least to the
> people I have talked to.
>
> Prospective developers get confused:
>
>- between primary facets and facet fragments.
>- where to put facets and facet fragments.
>- which facet fragments are optional and which ones are mandatory
>
> (Did you even know that those jelly / groovy views are called facets and
> that there are two kinds?)
>
> Some of those concerns affect me too... but I am a seasoned Jenkins
> developer CMD+SHIFT+P, *, ENTER and IntelliJ is showing me a full list of
> facets and facet fragments from the class hierarchy and I can search each
> one looking for the  to
> discover that there is an optional facet fragment... and then try and dig
> through the Jelly / Groovy logic to determine when and why that fragment
> should be included.
>
> It doesn't just stop there... There are those methods that we expect
> Stapler to invoke for us... typically they are the doFillXYZItems() or
> doCheckXYZ() methods. I find myself having to mark them up like:
>
> @SuppressWarnings("unused") // stapler
> public FormValidation doCheckWidgetValue(@QueryParameter String value) {
> ...
> }
>
>
> So that my IDE stops complaining about the dead code. It's not a big deal
> in the grand scheme of things, but I'd much rather have an annotation on
> the method to signify that we expect the method to be used by stapler...
> Right now I could do that using
>
> @WebMethod(name="checkWidgetValue")
> public FormValidation doCheckWidgetValue(@QueryParameter String value) {
> ...
> }
>
>
> If I don't like that, I guess I could use the newer HTTP verb annotations
> in stapler:
>
> @GET // stapler
> public FormValidation doCheckWidgetValue(@QueryParameter String value) {
> ...
> }
>
>
> But the simple @GET is not screaming out stapler to me, so I feel
> compelled to add a // stapler comment to remind myself that the
> annotation is used by stapler
>
> Then we hit the actual name that stapler exposes things on. There are some
> conventions that stapler follows... and they are magic conventions... so
> much so that I just keep http://stapler.kohsuke.org/reference.html as the
> first bookmark in my bookmark bar.
>
> I think we can do better. I think we should do better, and here is my
> proposal.
>
> We should introduce some annotations. Make them available against older
> versions of Jenkins so that we don't have to wait for everyone to update
> their plugin baseline. The annotations can be added as a plugin dependency
> in the parent pom, that everyone can use them just by upgrading the plugin
> parent pom.
>
> Here are the class annotations I think we need:
>
>- An annotation (I propose @StaplerObject) that says "This object is
>expected to bound to a URL by Stapler, the Stapler annotations are
>complete, check that there are no facets / fragments without a
>corresponding annotation and no magic on this class please" (so if there
>is, say a rename.jelly but no @StaplerFacet("rename") or
>@StaplerFragment("rename") then you get an error)
>- An annotation (I propose @StaplerFacet and the repeatable container
>@StaplerFacets) that says "Here are the facets that this object is
>expected to have" (doesn't have to be on a @StaplerObject but when not
>on a @StaplerObject we can only check for missing expected facets, we
>cannot check for "unexpected" facets - i.e. I created a facet with a
>spelling mistake or typo in the name)
>- An annotation (I propose @StaplerFragment and the repeatable
>container @StaplerFragments) that says "Here are the facet fragments
>that this object is required or may optionally have" (quite often will not
>be on a @StaplerObject)
>
>
> So I envision something like this (pre-Java 8):
>
> @StaplerObject
> @StaplerFacets({
>   @StaplerFacet("index"),
>   @StaplerFacet("config")
> })
> @StaplerFragments({
>   @StaplerFragment("main"),
>   @StaplerFra

[Proposal] Making all things Stapler more declarative

[Stephen Connolly]

I have been developing Jenkins plugins and changes to Jenkins core for more
than 10 years now. As such, I have internalized a lot of the knowledge
about how to develop against Jenkins and more specifically against Stapler.

When I talk to people trying to start out development against Jenkins, the
magic of Stapler seems to be a big source of confusion - at least to the
people I have talked to.

Prospective developers get confused:

   - between primary facets and facet fragments.
   - where to put facets and facet fragments.
   - which facet fragments are optional and which ones are mandatory

(Did you even know that those jelly / groovy views are called facets and
that there are two kinds?)

Some of those concerns affect me too... but I am a seasoned Jenkins
developer CMD+SHIFT+P, *, ENTER and IntelliJ is showing me a full list of
facets and facet fragments from the class hierarchy and I can search each
one looking for the  to
discover that there is an optional facet fragment... and then try and dig
through the Jelly / Groovy logic to determine when and why that fragment
should be included.

It doesn't just stop there... There are those methods that we expect
Stapler to invoke for us... typically they are the doFillXYZItems() or
doCheckXYZ() methods. I find myself having to mark them up like:

@SuppressWarnings("unused") // stapler
public FormValidation doCheckWidgetValue(@QueryParameter String value) {
...
}


So that my IDE stops complaining about the dead code. It's not a big deal
in the grand scheme of things, but I'd much rather have an annotation on
the method to signify that we expect the method to be used by stapler...
Right now I could do that using

@WebMethod(name="checkWidgetValue")
public FormValidation doCheckWidgetValue(@QueryParameter String value) {
...
}


If I don't like that, I guess I could use the newer HTTP verb annotations
in stapler:

@GET // stapler
public FormValidation doCheckWidgetValue(@QueryParameter String value) {
...
}


But the simple @GET is not screaming out stapler to me, so I feel compelled
to add a // stapler comment to remind myself that the annotation is used by
stapler

Then we hit the actual name that stapler exposes things on. There are some
conventions that stapler follows... and they are magic conventions... so
much so that I just keep http://stapler.kohsuke.org/reference.html as the
first bookmark in my bookmark bar.

I think we can do better. I think we should do better, and here is my
proposal.

We should introduce some annotations. Make them available against older
versions of Jenkins so that we don't have to wait for everyone to update
their plugin baseline. The annotations can be added as a plugin dependency
in the parent pom, that everyone can use them just by upgrading the plugin
parent pom.

Here are the class annotations I think we need:

   - An annotation (I propose @StaplerObject) that says "This object is
   expected to bound to a URL by Stapler, the Stapler annotations are
   complete, check that there are no facets / fragments without a
   corresponding annotation and no magic on this class please" (so if there
   is, say a rename.jelly but no @StaplerFacet("rename") or
   @StaplerFragment("rename") then you get an error)
   - An annotation (I propose @StaplerFacet and the repeatable container
   @StaplerFacets) that says "Here are the facets that this object is
   expected to have" (doesn't have to be on a @StaplerObject but when not
   on a @StaplerObject we can only check for missing expected facets, we
   cannot check for "unexpected" facets - i.e. I created a facet with a
   spelling mistake or typo in the name)
   - An annotation (I propose @StaplerFragment and the repeatable container
   @StaplerFragments) that says "Here are the facet fragments that this
   object is required or may optionally have" (quite often will not be on a
   @StaplerObject)


So I envision something like this (pre-Java 8):

@StaplerObject
@StaplerFacets({
  @StaplerFacet("index"),
  @StaplerFacet("config")
})
@StaplerFragments({
  @StaplerFragment("main"),
  @StaplerFragment("side-panel"),
  @StaplerFragment(value="tasks",optional=true)
})
public class Widget { ... }


When compiled targeting Java 8 this would become:

@StaplerObject
@StaplerFacet("index")
@StaplerFacet("config")
@StaplerFragment("main")
@StaplerFragment("side-panel")
@StaplerFragment(value="tasks",optional=true)
public class Widget { ... }


There would be an annotation processor that could do some checks:

   - If you add @StaplerFragment(..., optional=false) then any non-abstract
   class must have that fragment somewhere in the class hierarchy
   - If you add @StaplerFacet then any non-abstract class must have that
   fragment somewhere in the class hierarchy
   - If you add @StaplerObject then only the named facets and facet
   fragments must be present for that class (to catch somebody calling the
   facet resource with an incorrect name - it should be side-panel2.jelly
   but 

Anyone else seeing a -SNAPSHOT deployed as a release for gradle plugin?

[Stephen Connolly]

​

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

Re: Cannot upload plugin to release repository, while shapshot works

[Stephen Connolly]

Are you listed in the plugin repository permissions? if not file a PR
against https://github.com/jenkins-infra/repository-permissions-updater/

On 27 June 2017 at 07:16, Tomasz Jurkiewicz 
wrote:

> Hi,
>
> I get 401/Unauthorised upon uploading to release repository:
>
> tomekmbpro:incapptic-connect-uploader-plugin tomek$ /Applications/IntelliJ
> \ IDEA.app/Contents/plugins/maven/lib/maven3/bin/mvn release:perform
>
> ..
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-deploy-
> plugin:2.8.2:deploy (default-deploy) on project incapptic-connect-uploader
> : Failed to deploy artifacts: Could not transfer artifact com.incapptic.
> plugins:incapptic-connect-uploader:hpi:1.5 from/to maven.jenkins-ci.org (
> https://repo.jenkins-ci.org/releases/): Access denied to:
> https://repo.jenkins-ci.org/releases/com/incapptic/
> plugins/incapptic-connect-uploader/1.5/incapptic-connect-uploader-1.5.hpi,
> ReasonPhrase: Forbidden. -> [Help 1]
>
>
> uploading to snapshot with mvn deploy works. I have the ~/.m2/settings.xml
> filled with username & encrypted password revealed here:
> https://repo.jenkins-ci.org/webapp
>
> Here are the snapshot versions:
> https://repo.jenkins-ci.org/snapshots/com/incapptic/
> plugins/incapptic-connect-uploader/
>
> I assume that my password is ok, because without the settings.xml file, I
> cannot even do snapshot uploads.
>
> My plugin version is 2.11:
>
>
> 
>  org.jenkins-ci.plugins
>  plugin
>  2.11
>  
> 
>
>
>
>
> Cheers,
> Tomek
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/ac07bd62-90ce-45cd-b15f-b6479cff081b%
> 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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMypFxKZtGet4%2B-mPK1yNim%2BV__NWPqhbSZ%2B_YWJp%3DODiQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub and Bitbucket branch source UI refactoring

[Stephen Connolly]

On 26 June 2017 at 08:14, Joseph P <joseph...@gmail.com> wrote:

> This UI is a lot better! Looking forward to the massive upgrade!
>
> Just wondering with the refactoring will it be possible for PRs to rebuild
> when changes to target branch is notified?
> When the option for Merge PR with Target branch is selected.
>
> That would be AWESOME!
>

So right now that would be a controversial feature...

What I want to do is add the concept of interesting and non-interesting
revisions to SCM-API

I feel that it is necessary to have that concept in order to enable support
for Tag discovery (because you certainly want old tags as non-interesting,
if not all tags as non-interesting)

Then the idea would be that the Branch-API's multi-branch project would not
build non-interesting revisions by default.

With the above changes then we could do things like:

1. Merge commits where only the target branch changes are non-interesting
(which is a win for the people who do not want build storms on indexing)
2. Merge commits where the target branch changes are interesting (which is
what you want)

With some of the other changes in SCM-API it would then be safe to add
multi-branch project triggering change requests when the target branch
changes because we'd have
https://github.com/jenkinsci/scm-api-plugin/blob/master/src/main/java/jenkins/scm/api/mixin/ChangeRequestSCMHead.java#L57
and
https://github.com/jenkinsci/scm-api-plugin/blob/master/src/main/java/jenkins/scm/api/mixin/ChangeRequestSCMHead2.java#L45
so we'd know that the checkout strategy is merge and hence if
https://github.com/jenkinsci/scm-api-plugin/blob/master/src/main/java/jenkins/scm/api/mixin/ChangeRequestSCMRevision.java#L65
has changed then we should re-fetch the effective head revision... and if
it is interesting then we can rebuild.

At least that is my current thinking...

But right now there are two camps of people:

   - Those who want the build storm
   - Those who do not want the build storm

Until I can satisfy both camps we will have to live with the current "build
storm only on indexing" situation.


>
>
> Den fredag den 23. juni 2017 kl. 15.32.54 UTC+2 skrev Stephen Connolly:
>>
>> How do you find the new UI compared with the previous one?
>>
>> On 23 June 2017 at 14:18, Joseph P <jose...@gmail.com> wrote:
>>
>>> Upgrade on "prod like" went smooth :)
>>> Could we move the question for behaviours closer to the behaviours text?
>>>
>>>
>>> <https://lh3.googleusercontent.com/-6ZYEdujPA6I/WU0Ut447ZXI/Bro/MO4YEevB3rAPfGAWqoJnqkqruXW26SBFACLcBGAs/s1600/shot_170623_151622.png>
>>>
>>>
>>>
>>>
>>> Den torsdag den 22. juni 2017 kl. 08.10.41 UTC+2 skrev Joseph P:
>>>>
>>>> I will try and get around to testing it today.
>>>>
>>>> Den onsdag den 21. juni 2017 kl. 20.30.03 UTC+2 skrev Stephen Connolly:
>>>>>
>>>>> How many people have been able to try this so far?
>>>>>
>>>>> On Tue 20 Jun 2017 at 14:52, Stephen Connolly <stephen.al...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> If you are chomping at the bit, here are all the binaries:
>>>>>>
>>>>>> https://www.dropbox.com/sh/47weboatdzus22w/AADNF_aBniOyEeQi9
>>>>>> MvM82sMa?dl=0
>>>>>>
>>>>>> SHA1 checksums:
>>>>>> d9c346ac8db497a35825c7dbbb934842a2bc429a  branch-api.hpi
>>>>>> 16da429f09fb585fd1d744809ee22c8d612fb62c
>>>>>> cloudbees-bitbucket-branch-source.hpi
>>>>>> 234fa8eb88dad3241d620bb0116dd12fb9decbba  git.hpi
>>>>>> a68be01144f3045f81a5cf3c0bc60ad12f39b643  github-branch-source.hpi
>>>>>> 92237097815b45260bb8b272caa9be9f92eb5085  mercurial.hpi
>>>>>> 04c321420b3752a8d8b3af89cae1bf5934607b1c  scm-api.hpi
>>>>>>
>>>>>> SHA256 checksums:
>>>>>> 858ce20992c3f179b850c512979999084b11fe7c4c173cf6d4d2e07bbfebf3e7
>>>>>> branch-api.hpi
>>>>>> 8ebff7a3ec43df276d4b51d1e5bcb910bbe8eb4cd47a4be0e35f2f2ca1cd0e03
>>>>>> cloudbees-bitbucket-branch-source.hpi
>>>>>> 46cbbf11395df4a085829094d5a36dee7328aeba00d33e34b44aa0dcf9898248
>>>>>> git.hpi
>>>>>> 6495a60f1bf0733d807f412434c6c2e24b7bba53fd7ce348ca5319ef38571f20
>>>>>> github-branch-source.hpi
>>>>>> 173d12042fe8582efdb52e740f4e939b9daa05f181c6aaff31824337d519a31c
>>>>>> mercurial.hpi
>>>>>> 9b58e9e6d13ce90a91b73f38142bf0977f244df9c52b948988f9d5bdc3785481
>>>>

Re: GitHub and Bitbucket branch source UI refactoring

[Stephen Connolly]

On 26 June 2017 at 06:13, Kevin Burnett <kburn...@rosettastone.com> wrote:

> This is so good. :)
>

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


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

w00t


>
> I'm going to remove the "discover pull requests from [everywhere]"
> behaviors and select "Only branches that are also filed as PRs" on
> production as soon as possible.
>
> Michael Neale mentioned that one issue he had seen "does look better now
> with the new version." I used the plugin versions that Stephen originally
> posted on June 20, but I take Michael's comment to mean there might be
> newer versions. Please make this irrelevant by issuing release versions of
> these plugins this week. :)
>
> Thanks a ton!
> -KB
>
> On Friday, June 23, 2017 at 12:45:44 PM UTC-4, Stephen Connolly wrote:
>>
>>
>>
>> On 23 June 2017 at 17:24, Mark Waite <mark.ea...@gmail.com> wrote:
>>
>>> I see duplicate entries in the "Add' configuration of the Bitbucket
>>> source for "Checkout over ssh".  Let me know if you need steps to see that.
>>>
>>
>> Shouldn't... may just be a bug in the drop down populator when you have
>> GitHub and Bitbucket
>>
>>
>>>
>>> I also wonder if the text "General", "Git" and "Bitbucket" should be
>>> italicized, or bold, or separated with dashes, or something, so that the
>>> user has a concept that things will be appearing under them.  They seem to
>>> be standard text currently, and it wasn't obvious to me that they were
>>> categories into which settings would be placed.
>>>
>>
>> Cannot style the drop-down menu without significant JS changes that risk
>> affecting form binding.
>>
>>
>>>
>>> Mark Waite
>>>
>>>
>>> On Friday, June 23, 2017 at 9:58:52 AM UTC-6, Mark Waite wrote:
>>>>
>>>> The UI experience has been great for me in the two or three places
>>>> where I've used it.  I was a little surprised (and pleased) with the
>>>> adaptation that the local branch setting is now a toggle.  I think that's
>>>> the right approach, since (as far as I can tell) that is the 99% use case.
>>>>
>>>> Earlier I reported an NPE when configuring a multi-branch pipeline that
>>>> uses GitHub as source instead of Git as source.  The NPE was resolved by
>>>> removing the multiple-scms plugin.  Unfortunately, the 404 is still there,
>>>> along with a stack trace that starts with this:
>>>>
>>>> Jun 23, 2017 9:51:38 AM hudson.ExpressionFactory2$JexlExpression
>>>> evaluate
>>>> WARNING: Caught exception evaluating: 
>>>> descriptor.calcFillSettings(field,attrs)
>>>> in /job/Git-Client-Folder/job/git-client-pipeline-github/configure.
>>>> Reason: java.lang.IllegalStateException: class
>>>> org.jenkinsci.plugins.github_branch_source.GitHubSCMSource$DescriptorImpl
>>>> doesn't have the doFillCredentialsIdItems method for filling a drop-down
>>>> list
>>>> java.lang.IllegalStateException: class org.jenkinsci.plugins.github_b
>>>> ranch_source.GitHubSCMSource$DescriptorImpl doesn't have the
>>>> doFillCredentialsIdItems method for filling a drop-down list
>>>> at hudson.model.Descriptor.calcFillSettings(Descriptor.java:412)
>>>> at sun.reflect.GeneratedMethodAccessor578.invoke(Unknown Source)
>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>>>> thodAccessorImpl.java:43)
>>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>>> at org.apache.commons.jexl.util.introspection.UberspectImpl$Vel
>>>> MethodImpl.invoke(UberspectImpl.java:258)
>>>> at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:104)
>>>> at org.apache.commons.jexl.parser.ASTReference.execute(ASTRefer
>>>> ence.java:83)
>>>> at org.apache.commons.jexl.parser.ASTReference.value(ASTReferen
>>>> ce.java:57)
>>>> at org.apache.commons.jexl.parser.ASTReferenceExpression.value(
>>>> ASTReferenceExpression.java:51)
>>>> at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionIm
>>>> pl.java:80)
>>>> at hudson.ExpressionFactory2$JexlExpression.evaluate(Expression
>>>> Factory2.java:74)
>>>> at org.apache.commons.jelly.parser.EscapingExpression.evalua

Re: GitHub and Bitbucket branch source UI refactoring

[Stephen Connolly]

Check the drop-box link...
https://www.dropbox.com/sh/47weboatdzus22w/AADNF_aBniOyEeQi9MvM82sMa?dl=0 git,
mercurial, github and bitbucket are all up as far as -alpha-4

-alpha-4 is looking very near a beta release candidate (just need to
confirm I have all the code reviewers happy)

I will not be releasing the GA versions this week as we have some internal
quality bars that need to be met

On 26 June 2017 at 06:28, Michael Kobit <mko...@gmail.com> wrote:

> I'm going to have time to do this today. Are there newer alphas available?
>
> On Mon, Jun 26, 2017, 08:13 Kevin Burnett <kburn...@rosettastone.com>
> wrote:
>
>> This is so good. :)
>>
>> The pre and post diffs looked right, and the new UI and functionality
>> gives me everything that I was hoping for.
>>
>> I'm going to remove the "discover pull requests from [everywhere]"
>> behaviors and select "Only branches that are also filed as PRs" on
>> production as soon as possible.
>>
>> Michael Neale mentioned that one issue he had seen "does look better now
>> with the new version." I used the plugin versions that Stephen originally
>> posted on June 20, but I take Michael's comment to mean there might be
>> newer versions. Please make this irrelevant by issuing release versions of
>> these plugins this week. :)
>>
>> Thanks a ton!
>> -KB
>>
>> On Friday, June 23, 2017 at 12:45:44 PM UTC-4, Stephen Connolly wrote:
>>>
>>>
>>>
>>> On 23 June 2017 at 17:24, Mark Waite <mark.ea...@gmail.com> wrote:
>>>
>>>> I see duplicate entries in the "Add' configuration of the Bitbucket
>>>> source for "Checkout over ssh".  Let me know if you need steps to see that.
>>>>
>>>
>>> Shouldn't... may just be a bug in the drop down populator when you have
>>> GitHub and Bitbucket
>>>
>>>
>>>>
>>>> I also wonder if the text "General", "Git" and "Bitbucket" should be
>>>> italicized, or bold, or separated with dashes, or something, so that the
>>>> user has a concept that things will be appearing under them.  They seem to
>>>> be standard text currently, and it wasn't obvious to me that they were
>>>> categories into which settings would be placed.
>>>>
>>>
>>> Cannot style the drop-down menu without significant JS changes that risk
>>> affecting form binding.
>>>
>>>
>>
>>>> Mark Waite
>>>>
>>>>
>>>> On Friday, June 23, 2017 at 9:58:52 AM UTC-6, Mark Waite wrote:
>>>>>
>>>>> The UI experience has been great for me in the two or three places
>>>>> where I've used it.  I was a little surprised (and pleased) with the
>>>>> adaptation that the local branch setting is now a toggle.  I think that's
>>>>> the right approach, since (as far as I can tell) that is the 99% use case.
>>>>>
>>>>> Earlier I reported an NPE when configuring a multi-branch pipeline
>>>>> that uses GitHub as source instead of Git as source.  The NPE was resolved
>>>>> by removing the multiple-scms plugin.  Unfortunately, the 404 is still
>>>>> there, along with a stack trace that starts with this:
>>>>>
>>>>> Jun 23, 2017 9:51:38 AM hudson.ExpressionFactory2$JexlExpression
>>>>> evaluate
>>>>> WARNING: Caught exception evaluating: 
>>>>> descriptor.calcFillSettings(field,attrs)
>>>>> in /job/Git-Client-Folder/job/git-client-pipeline-github/configure.
>>>>> Reason: java.lang.IllegalStateException: class
>>>>> org.jenkinsci.plugins.github_branch_source.GitHubSCMSource$DescriptorImpl
>>>>> doesn't have the doFillCredentialsIdItems method for filling a drop-down
>>>>> list
>>>>> java.lang.IllegalStateException: class org.jenkinsci.plugins.github_
>>>>> branch_source.GitHubSCMSource$DescriptorImpl doesn't have the
>>>>> doFillCredentialsIdItems method for filling a drop-down list
>>>>> at hudson.model.Descriptor.calcFillSettings(Descriptor.java:412)
>>>>> at sun.reflect.GeneratedMethodAccessor578.invoke(Unknown Source)
>>>>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
>>>>> DelegatingMethodAccessorImpl.java:43)
>>>>> at java.lang.reflect.Method.invoke(Method.java:498)
>>>>> at org.apache.commons.jexl.util.introspection.UberspectImpl$
>>>>> 

Re: GitHub and Bitbucket branch source UI refactoring

[Stephen Connolly]

Phew! I found the bug in structs... and it is an easy fix...
https://issues.jenkins-ci.org/browse/JENKINS-45130 so no renaming of
classes required!

On 25 June 2017 at 01:49, Stephen Connolly <stephen.alan.conno...@gmail.com>
wrote:

> TL;DR keep the alpha's to throw-away instances until I identify whether I
> need to rename classes before the beta
>
> On Sun 25 Jun 2017 at 09:20, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> I have found an issue with how these plugins get their pipeline snippets
>> generated when all are installed an the same instance at the same time.
>>
>> Hopefully this is just a bug in the structs plugin and I can fix it
>> there...
>>
>> BUT if I cannot fix it in structs I WILL HAVE TO RENAME CLASSES before a
>> beta release.
>>
>> If I have to rename classes you will not be able to upgrade from -alpha
>> to -beta or GA as I cannot have the old classes present (but I will see if
>> I can find a way around)
>>
>> On Fri 23 Jun 2017 at 18:14, Mark Waite <mark.earl.wa...@gmail.com>
>> wrote:
>>
>>> On Fri, Jun 23, 2017 at 10:37 AM Jesse Glick <jgl...@cloudbees.com>
>>> wrote:
>>>
>>>> On Thu, Jun 22, 2017 at 8:02 PM, Mark Waite <mark.earl.wa...@gmail.com>
>>>> wrote:
>>>> > The git client plugin has tests which assume its branches are full
>>>> clones.
>>>> > It uses that assumption to reduce the setup time for submodule tests,
>>>> tests
>>>> > of tagging, and more.
>>>>
>>>> Wait, what? It is assuming that the tests are running in a
>>>> particularly configured checkout of the `git-client-plugin`
>>>> repository? That is certainly an antipattern. Tests should not even
>>>> assume that they are running in a Git checkout at all. Could just have
>>>> been a `cp -ar` from a source tree. Definitely worth cleaning this up
>>>> if I am understanding correctly what you are saying.
>>>>
>>>>
>>> I'm not sure I'd call it a "particularly configured checkout" since I
>>> generally consider "checkout" to be the results of a "git checkout", though
>>> I guess that is one way to describe it.
>>>
>>> Some of the current tests assume that the working repository is an
>>> accurate clone of the upstream repository from which it was cloned,
>>> including tags and remote branches (like tests/getSubmodules).  It was an
>>> easy way to test submodules, remote clones, and authentication, without
>>> having to construct repositories containing specific tags and submodules
>>> each time.
>>>
>>> Since it is an anti-pattern, I'll plan to systematically replace those
>>> dependencies with similar conditions constructed from within the tests
>>> themselves.
>>>
>>> Thanks,
>>> Mark Waite
>>>
>>>
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Jenkins Developers" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>>> To view this discussion on the web visit https://groups.google.com/d/
>>>> msgid/jenkinsci-dev/CANfRfr1hQ%2B2po6fcoM-
>>>> ba72GKat6uCng0xspFDWr3n9f5RK6EQ%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 Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/jenkinsci-dev/CAO49JtEtuUVcXG8q3WtZNMAA%3D-
>>> zr6DPnKDhVvCVewmrksS8Mew%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtEtuUVcXG8q3WtZNMAA%3D-zr6DPnKDhVvCVewmrksS8Mew%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> Sent from my phone
>>
> --
> Sent from my phone
>

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

Re: GitHub and Bitbucket branch source UI refactoring

[Stephen Connolly]

TL;DR keep the alpha's to throw-away instances until I identify whether I
need to rename classes before the beta

On Sun 25 Jun 2017 at 09:20, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I have found an issue with how these plugins get their pipeline snippets
> generated when all are installed an the same instance at the same time.
>
> Hopefully this is just a bug in the structs plugin and I can fix it
> there...
>
> BUT if I cannot fix it in structs I WILL HAVE TO RENAME CLASSES before a
> beta release.
>
> If I have to rename classes you will not be able to upgrade from -alpha to
> -beta or GA as I cannot have the old classes present (but I will see if I
> can find a way around)
>
> On Fri 23 Jun 2017 at 18:14, Mark Waite <mark.earl.wa...@gmail.com> wrote:
>
>> On Fri, Jun 23, 2017 at 10:37 AM Jesse Glick <jgl...@cloudbees.com>
>> wrote:
>>
>>> On Thu, Jun 22, 2017 at 8:02 PM, Mark Waite <mark.earl.wa...@gmail.com>
>>> wrote:
>>> > The git client plugin has tests which assume its branches are full
>>> clones.
>>> > It uses that assumption to reduce the setup time for submodule tests,
>>> tests
>>> > of tagging, and more.
>>>
>>> Wait, what? It is assuming that the tests are running in a
>>> particularly configured checkout of the `git-client-plugin`
>>> repository? That is certainly an antipattern. Tests should not even
>>> assume that they are running in a Git checkout at all. Could just have
>>> been a `cp -ar` from a source tree. Definitely worth cleaning this up
>>> if I am understanding correctly what you are saying.
>>>
>>>
>> I'm not sure I'd call it a "particularly configured checkout" since I
>> generally consider "checkout" to be the results of a "git checkout", though
>> I guess that is one way to describe it.
>>
>> Some of the current tests assume that the working repository is an
>> accurate clone of the upstream repository from which it was cloned,
>> including tags and remote branches (like tests/getSubmodules).  It was an
>> easy way to test submodules, remote clones, and authentication, without
>> having to construct repositories containing specific tags and submodules
>> each time.
>>
>> Since it is an anti-pattern, I'll plan to systematically replace those
>> dependencies with similar conditions constructed from within the tests
>> themselves.
>>
>> Thanks,
>> Mark Waite
>>
>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to jenkinsci-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1hQ%2B2po6fcoM-ba72GKat6uCng0xspFDWr3n9f5RK6EQ%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 Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtEtuUVcXG8q3WtZNMAA%3D-zr6DPnKDhVvCVewmrksS8Mew%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtEtuUVcXG8q3WtZNMAA%3D-zr6DPnKDhVvCVewmrksS8Mew%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> Sent from my phone
>
-- 
Sent from my phone

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

Re: GitHub and Bitbucket branch source UI refactoring

[Stephen Connolly]

I have found an issue with how these plugins get their pipeline snippets
generated when all are installed an the same instance at the same time.

Hopefully this is just a bug in the structs plugin and I can fix it there...

BUT if I cannot fix it in structs I WILL HAVE TO RENAME CLASSES before a
beta release.

If I have to rename classes you will not be able to upgrade from -alpha to
-beta or GA as I cannot have the old classes present (but I will see if I
can find a way around)

On Fri 23 Jun 2017 at 18:14, Mark Waite  wrote:

> On Fri, Jun 23, 2017 at 10:37 AM Jesse Glick  wrote:
>
>> On Thu, Jun 22, 2017 at 8:02 PM, Mark Waite 
>> wrote:
>> > The git client plugin has tests which assume its branches are full
>> clones.
>> > It uses that assumption to reduce the setup time for submodule tests,
>> tests
>> > of tagging, and more.
>>
>> Wait, what? It is assuming that the tests are running in a
>> particularly configured checkout of the `git-client-plugin`
>> repository? That is certainly an antipattern. Tests should not even
>> assume that they are running in a Git checkout at all. Could just have
>> been a `cp -ar` from a source tree. Definitely worth cleaning this up
>> if I am understanding correctly what you are saying.
>>
>>
> I'm not sure I'd call it a "particularly configured checkout" since I
> generally consider "checkout" to be the results of a "git checkout", though
> I guess that is one way to describe it.
>
> Some of the current tests assume that the working repository is an
> accurate clone of the upstream repository from which it was cloned,
> including tags and remote branches (like tests/getSubmodules).  It was an
> easy way to test submodules, remote clones, and authentication, without
> having to construct repositories containing specific tags and submodules
> each time.
>
> Since it is an anti-pattern, I'll plan to systematically replace those
> dependencies with similar conditions constructed from within the tests
> themselves.
>
> Thanks,
> Mark Waite
>
>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr1hQ%2B2po6fcoM-ba72GKat6uCng0xspFDWr3n9f5RK6EQ%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 Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtEtuUVcXG8q3WtZNMAA%3D-zr6DPnKDhVvCVewmrksS8Mew%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Sent from my phone

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

Re: Question: Git Branch Source and the traits / behaviours

[Stephen Connolly]

On 23 June 2017 at 17:43, Jesse Glick <jgl...@cloudbees.com> wrote:

> On Fri, Jun 23, 2017 at 9:29 AM, Stephen Connolly
> <stephen.alan.conno...@gmail.com> wrote:
> > That means we would have to grandfather in the discovery of branches.
> >
> > So if we read a GitSCMSource from disk and it has no discovery traits we
> > would then assume it is not configured thus by the user intent on it
> being
> > in the stupid state... rather they want to discover branches
>
> Surely there is some sort of `readResolve` that will get called during
> this big-bang migration and you can use that as the place to insert
> the “Discover Branches” trait.
>

The point is that we cannot - unlike for the 3.3.0 -> 3.4.0 readResolve -
rely on the traits field being null... instead we would need to introduce
some "version" field in order to determine that this was a pre-discovery
trait instance vs a post-discovery trait instance where the discover
branches trait is explicitly excluded and some other discovery trait was
added from an extension plugin


>
> > the constructor would have to always add the discovery trait from the
> start
>
> That seems like the expected behavior to me—a natural default.
>
> I am questioning why we need a “Discover Branches” trait at all. Is
> there some use case for discovering tags but _not_ branches? I cannot
> think of any. Which argues for a single “Discover Tags” trait, absent
> by default, hence no problems here. If and when some weird person
> really decides they need this, you could always add a “Do Not Discover
> Branches” trait.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/CANfRfr35R0NYv1vRZXCFU3HvtJxgw
> j2ctnDLh8D_JJs07s_wiw%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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwYgE3vUpZvdqMk7e6muZh7XLHUWq%3Dp3CpOAr9%2BwsyMRA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Question: Git Branch Source and the traits / behaviours

[Stephen Connolly]

On 23 June 2017 at 17:46, Jesse Glick  wrote:

> …or, if and when implementing that RFE, introduce a single trait
> “Customize Discovered References” which would have its own checkboxes
> for branches, tags, and maybe even some sort of pattern match for refs
> or whatever.
>

God no... we are not going back to checkbox hell


>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/CANfRfr0HQX_fcZk3Q7CLVwEzrgB7wTF0HM-Tnb4o%
> 2BugqMH4Y7g%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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMx1ykS49NZSrKRk-QFZH8pUKO%2BHnX7Qs0BMD7UP0UkmcQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Question: Git Branch Source and the traits / behaviours

[Stephen Connolly]

On 23 June 2017 at 17:43, Jesse Glick <jgl...@cloudbees.com> wrote:

> On Fri, Jun 23, 2017 at 9:29 AM, Stephen Connolly
> <stephen.alan.conno...@gmail.com> wrote:
> > That means we would have to grandfather in the discovery of branches.
> >
> > So if we read a GitSCMSource from disk and it has no discovery traits we
> > would then assume it is not configured thus by the user intent on it
> being
> > in the stupid state... rather they want to discover branches
>
> Surely there is some sort of `readResolve` that will get called during
> this big-bang migration and you can use that as the place to insert
> the “Discover Branches” trait.
>
> > the constructor would have to always add the discovery trait from the
> start
>
> That seems like the expected behavior to me—a natural default.
>
> I am questioning why we need a “Discover Branches” trait at all. Is
> there some use case for discovering tags but _not_ branches? I cannot
> think of any. Which argues for a single “Discover Tags” trait, absent
> by default, hence no problems here. If and when some weird person
> really decides they need this, you could always add a “Do Not Discover
> Branches” trait.
>

But ultimately I want to make the Discover Branches trait shared across
all... in which case since GitHub and Bitbucket already have that trait the
counter-trait would be non-intuitive


>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/CANfRfr35R0NYv1vRZXCFU3HvtJxgw
> j2ctnDLh8D_JJs07s_wiw%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 Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMx6aDxq2TDM_nSkBh%2BW6QNr-29eijmM3Lukr_Ub_M3FjA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GitHub and Bitbucket branch source UI refactoring

[Stephen Connolly]

On 23 June 2017 at 17:24, Mark Waite <mark.earl.wa...@gmail.com> wrote:

> I see duplicate entries in the "Add' configuration of the Bitbucket source
> for "Checkout over ssh".  Let me know if you need steps to see that.
>

Shouldn't... may just be a bug in the drop down populator when you have
GitHub and Bitbucket


>
> I also wonder if the text "General", "Git" and "Bitbucket" should be
> italicized, or bold, or separated with dashes, or something, so that the
> user has a concept that things will be appearing under them.  They seem to
> be standard text currently, and it wasn't obvious to me that they were
> categories into which settings would be placed.
>

Cannot style the drop-down menu without significant JS changes that risk
affecting form binding.


>
> Mark Waite
>
>
> On Friday, June 23, 2017 at 9:58:52 AM UTC-6, Mark Waite wrote:
>>
>> The UI experience has been great for me in the two or three places where
>> I've used it.  I was a little surprised (and pleased) with the adaptation
>> that the local branch setting is now a toggle.  I think that's the right
>> approach, since (as far as I can tell) that is the 99% use case.
>>
>> Earlier I reported an NPE when configuring a multi-branch pipeline that
>> uses GitHub as source instead of Git as source.  The NPE was resolved by
>> removing the multiple-scms plugin.  Unfortunately, the 404 is still there,
>> along with a stack trace that starts with this:
>>
>> Jun 23, 2017 9:51:38 AM hudson.ExpressionFactory2$JexlExpression evaluate
>> WARNING: Caught exception evaluating: 
>> descriptor.calcFillSettings(field,attrs)
>> in /job/Git-Client-Folder/job/git-client-pipeline-github/configure.
>> Reason: java.lang.IllegalStateException: class
>> org.jenkinsci.plugins.github_branch_source.GitHubSCMSource$DescriptorImpl
>> doesn't have the doFillCredentialsIdItems method for filling a drop-down
>> list
>> java.lang.IllegalStateException: class org.jenkinsci.plugins.github_b
>> ranch_source.GitHubSCMSource$DescriptorImpl doesn't have the
>> doFillCredentialsIdItems method for filling a drop-down list
>> at hudson.model.Descriptor.calcFillSettings(Descriptor.java:412)
>> at sun.reflect.GeneratedMethodAccessor578.invoke(Unknown Source)
>> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
>> thodAccessorImpl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498)
>> at org.apache.commons.jexl.util.introspection.UberspectImpl$Vel
>> MethodImpl.invoke(UberspectImpl.java:258)
>> at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:104)
>> at org.apache.commons.jexl.parser.ASTReference.execute(ASTRefer
>> ence.java:83)
>> at org.apache.commons.jexl.parser.ASTReference.value(ASTReferen
>> ce.java:57)
>> at org.apache.commons.jexl.parser.ASTReferenceExpression.value(
>> ASTReferenceExpression.java:51)
>> at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionIm
>> pl.java:80)
>> at hudson.ExpressionFactory2$JexlExpression.evaluate(Expression
>> Factory2.java:74)
>> at org.apache.commons.jelly.parser.EscapingExpression.evaluate(
>> EscapingExpression.java:24)
>> at org.apache.commons.jelly.impl.ExpressionScript.run(Expressio
>> nScript.java:66)
>> at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
>>
>> I'm not sure how to provide a repeatable condition for that bug yet, but
>> wanted to alert you about it.  I won't investigate further on it until
>> after the end of the working day today.
>>
>> Mark Waite
>>
>> On Friday, June 23, 2017 at 7:32:54 AM UTC-6, Stephen Connolly wrote:
>>>
>>> How do you find the new UI compared with the previous one?
>>>
>>> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/c2e110d7-f929-461d-8595-273e8e543d89%
> 40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/c2e110d7-f929-461d-8595-273e8e543d89%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Question: Git Branch Source and the traits / behaviours

[Stephen Connolly]

Doesn't look too bad in the default new-instance state:

[image: Inline images 1]

I'll roll a new set of alpha's after I finish writing the migration tests

On 23 June 2017 at 15:24, Joseph P <joseph...@gmail.com> wrote:

> Adding discover branch trait makes a lot of sense when other traits will
> join in.
> So take the migration part now.
>
> And if your need more vertical space, just flip your monitor into
> porTrait.. pun intended. :D
>
>
> Den fredag den 23. juni 2017 kl. 15.29.20 UTC+2 skrev Stephen Connolly:
>>
>> So before we cut a GA release of the JENKINS-43507 changes I thought it
>> might be a good idea to resolve one question.
>>
>> To understand the context of this, we first need to acknowledge
>> https://issues.jenkins-ci.org/browse/JENKINS-33445
>>
>> There are some users who would like the *Branch* source to also return
>> *Tag*s
>>
>> Now in a sense this is perfectly reasonable. I think there are some
>> things that need to be ironed out first before we can enable discovery of
>> tags. To give an example, you probably do not want to trigger a build storm
>> of all your old tags if you recreate the multibranch project... in fact if
>> you were using the pipeline to deploy to production when it detects the
>> build is on a tag... this would be a very bad plan.
>>
>> So before we enable the discovery of tags, we need to solve some
>> problems...
>>
>> But now, let's take it as read that we have solved those problems... this
>> means that the Git source could be configured into one of four possible
>> states:
>>
>>1. Stupid state: discovers nothing
>>2. Branches only
>>3. Tags only
>>4. Both branches and tags
>>
>> The natural way, given the conventions in the GitHub and Bitbucket
>> behaviours / traits is that we would have one behaviour for discovering
>> branches and one for discovering tags...
>>
>> Well right now GitSCMSource has neither, it just discovers branches
>> always.
>>
>> That means we would have to grandfather in the discovery of branches.
>>
>> So if we read a GitSCMSource from disk and it has no discovery traits we
>> would then assume it is not configured thus by the user intent on it being
>> in the stupid state... rather they want to discover branches... the
>> constructor would have to always add the discovery trait from the start and
>> people would need to configure away branch discovery... it seems like a bit
>> of a mess to me.
>>
>> So what I am thinking is that we just add a Git specific "Discover
>> Branches" behaviour to the plugin before the 3.4.0 GA release. The legacy
>> constructor would inject it as would readResolve and the UI would always
>> propose it when creating via the UI
>>
>> It does mean that the UI will always start with Discover Branches present
>> (taking up vertical space that is effectively useless until we get Discover
>> Tags) but I think it will make the addition of Discover Tags much less risky
>>
>> WDYT?
>>
>> -Stephen
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/c76e7027-5bbc-42f4-9ee6-bc2fa1eed920%
> 40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/c76e7027-5bbc-42f4-9ee6-bc2fa1eed920%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: Question: Git Branch Source and the traits / behaviours

[Stephen Connolly]

On 23 June 2017 at 14:50, Mark Waite <mark.earl.wa...@gmail.com> wrote:

>
>
> On Fri, Jun 23, 2017 at 7:29 AM Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> So before we cut a GA release of the JENKINS-43507 changes I thought it
>> might be a good idea to resolve one question.
>>
>> To understand the context of this, we first need to acknowledge
>> https://issues.jenkins-ci.org/browse/JENKINS-33445
>>
>> There are some users who would like the *Branch* source to also return
>> *Tag*s
>>
>> Now in a sense this is perfectly reasonable. I think there are some
>> things that need to be ironed out first before we can enable discovery of
>> tags. To give an example, you probably do not want to trigger a build storm
>> of all your old tags if you recreate the multibranch project... in fact if
>> you were using the pipeline to deploy to production when it detects the
>> build is on a tag... this would be a very bad plan.
>>
>> So before we enable the discovery of tags, we need to solve some
>> problems...
>>
>> But now, let's take it as read that we have solved those problems... this
>> means that the Git source could be configured into one of four possible
>> states:
>>
>>1. Stupid state: discovers nothing
>>2. Branches only
>>3. Tags only
>>4. Both branches and tags
>>
>> The natural way, given the conventions in the GitHub and Bitbucket
>> behaviours / traits is that we would have one behaviour for discovering
>> branches and one for discovering tags...
>>
>> Well right now GitSCMSource has neither, it just discovers branches
>> always.
>>
>> That means we would have to grandfather in the discovery of branches.
>>
>> So if we read a GitSCMSource from disk and it has no discovery traits we
>> would then assume it is not configured thus by the user intent on it being
>> in the stupid state... rather they want to discover branches... the
>> constructor would have to always add the discovery trait from the start and
>> people would need to configure away branch discovery... it seems like a bit
>> of a mess to me.
>>
>> So what I am thinking is that we just add a Git specific "Discover
>> Branches" behaviour to the plugin before the 3.4.0 GA release. The legacy
>> constructor would inject it as would readResolve and the UI would always
>> propose it when creating via the UI
>>
>> It does mean that the UI will always start with Discover Branches present
>> (taking up vertical space that is effectively useless until we get Discover
>> Tags) but I think it will make the addition of Discover Tags much less risky
>>
>> WDYT?
>>
>>
> I like the idea very much.  It gives a simple place to extend the user
> interface in the future, and moves towards allowing independent treatment
> of tags and branches.
>
> I just had a discussion (in a pull request) with someone who wants to
> treat a newly tagged SHA1 as meaning "build this again, even if it was
> built before".  I'm not very fond of that particular use model, since the
> git plugin treats a SHA1 that has already been built as "done", and that
> use model says it is the combination of SHA1 and tag which is "done", but I
> believe that I understand it.
>
> I that that a user might do that, since there is meaning in a tag, and one
> meaning may include "build this tag, whether or not you've built this SHA1
> before".
>

Well this is where some of the ideas I have about pre-changes prior to
enabling tag discovery land... and also that I suspect tag discovery may
have more than one behaviour / trait implementation and the different
implementations being provided by different plugins

But the GitSCMSource needs to come from a place where it is enabled in
advance for this support


>
>
>> -Stephen
>>
>

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