Plugin testers / early adopters

[Tony Noble]

Apologies if I'm way off track or asking something there's a well known
answer to, but:

Is there a mailing list or group for end users who are willing to test
incremental builds of plugins and report back?

In this instance, I'm at the point where I'm ready to release the
XTrigger-lib-related plugins (urltrigger, fstrigger, ivytrigger etc) which
have been updated to use the newly-released XTrigger-API plugin, which in
turn has been updated to use the EnvInject-API plugin instead of EnvInject
lib.  In theory, this is a non-breaking change, as no functionality of
configuration should be changing, but obviously under the hood, it's pretty
significant.

I'm updating the versions of the plugins from 0.xx to 1.xx to signify a
major update, but is there anything else I can do to lessen any potential
shock to end-users?  If an 'early adopter' group exists, that would be
ideal, but any other suggestions would be welcome.

Tony

-- 
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/CAEWqh9GNsDVkaBu4s0SJsZ1hFLD0HL%3DrVGhw4Jvuw4cf4fGZpQ%40mail.gmail.com.

Re: Certificate expiry error on get.jenkins.io

[Tony Noble]

Thanks - it looks like we might have something caching old certificates
then.  Apologies for the false alarm...


On Wed, Dec 8, 2021 at 5:11 PM 'Gavin Mogan' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Maybe someone restarted the service already. As far as I can tell is valid
> - https://www.sslshopper.com/ssl-checker.html#hostname=get.jenkins.io
>
> On Wed, Dec 8, 2021 at 9:03 AM Tony Noble  wrote:
>
>> Looks like the previous certificate expiry issues are still in place on
>> the above host:
>>
>> tmp>wget https://get.jenkins.io/war-stable/2.303.3/jenkins.war
>>
>> --2021-12-08 17:02:03--
>> https://get.jenkins.io/war-stable/2.303.3/jenkins.war
>> Resolving get.jenkins.io (get.jenkins.io)... 52.167.253.43
>> Connecting to get.jenkins.io (get.jenkins.io)|52.167.253.43|:443...
>> connected.
>> ERROR: cannot verify get.jenkins.io's certificate, issued by
>> ‘/C=US/O=Let's Encrypt/CN=R3’:
>>   Issued certificate has expired.
>> To connect to get.jenkins.io insecurely, use `--no-check-certificate'.
>> /tmp>
>>
>> Is there anyone with access to take a look?
>>
>> --
>> 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/CAEWqh9HEpsGSvpDCStdcCrmWBD0tjfyO%3Da27SpdrQojk%3DRY%3DeA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAEWqh9HEpsGSvpDCStdcCrmWBD0tjfyO%3Da27SpdrQojk%3DRY%3DeA%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/CAG%3D_DusX9ZzHyvpAb%3D0MFNYjXov3cE9gseDHgY%2Bv1fXAn9JnnA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAG%3D_DusX9ZzHyvpAb%3D0MFNYjXov3cE9gseDHgY%2Bv1fXAn9JnnA%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/CAEWqh9GCEBxjD5A7ACWvn7iVau6qtaLLTi7McdcONfYibiMVfw%40mail.gmail.com.

Certificate expiry error on get.jenkins.io

[Tony Noble]

Looks like the previous certificate expiry issues are still in place on the
above host:

tmp>wget https://get.jenkins.io/war-stable/2.303.3/jenkins.war

--2021-12-08 17:02:03--
https://get.jenkins.io/war-stable/2.303.3/jenkins.war
Resolving get.jenkins.io (get.jenkins.io)... 52.167.253.43
Connecting to get.jenkins.io (get.jenkins.io)|52.167.253.43|:443...
connected.
ERROR: cannot verify get.jenkins.io's certificate, issued by ‘/C=US/O=Let's
Encrypt/CN=R3’:
  Issued certificate has expired.
To connect to get.jenkins.io insecurely, use `--no-check-certificate'.
/tmp>

Is there anyone with access to take a look?

-- 
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/CAEWqh9HEpsGSvpDCStdcCrmWBD0tjfyO%3Da27SpdrQojk%3DRY%3DeA%40mail.gmail.com.

Re: [workflow-durable-task-step-plugin] Add tool installer for Powershell Core

[Tony Noble]

"The `ToolInstallation` system is generally deprecated."

Out of interest, how long has this been the case?  For a number of reasons,
pre-built and configured VMs or containers have not been an option for us
and the ability to make tools available on demand for development teams'
builds is pretty key to the service we provide.

In an Enterprise environment with a lot of historical software (and years
of technical debt that can't quickly be fixed), the availability of
different versions of Maven, Ant, Java and similar for building is pretty
important.  And pre-installing them on every single worker VM is simply not
practical.  Similarly, neither is installing every new version of every
tool on every VM.


On Tue, May 25, 2021 at 11:42 PM Tim Van Holder 
wrote:

> I'll have another look at that plugin - at first glance, it seems to have
> hardcoded assumptions on Windows vs Linux.
> And the point here is to have tool installations for specific PowerShell (
> *not* Windows PowerShell) versions downloaded and deployed from GitHub
> releases, regardless of platform.
>
> As for the build wrapper, the pwsh step seems to resist proper selection
> of which shell to run.
> In a freestyle job, the wrapper works. But that's because it only has
> equivalents of bat and sh. Running pwsh from those uses the executable from
> the selected tool installation just fine.
>
> However, in a pipeline, a pwsh step inside the wrapper seems to forcibly
> put "C:\Program Files\PowerShell\7" at the start of PATH, overriding what
> the wrapper put in place.
> That feels broken to me - even using a tool section has no effect.
> It would also be counterintuitive to have to use sh/bat steps to be able
> to use a tool-based pwsh installation (and the whole point of using a pwsh
> step would be to not have to care whether it's linux/osx/windows/...).
>
> And yes, something like JENKINS-28718
>  would remove the need
> for more specific withXXX wrappers - but that proposal as-is seems to
> assume installation names are globally unique - and it is my understanding
> they're only unique within a particular installation type. For example, I
> might have both a PowerShell installation named 'LTS' and a .NET SDK
> installation named 'LTS', so "withTool('LTS') { }" would be ambiguous.
> Also, an installation's setup is not necessarily limited to just a home
> folder, so $(tool 'XXX') might only handle part of what's needed for a
> given tool.
>
>
> On Mon, 24 May 2021 at 17:40, Jesse Glick  wrote:
>
>> On Fri, May 21, 2021 at 5:51 PM Tim Van Holder 
>> wrote:
>>
>>> PowerShell Core is multi-platform and installable via zip or tarball.
>>> As such, I'd be inclined to want to add a tool installer for it
>>>
>>
>> The `ToolInstallation` system is generally deprecated. Modern CI setups
>> are expected to use VMs or containers with appropriate tools preinstalled.
>> So I would probably recommend creating a separate plugin for the likely
>> small number of users who would benefit. Or better yet, just check whether
>> the existing plugin
>> 
>>  works
>> for you.
>>
>>
>>> a withPwsh (or withPowerShellCore?) step would also make sense, to put a
>>> particular install in PATH for a delimited set of steps (as I understand
>>> it, with the tool section, it always applies to an entire stage)
>>>
>>
>> There is limited flexibility in Declarative syntax. For Scripted syntax,
>> this just sounds like it would be better covered by the general
>> JENKINS-28718 . A
>> dedicated block-scoped step makes sense for logic that does something more
>> complicated than bind a `ToolInstallation` to a `$PATH` entry.
>>
>> --
>> 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/CANfRfr2Q66ArFPTDY2V8eeQn3t4AR_8giQc%3DtsptoDX5n5e8aQ%40mail.gmail.com
>> 
>> .
>>
> --
> 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/CAKMi--BZwB%2BL6T6SXvuat9QjVnB5STF3iX1qJLxPHbqfJQqgWw%40mail.gmail.com
> 
> .
>

-- 
You 

AbstractProjects, BuildableItems and Parameterized builds

[Tony Noble]

Looking to see if I can get a quick answer, before I spend much more time
googling the wrong terms.

While accepting PRs to modernize xtrigger-lib, one contributor helpfully
sorted the move from using AbstractProjects to BuildableItems, including
the code to actually schedule a build of the triggered job, which went from:

abstractProject.scheduleBuild(...)
to
hudson.model.Queue.getInstance().schedule(...)

This all seems to work, except in its handling of parameterised builds -
the old method happily scheduled builds with the default parameters set,
but the new one leaves them all null.  So the question is:  Is there a
guide anywhere on moving between these two in a way that takes care of
this, or is there a quick and simple way of detecting whether a build is
parameterised, so I can then add the default values to the actions when
scheduling it?  So far, I'm not having much luck...

-- 
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/CAEWqh9FY-qydrWOdX_%3DDVwwyfRj4Uko3N1js%2B9X9vPB2a4zrJw%40mail.gmail.com.

Re: XTrigger-Lib needs maintenance/release

[Tony Noble]

I looked at what you'd done with EnvInject when working on XTrigger and did
wonder what the reasons for your approach were - and did spot the caveats.

My intention is to draw a line in the sand for XTrigger and all components
that use it - the lib setup will be kept on a branch for security fixes
only, the same will apply for dependent trigger plugins.  Development from
here onwards will depend on the current LTS (2.277, I think?) as a minimum
and any future releases of urltrigger, fstrigger etc will be in turn
dependent on that.

I didn't plan to have the new repo require the old one, merely to leave the
old one mothballed as a reference.  I suppose that suggests a rename is the
best option - if you could sort that, it would be much appreciated.

Thanks,

Tony


On Sun, May 16, 2021 at 1:02 PM Oleg Nenashev 
wrote:

> There should be no infra issues with renaming, so it is totally your
> choice based on your preference
>
> FTR I created a separate repo for EnvInject API plugin when working on
> pluginizing EnvInject Lib. I did that because I wanted to retain
> binary/XStream compatibility, but did not want to bring the legacy
> AbstractProject only API into the new plugin. Not sure it is a case for you
> Toby, but for me it caused big overhead due to the need to maintain a chain
> of dependent components.
>
>
>
> On Sun, May 16, 2021, 13:18 Tony Noble  wrote:
>
>> Hi Oleg,
>>
>> I'm keeping as much of the codebase as possible and the revision history,
>> though obviously the structure has changed somewhat.  Happy to rename the
>> existing repo and run a maintenance branch for xtrigger-lib, as long as
>> that can be done without breaking any existing linkages and the artifact
>> permissions system can cope with two different things pointing to the same
>> repo?
>>
>> Tony
>>
>> On Sun, May 16, 2021 at 6:12 AM Oleg Nenashev 
>> wrote:
>>
>>> Hi Tony,
>>>
>>> Thanks a lot for working on it! In this case I would be happy to just
>>> create a repo for you. Before we do so, what do you think about just
>>> renaming https://github.com/jenkinsci/xtrigger-lib ? It might be a more
>>> convenient approach if you keep the most of the codebase and do not need
>>> the old library implementation anymore.
>>>
>>> Best regards,
>>> Oleg
>>>
>>>
>>> On Sun, May 16, 2021, 01:23 Tony Noble  wrote:
>>>
>>>> Dredging up an old conversation - apologies
>>>>
>>>> I've had chance to do some work on xtrigger-lib and convert to a
>>>> plugin, removing its dependency on envinject-lib in the process.  I have a
>>>> project xtrigger-api-plugin ready to go, so really just a query as to what
>>>> the next step is - do I need to create my own repo which is then forked /
>>>> moved into jenkinsci org, or is it possible to just create an empty repo
>>>> and make me maintainer / owner?
>>>>
>>>> I assume artifact upload permissions will also need to be sorted, but
>>>> from memory that requires the github repo to exist first?
>>>>
>>>> Cheers,
>>>>
>>>> Tony
>>>>
>>>> On Mon, Dec 2, 2019 at 9:37 AM Tony Noble  wrote:
>>>>
>>>>> Brilliant, thanks :0)
>>>>>
>>>>>
>>>>> On Mon, Dec 2, 2019 at 7:39 AM Ullrich Hafner <
>>>>> ullrich.haf...@gmail.com> wrote:
>>>>>
>>>>>> I added you as committer to the repositories.
>>>>>>
>>>>>> Am 02.12.2019 um 00:04 schrieb Tony Noble :
>>>>>>
>>>>>> Late follow-up, apologies.
>>>>>>
>>>>>> Now I have time to look at outstanding PRs / Jira tickets, I still
>>>>>> don't appear to have owner access to the following git repos:
>>>>>>
>>>>>>    -
>>>>>>- ScriptTrigger Plugin
>>>>>><https://wiki.jenkins.io/display/JENKINS/ScriptTrigger+Plugin> -
>>>>>>https://github.com/jenkinsci/scripttrigger-plugin
>>>>>>- BuildResultTrigger Plugin
>>>>>><https://wiki.jenkins.io/display/JENKINS/BuildResultTrigger+Plugin> 
>>>>>> (a.k.a
>>>>>>JobTrigger) - https://github.com/jenkinsci/buildresult-trigger
>>>>>>-plugin
>>>>>>
>>>>>>
>>>>>> All other access appears to be sorted, however.
>>>>>>
>>>>>> Can someone assist?

Re: XTrigger-Lib needs maintenance/release

[Tony Noble]

Hi Oleg,

I'm keeping as much of the codebase as possible and the revision history,
though obviously the structure has changed somewhat.  Happy to rename the
existing repo and run a maintenance branch for xtrigger-lib, as long as
that can be done without breaking any existing linkages and the artifact
permissions system can cope with two different things pointing to the same
repo?

Tony

On Sun, May 16, 2021 at 6:12 AM Oleg Nenashev 
wrote:

> Hi Tony,
>
> Thanks a lot for working on it! In this case I would be happy to just
> create a repo for you. Before we do so, what do you think about just
> renaming https://github.com/jenkinsci/xtrigger-lib ? It might be a more
> convenient approach if you keep the most of the codebase and do not need
> the old library implementation anymore.
>
> Best regards,
> Oleg
>
>
> On Sun, May 16, 2021, 01:23 Tony Noble  wrote:
>
>> Dredging up an old conversation - apologies
>>
>> I've had chance to do some work on xtrigger-lib and convert to a plugin,
>> removing its dependency on envinject-lib in the process.  I have a project
>> xtrigger-api-plugin ready to go, so really just a query as to what the next
>> step is - do I need to create my own repo which is then forked / moved into
>> jenkinsci org, or is it possible to just create an empty repo and make me
>> maintainer / owner?
>>
>> I assume artifact upload permissions will also need to be sorted, but
>> from memory that requires the github repo to exist first?
>>
>> Cheers,
>>
>> Tony
>>
>> On Mon, Dec 2, 2019 at 9:37 AM Tony Noble  wrote:
>>
>>> Brilliant, thanks :0)
>>>
>>>
>>> On Mon, Dec 2, 2019 at 7:39 AM Ullrich Hafner 
>>> wrote:
>>>
>>>> I added you as committer to the repositories.
>>>>
>>>> Am 02.12.2019 um 00:04 schrieb Tony Noble :
>>>>
>>>> Late follow-up, apologies.
>>>>
>>>> Now I have time to look at outstanding PRs / Jira tickets, I still
>>>> don't appear to have owner access to the following git repos:
>>>>
>>>>-
>>>>- ScriptTrigger Plugin
>>>><https://wiki.jenkins.io/display/JENKINS/ScriptTrigger+Plugin> -
>>>>https://github.com/jenkinsci/scripttrigger-plugin
>>>>- BuildResultTrigger Plugin
>>>><https://wiki.jenkins.io/display/JENKINS/BuildResultTrigger+Plugin> 
>>>> (a.k.a
>>>>JobTrigger) - https://github.com/jenkinsci/buildresult-trigger
>>>>-plugin
>>>>
>>>>
>>>> All other access appears to be sorted, however.
>>>>
>>>> Can someone assist?
>>>>
>>>> Tony
>>>>
>>>>-
>>>>
>>>>
>>>> On Fri, Jul 26, 2019 at 1:47 PM Oleg Nenashev 
>>>> wrote:
>>>>
>>>>> done. Was waiting for more confirmations, but it got stalled
>>>>>
>>>>> On Fri, Jul 26, 2019 at 2:37 PM Tony Noble 
>>>>> wrote:
>>>>>
>>>>>> Pull request looks to have been approved, but not applied - can
>>>>>> anyone assist?
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Tony
>>>>>>
>>>>>> On Sun, Jul 21, 2019 at 1:35 PM Tony Noble 
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks Oleg,
>>>>>>>
>>>>>>> Pull request created:
>>>>>>> https://github.com/jenkins-infra/repository-permissions-updater/pull/1233
>>>>>>>
>>>>>>> Tony
>>>>>>>
>>>>>>> On Sun, Jul 21, 2019 at 9:50 AM Oleg Nenashev <
>>>>>>> o.v.nenas...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hi Tony,
>>>>>>>>
>>>>>>>> I have granted you write access and made you a default assignee in
>>>>>>>> the components.
>>>>>>>> If you decide  to become a maintainer of the EnvInject stuff, I
>>>>>>>> will be happy to grant your permissions as well.
>>>>>>>>
>>>>>>>> Some notes:
>>>>>>>>
>>>>>>>>- To release the components, you will need to create a pull
>>>>>>>>request to
>>>>>>>>https://github.com/jenkins-infra/repository-permissions-updater
>

Re: XTrigger-Lib needs maintenance/release

[Tony Noble]

Dredging up an old conversation - apologies

I've had chance to do some work on xtrigger-lib and convert to a plugin,
removing its dependency on envinject-lib in the process.  I have a project
xtrigger-api-plugin ready to go, so really just a query as to what the next
step is - do I need to create my own repo which is then forked / moved into
jenkinsci org, or is it possible to just create an empty repo and make me
maintainer / owner?

I assume artifact upload permissions will also need to be sorted, but from
memory that requires the github repo to exist first?

Cheers,

Tony

On Mon, Dec 2, 2019 at 9:37 AM Tony Noble  wrote:

> Brilliant, thanks :0)
>
>
> On Mon, Dec 2, 2019 at 7:39 AM Ullrich Hafner 
> wrote:
>
>> I added you as committer to the repositories.
>>
>> Am 02.12.2019 um 00:04 schrieb Tony Noble :
>>
>> Late follow-up, apologies.
>>
>> Now I have time to look at outstanding PRs / Jira tickets, I still don't
>> appear to have owner access to the following git repos:
>>
>>-
>>- ScriptTrigger Plugin
>><https://wiki.jenkins.io/display/JENKINS/ScriptTrigger+Plugin> -
>>https://github.com/jenkinsci/scripttrigger-plugin
>>- BuildResultTrigger Plugin
>><https://wiki.jenkins.io/display/JENKINS/BuildResultTrigger+Plugin> (a.k.a
>>JobTrigger) - https://github.com/jenkinsci/buildresult-trigger-plugin
>>
>>
>> All other access appears to be sorted, however.
>>
>> Can someone assist?
>>
>> Tony
>>
>>-
>>
>>
>> On Fri, Jul 26, 2019 at 1:47 PM Oleg Nenashev 
>> wrote:
>>
>>> done. Was waiting for more confirmations, but it got stalled
>>>
>>> On Fri, Jul 26, 2019 at 2:37 PM Tony Noble  wrote:
>>>
>>>> Pull request looks to have been approved, but not applied - can anyone
>>>> assist?
>>>>
>>>> Cheers,
>>>>
>>>> Tony
>>>>
>>>> On Sun, Jul 21, 2019 at 1:35 PM Tony Noble 
>>>> wrote:
>>>>
>>>>> Thanks Oleg,
>>>>>
>>>>> Pull request created:
>>>>> https://github.com/jenkins-infra/repository-permissions-updater/pull/1233
>>>>>
>>>>> Tony
>>>>>
>>>>> On Sun, Jul 21, 2019 at 9:50 AM Oleg Nenashev 
>>>>> wrote:
>>>>>
>>>>>> Hi Tony,
>>>>>>
>>>>>> I have granted you write access and made you a default assignee in
>>>>>> the components.
>>>>>> If you decide  to become a maintainer of the EnvInject stuff, I will
>>>>>> be happy to grant your permissions as well.
>>>>>>
>>>>>> Some notes:
>>>>>>
>>>>>>- To release the components, you will need to create a pull
>>>>>>    request to
>>>>>>https://github.com/jenkins-infra/repository-permissions-updater
>>>>>>- ColMelvin <https://github.com/ColMelvin> has contributed a lot
>>>>>>of patches which have not been released yet. IIRC I reviewed them 1 
>>>>>> year
>>>>>>ago, but nobody took ownership at that point. Some area for 
>>>>>> collaboration
>>>>>>there, maybe
>>>>>>- For plugin you plan to maintain in longer term, it might make
>>>>>>sense to use Release Drafter for changelogs (docs
>>>>>>
>>>>>> <https://github.com/jenkinsci/.github/blob/master/.github/release-drafter.adoc>
>>>>>>)
>>>>>>
>>>>>> Best regards,
>>>>>> Oleg
>>>>>>
>>>>>> On Saturday, July 20, 2019 at 9:30:49 PM UTC+2, Tony Noble wrote:
>>>>>>>
>>>>>>> Okay, so modifications:
>>>>>>>
>>>>>>> - No need to add me as maintainer for envinject-lib
>>>>>>> - XTrigger-lib plugin replacement will be named XTrigger-api-plugin
>>>>>>>
>>>>>>> On that basis, if someone could add me as maintainer for the rest,
>>>>>>> it'd be much appreciated.
>>>>>>>
>>>>>>> Tony
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jul 20, 2019 at 7:15 PM Oleg Nenashev 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> My pl

Re: Jenkins Terminology cleanup continued - sub-terms for controllers

[Tony Noble]

In other projects, I've seen whitelist/blacklist moved to
allowlist/denylist, which *should* translate without context, I'd have
thought.  permit/block would seem to be the other possible analog.

Tony

On Tue, May 4, 2021 at 4:24 PM Oleg Nenashev  wrote:

> Re allowlistt vs. permitlist, I am happy to follow the suggestion of
> native speakers
>
>
> On Tue, May 4, 2021 at 5:21 PM Tim Jacomb  wrote:
>
>> > "Serialization whetelist" for JEP-200 => "serialization permit list"
>>
>> Any thoughts on allow list rather than permit? Permit sounds a bit funny
>> to me
>>
>> On Tue, 4 May 2021 at 15:59, Oleg Nenashev 
>> wrote:
>>
>>> Based on the current feedback, the following terminology is suggested:
>>>
>>>- Master node => "Built-in Node"
>>>- "master" label => "builtin" // We will need to keep master for
>>>compatibility reasons, but it can be deprecated and maybe even hidden 
>>> from
>>>UI
>>>- “Master branch” in documentation and help => "default branch"
>>>- Agent-to-Master security => " Agent-to-Controller security "
>>>- "Jenkins master container " => "Jenkins controller container"
>>>- "Jenkins master pod" => "Jenkins controller pod" // That still
>>>sounds a bit fishy since "controller" is a term in K8s
>>>- "Serialization whetelist" for JEP-200 => "serialization permit
>>>list"
>>>
>>> Any objections regarding these terms?
>>>
>>> On Monday, April 26, 2021 at 6:22:20 PM UTC+2 Oleg Nenashev wrote:
>>>
 Dear all,

 Thanks to everyone who contributed their ideas in the sub-term
 definitions list
 .
 We've got a number of ideas and identified the missing terms where we need
 decisions. Most notable ones which require discussion:

- Jenkins as node
- Jenkins “main node” label - Aligned with “Jenkins as node”
- Jenkins master pod - for K8s components
- “Master branch” in documentation, not the repository layout

 I suggest we continue the discussion and finalize the term decisions at
 the next governance meeting on May 05. I encourage all contributors to
 review the doc, vote for terms and let us know if you see any term missing.
 Hopefully we could build a consensus before th governance meeting happens.

 Thanks for your time,
 Oleg Nenashev


 On Tuesday, April 20, 2021 at 12:42:14 PM UTC+2 Oleg Nenashev wrote:

> Dear all,
>
> As discussed in the Jenkins chats, we would like to continue the
> terminology definitions we agreed on in 2020. Just to summarize the status
> from this thread
> 
> and the related announcements:
>
>- We adopted "controller" as a term to define the main Jenkins
>instance which acts as a web interface and the Jenkins system 
> controller
>(context, agent controller, endpoint for CLI and REST API, etc.). 
> Formerly
>known as "master", yes
>- We agreed that localizations for the term are to be reviewed on
>a case-by-case basis by maintainers and localization leaders.
>Recommendations for German, French, Spanish, Chinese, Italian and 
> Russian
>are defined here
>
> 
>.
>- We agreed to follow-up on the naming for sub-entities of the
>controller instance: e.g. Web interface, Jenkins as a "main" node, 
> labels,
>etc. This follow-up has not happened yet...
>
> In this thread I suggest to finally agree on terms for the third item
> so that we could ensure that all patches use the same terminology. It is
> *VERY* important, because such sub-entity terms are widespread in the
> Jenkins Web UI. For example, a screenshot from Danioel Beck:
>
> [image: image.png]
>
> I have started a table for sub-entity terms here
> ,
> this document is open for any suggestions. We kindly invite all interested
> contributors to:
>
>- Help us identify areas where "controller"/"master" terms need to
>be amended. These terms might be used inside the Jenkins core or in any
>other Jenkins components: docs, plugins, etc. Whatever you see, let's 
> fix
>that
>- Come up with term proposals or comment on already proposed ones
>
> Thanks in advance to all contributors!
>
> Best regards,
> Oleg Nenashev
> Jenkins Governance Board
>
>
> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Jenkins Developers" group.
>>> To unsubscribe from this group and 

Re: Terminology Updates

[Tony Noble]

Another vote for allowlist/denylist (or blocklist).

Controller/Agent is a sensible replacement for the master/slave paradigm
and has the benefit of being self-describing.  I don't see that there
should be any confusion between Jenkins controller and Kubernetes
controller any more than there would be with any other type of controller.
"Server" should apply to the host, IMO.

Tony

On Wed, Jun 17, 2020 at 3:30 PM Oleg Nenashev 
wrote:

> I started a Google Doc to capture proposals and votes
>
> https://docs.google.com/document/d/1-8myIWOZZktR0HNtbFIiNA0RfDCvkfKKuNI0C3wcvbo/edit?usp=sharing
>
>
> On Wednesday, June 17, 2020 at 12:30:47 AM UTC+2, Tammy Fox wrote:
>>
>> +1 for allowlist/denylist to be consistent with what other communities
>> are using.
>>
>> I have 3 suggestions to replace Master:
>>
>> 1. Director
>> 2. Expeditor
>> 3. Coordinator
>>
>> Thoughts? I was thinking about what a Master does, and it seems similar
>> to the Expeditor in a restaurant kitchen. The Master getting build requests
>> and sending it to the individual build agents is similar to an Expeditor
>> sending different items to the different food stations in a restaurant.
>>
>> On Tuesday, June 16, 2020 at 4:05:58 PM UTC-4 Tracy Miranda wrote:
>>
>>> Good discussion on 'master' replacement - listening and learning
>>>
>>> On the other terminology I vote allowlist/denylist.
>>> This is also consistent with other projects communities e.g.
>>> Rails/Kubernetes
>>> https://github.com/rails/rails/issues/33677
>>> https://github.com/kubernetes/website/pull/21591
>>>
>>> Tracy
>>>
>>>
>>> On Tue, Jun 16, 2020 at 1:30 PM Justin Harringa 
>>> wrote:
>>>
 Conductor is a cool suggestion!

 On Mon, Jun 15, 2020, 2:49 PM Adrien Lecharpentier <
 adrien.lec...@gmail.com> wrote:

> I have to say that the music parallel from Angelique seems nice and
> has a lot of sense in my opinion.
> And the Jenkins butler is not that far from a music orchestrator as
> well.
>
> Le lun. 15 juin 2020 à 22:47, Daniel Beck  a écrit :
>
>>
>>
>> > On 15. Jun 2020, at 22:39, Markus Winter  wrote:
>> >
>> > Second the server is also just plain agent (more or less). For this
>> we
>> > could use the term "main"  as the default label.
>>
>> That's what I proposed earlier in the thread as well.
>>
>> 'main' seems reasonable, but still has the connotation that it's
>> actually a good idea to use this node, when it rarely is.
>>
>> --
>> 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/300611FD-062F-40B8-9292-8E16170ABDE6%40beckweb.net
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/CLR55wMZwZ8/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-de...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAKwJSvwus_DLMT%3Dn2vxwpHya-Cn24qNRU%2B2bDbrKQBOyYL25yw%40mail.gmail.com
> 
> .
>
 --
 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/CAOa798WubmTKAqcV_bKtN0jSVUKNV%3DaSxfhybqPcSP%3D8tqHynA%40mail.gmail.com
 
 .

>>> --
> 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/a12075ca-48e0-4c55-bc8b-0eee84a210d3o%40googlegroups.com
> 
> .
>

-- 
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 

Re: Prevent building branches/PRs existing before the first branch indexing (Branch API plugin)

[Tony Noble]

I'm confused.

As far as I was aware, the 'Suppress automatic SCM triggering' property
already does what you require - branches will be indexed, but no builds
will ever be triggered by an SCM poll

Or perhaps there's three different requirements here - as I've already
said, I'm a big fan of the "different behaviour on first indexing"
approach, but it looks like your requirement is a little more specific.



On Fri, Apr 24, 2020 at 1:39 PM Adam Gabryś  wrote:

> @Liam Newman
>
> It is impossible to implement in a nice way a new strategy without
> changing the BranchBuildStrategy
> 
> class. I have access only to stuff, which are listed there. I wouldn't like
> not to implement a class which requires to configure job name, and next use
> Jenkins API to get the item by name etc.
>
> "Skip Build on First Job Indexing" is not enough. Users are able to
> configure indexing on regular basics (for example once per day). It is
> useful, if a webhook is not delivered, then on thenext day developers may
> execute the job from Jenkins UI. Without indexing the branch in such case
> will never be available.
>
> I think the cleanest solution is to pass information about the build
> reason to the strategy (indexing or event). This gives ability to implement
> simple strategies like "SkipBuildOnJobIndexing" or more advanced if any
> body needed. For us and I think most of the people "SkipBuildOnJobIndexing"
> is enough (probably most of the people use hooks instead of polling).
>
>
> @Daniel Beck
>
> The BranchBuildStrategy
> 
>  class
> gives access to SCMHead, so you are able to get a branch name. There is no
> information about the build cause.
>
>
> @Joh Brohauge
>
> My solution works, but it is not clean. As I wrote above, the cleanest
> solution is to add a build cause to the BranchBuildStrategy
> 
>  class.
> Then people may implement simple and complex strategies required by them.
>
> Finally, we have exactly the same situation as you, I provide CI as a
> Service, I don't own or influence teams repositories.
>
> --
> 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/418b55ff-2ea3-4f23-9f30-5bf2571d3dff%40googlegroups.com
> 
> .
>

-- 
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/CAEWqh9H18La%3DaZvbp%3DzCGbr%2BGSHF4mmLBdVb_phTueTqxd-UHA%40mail.gmail.com.

Re: Prevent building branches/PRs existing before the first branch indexing (Branch API plugin)

[Tony Noble]

This gets my vote - exactly the sequence that I've wished existed for some
time now.



On Thu, Apr 23, 2020 at 8:55 PM Liam Newman  wrote:

>
> Adam,
> I think the feature/behavior you're suggesting is definitely worth
> implementing.  It would let people safely create new projects without
> dealing with build storms.
>
> So to reiterate - the behavior we're looking for is:
>
>1. Project is created
>2. Branches are indexed, but not built
>3. Polling (or hooks) now enabled
>4. Scheduled indexing now auto-builds new branches if selected. Hooks
>will trigger builds
>
> You mentioned SkipInitialBuildOnFirstBranchIndexing
> 
>  .
> I think something like that is way to go here.  Only instead of disabling
> the "first indexing of each branch", it would be "Skip Build on First Job
> Indexing".  I know there are several possible ways ways to detect the state
> "this is the first time a project has been indexed", but I'm not
> sufficiently knowledgable to be able to point you to the exact right spot.
> Sorry. But I firmly believe this should be doable without changing the SCM
> or Branch API.  We just need to do some digging to find it.
>
> Sound good?
>
> -L.
>
> On Sunday, April 19, 2020 at 7:44:47 AM UTC-7, Adam Gabryś wrote:
>>
>> There are two strategies for building PRs:
>> 1) test PR before the merge operation - the same as building the source
>> branch
>> 2) test PR after the (virtual) merge operation - presents the state after
>> merging
>>
>> We use a second strategy, because the source branch could work
>> standalone, but break everything with the latest changes.
>>
>> It means that if we force developers to create a draft PR to just execute
>> a build, they will have to:
>> * create a new branch from the branch which is interesting for them
>> * create a PR from the new branch to the existing branch
>> I don't believe any developer would like to use such flow.
>>
>> > correct but it will build interesting branches not dangling ones.
>>
>> I'm confused about these "interesting" branches and filtering by regex.
>> In my company people use Git-Flow
>> . Branches are
>> created to work on new features or bug fixes. I would classify all code
>> changes as interesting to execute on the CI.
>>
> --
> 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/9c8b5674-4d91-4b31-927c-2981ffac0112%40googlegroups.com
> 
> .
>

-- 
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/CAEWqh9GZnZmCg-0RekFQ_0PuJWHbho8GrQ3sMiRGoNb_MMtu1w%40mail.gmail.com.

Re: Prevent building branches/PRs existing before the first branch indexing (Branch API plugin)

[tony . noble]

I think the point is to prevent an automatic build of a shedload of old 
pre-existing branches when creating a multi branch pipeline job for an older 
repo, even though from then onwards, you want new branches to be 
auto-discovered and built.  Regexes can’t always help with this.

It’s not really an argument about whether repositories *should* be in that 
state, it’s that sometimes they are and you need to be able to work with them 
without crippling a Jenkins server for hours at a time when creating new jobs.

Sent from my iPhone

> On 18 Apr 2020, at 14:33, Jesse Glick  wrote:
> 
> On Wed, Apr 15, 2020 at 9:11 AM Adam Gabryś  wrote:
>> when people don't delete old branches
> 
> FYI, for GitHub at least you can address this directly:
> 
> https://help.github.com/en/github/administering-a-repository/managing-the-automatic-deletion-of-branches
> 
> -- 
> 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/CANfRfr3bpVX4owimCtFYmjeg8-Wmh9L9nbY942JgtccP-xTVog%40mail.gmail.com.

-- 
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/A3ED39F8-7309-4CE8-B1EB-1B2D303F8A7A%40gmail.com.

Re: Prevent building branches/PRs existing before the first branch indexing (Branch API plugin)

[Tony Noble]

>From my experiences with this, I sympathise with your frustration.  In our
situation (not sure if this maps with yours) the ideal sequence of events
would be:

1. Project is created
2. Branches are indexed, but not built
3. Polling (or hooks) now enabled
4..?  Scheduled indexing now auto-builds new branches if selected.  Hooks
will trigger builds

The main thing is that on creation of a multibranch project referencing a
repository with a significant number of old branches, everything doesn't
get built all at once - like yourself, we found this would happily bring a
Jenkins instance to its knees quite effectively.  Once the initial creation
and first branch index is complete, however, existing functionality is fine.

Tony

On Wed, Apr 15, 2020 at 2:11 PM Adam Gabryś  wrote:

> Hello,
>
> we provide CI for many teams in a big company. Unfortunately, we have a
> huge problem with server loads after the spin up process, after restarts
> and jobs modification. Multibranch jobs execute branch indexing on every
> single change and directly after the job creation. It is great, because
> people see what is available. On the other side, when people don't delete
> old branches, we waste a lot of resources on building old stuff. In our
> case it completely blocks servers for days. We tried to use build
> strategies, but none of them solved it. The closest solution was
> SkipInitialBuildOnFirstBranchIndexing
> ,
> but unfortunately it:
>
>- blocks all new branches and PRs builds executed by webhooks (it
>always skip the first build no matter how it is triggered)
>- won’t solve the problem when the branch indexing is executed for a
>second time (again, everything is build)
>
> For now we use the patch visible in this PR
>  (I'm aware that
> it won't be merged - it is just a workaround, I skipped tests). I wanted to
> ask - do you have any ideas on how to solve this properly? We are open to
> implement the proposed solution 
>
> For now, I have two ideas to make it configurable:
>
>1. add an option to disable automatic builds on branch indexing
>2. extend BranchBuildStrategy
>
> 
>  class
>and pass information about the trigger cause
>
> Both solutions don't cover the workaround solution, because they will only
> allow the skipping of all builds caused by branch indexing (we will lose
> the ability to execute builds of branches/PRs for which webhooks have not
> been received - for example, lost due to network problems).
>
>
> Disable Automatic build on branch indexing
>
> The first solution requires to add a new property to the multibranch
> project and simply skip the build if causeFactory instanceof
> IndexingCauseFactory. I don't know how to add this configurable property,
> but I can get this knowledge 
>
> This approach does not change the API, just adds a new parameter.
>
> Extend BranchBuildStrategy API
>
> This approach is backward compatible, but introduces new methods to API
> (in a class which is extended by many plugins).
>
> How could we implement it:
>
>- add a new BranchBuildStrategy#isAutomaticBuild method which takes
>one more parameter (the trigger cause - indexing vs. webhook):
>
> public boolean isAutomaticBuild(@NonNull TriggerCause cause,
> @NonNull SCMSource source,
> @NonNull SCMHead head,
> @NonNull SCMRevision currRevision,
> @CheckForNull SCMRevision lastBuiltRevision,
> @CheckForNull SCMRevision lastSeenRevision,
> @NonNull TaskListener listener) {
> // by default delegate to the version without the cause
> return isAutomaticBuild(source, head, currRevision, lastBuiltRevision, 
> lastSeenRevision, listener);
> }
>
>
>- add a new BranchBuildStrategy#automaticBuild which will be executed
>by the MultiBranchProject:
>
> public final boolean automaticBuild(@NonNull TriggerCause cause,
> @NonNull SCMSource source,
> @NonNull SCMHead head,
> @NonNull SCMRevision currRevision,
> @CheckForNull SCMRevision 
> lastBuiltRevision,
> @CheckForNull SCMRevision 
> lastSeenRevision,
> @NonNull TaskListener listener) {
> if (Util.isOverridden(BranchBuildStrategy.class, getClass(), 
> "isAutomaticBuild", TriggerCause.class,
> SCMSource.class, SCMHead.class, SCMRevision.class, 
> 

Re: Problems publishing repo

[Tony Noble]

If you need a quick fix to get the upload working without having to
re-engineer for a more modern POM, you can just override the
distributionmanagement section to point to the correct host:



maven.jenkins-ci.org
https://repo.jenkins-ci.org/releases/


maven.jenkins-ci.org
https://repo.jenkins-ci.org/snapshots/



Bear in mind, you'll need to revert the release first, commit that change
and then run the release from the start.  You'll also need to add your
credentials for that host to the maven settings file as well.

Tony

On Wed, Feb 26, 2020 at 11:26 PM Terry Moreland 
wrote:

> ah the joys of legacy code, or configurations, either way it can eat up a
> fair bit of time.  I should've expected something like this as the code
> update was too easy
>
> On Wed, 26 Feb 2020 at 22:51, Daniel Beck  wrote:
>
>> The host name you specify in your pom.xml hasn't existed in ~5 years.
>> Your plugin might need a general pom.xml update.
>>
>> The repo is now at https://repo.jenkins-ci.org/releases/
>>
>> Also, releasing as documented will automatically tag as well.
>>
>> --
>> 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/CAMo7PtJb9TzLRzCcnVsXAsD%3DbUx2W2chwTo9TeorPzBR-HbTFw%40mail.gmail.com
>> 
>> .
>>
> --
> 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/CAM5UBjeHJTv9KCiQbX6CjexZ%2BVNejxFOo0ukL_OU-MAMdwdtkw%40mail.gmail.com
> 
> .
>

-- 
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/CAEWqh9Fmg1wSxdY-WNdA2E_bn-pqgwkcM3F0B7_b6mjRWX8Jog%40mail.gmail.com.

Re: Proposal: Moving the plugin adoption labels from Wiki to GitHub topics

[Tony Noble]

So just to clarify - if I remove the 'adpot-this-plugin' topic from a
plugin's GitHub project, that will automatically sync to the plugin page?

Tony

On Thu, Feb 20, 2020 at 4:36 PM Oleg Nenashev 
wrote:

> *TL;DR*: The process is up and running!
>
>- All foundation pull requests have been merged, including the policy
>updates. IMHO policy PR merge was a bit premature, but the change provides
>a working process at least
>- Documentation is updated:
>   - Plugin adoption:
>   https://jenkins.io/doc/developer/plugin-governance/adopt-a-plugin/
>   - Plugin deprecation and removal:
>   
> https://jenkins.io/doc/developer/plugin-governance/deprecating-or-removing-plugin/
>- Adoption labels were moved to GitHub. I applied new topics only to
>those plugin which have not been updated or adopted since Oct 2019 when the
>Wiki became read-only
>   - 77 plugins are marked for adoption at the moment:
>   https://github.com/topics/adopt-this-plugin
>- Plugin site links (sync is in progress):
>   - Plugins for adoption:
>   https://plugins.jenkins.io/ui/search/?labels=adopt-this-plugin
>   - Deprecated plugins:
>   https://plugins.jenkins.io/ui/search/?labels=deprecated
>
> BR, Oleg
>
>
> On Wednesday, February 19, 2020 at 3:13:31 PM UTC+1, Oleg Nenashev wrote:
>>
>> I have also submitted the new plugin adoption process here:
>> https://github.com/jenkins-infra/jenkins.io/pull/2875
>> While I was there, I also documented a similar plugin deprecation process
>> which should help to unblock other stories.
>>
>> P.S: "adopt-me" label is removed for good so we will have a single label
>>
>> BR, Oleg
>>
>> On Tuesday, February 18, 2020 at 2:51:21 PM UTC+1, Oleg Nenashev wrote:
>>>
>>> https://github.com/jenkins-infra/plugin-site/pull/130 for the plugin
>>> site update
>>>
>>> On Tuesday, February 18, 2020 at 10:05:40 AM UTC+1, Oleg Nenashev wrote:

 Yes, plugin site is something I will be doing (see the comments above).
 The problem is rather with GitHub repositories and direct access to
 them. In this case a badge could improve visibility of the adoption status.
 We could serve a badge from the plugin site for that, but IMHO it is a
 separate topic.

 BR, Oleg


 On Tue, Feb 18, 2020 at 10:02 AM Tim Jacomb 
 wrote:

> The badge could be automatically added on the plugin site if one of
> the adopt topics is added to the GitHub repo?
>
> On Tue, 18 Feb 2020 at 08:01, Ivan Fernandez Calvo <
> kuisathave...@gmail.com> wrote:
>
>> Sure, the badge is something additional,
>>  something that users can see when they go to the documentation, then
>> they can decide
>> if they want to use a plugin in adoption.
>>
>> --
>> 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/7e802140-b00c-4ccc-adcf-c84be95ab610%40googlegroups.com
>> .
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/UoEqG5AaWJU/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/CAH-3BicYmYzqjqo7TbOogb5LhuNBNtgmWcgd2Ld8C65aJduzbQ%40mail.gmail.com
> 
> .
>
 --
> 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/9fadc186-5e69-48b2-81c8-84b99e919100%40googlegroups.com
> 
> .
>

-- 
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/CAEWqh9EdCQ6cJ%3DGWLAW6MKhn78kB0gQTxO5WfaS3MzU43cZP%2BQ%40mail.gmail.com.

Re: Proposal: Automatically requesting code reviews from plugin developer teams (CODEOWNERS)

[Tony Noble]

Quite happy for that in the case of the plugins I maintain.  My details are
in the POMs anyway.


On Mon, Jan 13, 2020 at 12:46 PM Marky Jackson 
wrote:

> Oleg,
> I feel that need some form of consent from maintainers.
>
> On Jan 13, 2020, at 4:32 AM, Oleg Nenashev  wrote:
>
> 
> One thing here is that the most of the *pluginId-developers* teams are
> secret at the moment, and the teams must be public to operate properly with
> CODEOWNERS.
> I suggest to make all of them public, IMHO there is no value in hiding
> teams in the open-source project (apart form unintended mention prevention).
> I will add it to the next governance meeting, but I would appreciate the
> feedback
>
>
>
> On Fri, Jan 10, 2020 at 12:31 PM Oleg Nenashev 
> wrote:
>
>> I'd guess any plugin maintainer can just proceed and add CODEOWNERS to
>> the repo.
>> There is no need to wait for the bot if you want to start adopting the
>> suggestion :)
>>
>> On Thursday, January 9, 2020 at 7:07:08 PM UTC+1, Gavin Mogan wrote:
>>>
>>> Sweet I was going to suggest the same thing..
>>>
>>> Lots of plugin maintainers don't realize they are not "watching" a repo.
>>> and I think tools like pr bot don't count you unless your listed as a
>>> reviewer
>>>
>>> So much +1 for me
>>>
>>> On Thu., Jan. 9, 2020, 6:29 a.m. Oleg Nenashev, 
>>> wrote:
>>>
 Perfect, this makes the barrier to acceptance quite low,
> without forcing a change on anyone.
>
 Yes, I do not think we are in position to enforce the process at the
 moment. Historically Jenkins project gives a lot of freedom to plugin
 maintainers to define how they operate, and IMHO it is a part of the
 project's culture. IMHO we should rather lead by example there and help by
 providing tools and solutions simplifying the work and removing routine.

 On Thursday, January 9, 2020 at 3:04:51 PM UTC+1, Jesse Glick wrote:
>
> On Thu, Jan 9, 2020 at 8:05 AM Oleg Nenashev 
> wrote:
> > We add CODEOWNERS template to plugin archetypes
>
> Yes, though we need to do JENKINS-58557 first.
>
> > We submit pull requests […]
> > Each plugin maintainer or maintainer team will decide on their own
> whether they accept the process or not. Merging or closing the pull 
> request
> will indicate the decision
>
> Perfect, this makes the barrier to acceptance quite low, without
> forcing a change on anyone.
>
 --
 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/f3f0b2d4-bb98-458d-9c96-ccdee1d1fec1%40googlegroups.com
 
 .

>>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/jenkinsci-dev/U_lFkTzmg1E/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/bc4c21c0-a18c-467a-a02e-a26cfa5acd97%40googlegroups.com
>> 
>> .
>>
> --
> 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/CAPfivLATCB1R_OWLsEuGNoCx-k%2BqfQwJHxwvJOVbEFkgHWTW4A%40mail.gmail.com
> 
> .
>
> --
> 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/77113232-CBF5-4E20-963D-836E75DA4161%40gmail.com
> 
> .
>

-- 
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 

Re: XTrigger-Lib needs maintenance/release

[Tony Noble]

Brilliant, thanks :0)


On Mon, Dec 2, 2019 at 7:39 AM Ullrich Hafner 
wrote:

> I added you as committer to the repositories.
>
> Am 02.12.2019 um 00:04 schrieb Tony Noble :
>
> Late follow-up, apologies.
>
> Now I have time to look at outstanding PRs / Jira tickets, I still don't
> appear to have owner access to the following git repos:
>
>-
>- ScriptTrigger Plugin
><https://wiki.jenkins.io/display/JENKINS/ScriptTrigger+Plugin> -
>https://github.com/jenkinsci/scripttrigger-plugin
>- BuildResultTrigger Plugin
><https://wiki.jenkins.io/display/JENKINS/BuildResultTrigger+Plugin> (a.k.a
>JobTrigger) - https://github.com/jenkinsci/buildresult-trigger-plugin
>
>
> All other access appears to be sorted, however.
>
> Can someone assist?
>
> Tony
>
>-
>
>
> On Fri, Jul 26, 2019 at 1:47 PM Oleg Nenashev 
> wrote:
>
>> done. Was waiting for more confirmations, but it got stalled
>>
>> On Fri, Jul 26, 2019 at 2:37 PM Tony Noble  wrote:
>>
>>> Pull request looks to have been approved, but not applied - can anyone
>>> assist?
>>>
>>> Cheers,
>>>
>>> Tony
>>>
>>> On Sun, Jul 21, 2019 at 1:35 PM Tony Noble  wrote:
>>>
>>>> Thanks Oleg,
>>>>
>>>> Pull request created:
>>>> https://github.com/jenkins-infra/repository-permissions-updater/pull/1233
>>>>
>>>> Tony
>>>>
>>>> On Sun, Jul 21, 2019 at 9:50 AM Oleg Nenashev 
>>>> wrote:
>>>>
>>>>> Hi Tony,
>>>>>
>>>>> I have granted you write access and made you a default assignee in the
>>>>> components.
>>>>> If you decide  to become a maintainer of the EnvInject stuff, I will
>>>>> be happy to grant your permissions as well.
>>>>>
>>>>> Some notes:
>>>>>
>>>>>- To release the components, you will need to create a pull
>>>>>request to
>>>>>https://github.com/jenkins-infra/repository-permissions-updater
>>>>>- ColMelvin <https://github.com/ColMelvin> has contributed a lot
>>>>>of patches which have not been released yet. IIRC I reviewed them 1 
>>>>> year
>>>>>ago, but nobody took ownership at that point. Some area for 
>>>>> collaboration
>>>>>there, maybe
>>>>>- For plugin you plan to maintain in longer term, it might make
>>>>>sense to use Release Drafter for changelogs (docs
>>>>>
>>>>> <https://github.com/jenkinsci/.github/blob/master/.github/release-drafter.adoc>
>>>>>)
>>>>>
>>>>> Best regards,
>>>>> Oleg
>>>>>
>>>>> On Saturday, July 20, 2019 at 9:30:49 PM UTC+2, Tony Noble wrote:
>>>>>>
>>>>>> Okay, so modifications:
>>>>>>
>>>>>> - No need to add me as maintainer for envinject-lib
>>>>>> - XTrigger-lib plugin replacement will be named XTrigger-api-plugin
>>>>>>
>>>>>> On that basis, if someone could add me as maintainer for the rest,
>>>>>> it'd be much appreciated.
>>>>>>
>>>>>> Tony
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Jul 20, 2019 at 7:15 PM Oleg Nenashev 
>>>>>> wrote:
>>>>>>
>>>>>>> My plan was to keep EnvInject Lib as a temporary lib until all
>>>>>>> plugins and "libs" switch to EnvInject API. Then I would have moved the
>>>>>>> code and removed the library repository. It was at the time of a 
>>>>>>> Pipeline
>>>>>>> compatibility effort 4 years ago. But we have not been able to rework 
>>>>>>> all
>>>>>>> Geegory's plugins at that time, switched to other tasks.
>>>>>>>
>>>>>>> If you rework XTrigger Lib to a plugin, please use EnvInject API
>>>>>>> Plugin as a dependency.
>>>>>>>
>>>>>>> BR, Oleg
>>>>>>>
>>>>>>> On Sat, Jul 20, 2019, 19:54 Daniel Beck  wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> > On 20. Jul 2019, at 14:52, Tony Noble  wrote:
>>>>>

Re: XTrigger-Lib needs maintenance/release

[Tony Noble]

Late follow-up, apologies.

Now I have time to look at outstanding PRs / Jira tickets, I still don't
appear to have owner access to the following git repos:
-
- ScriptTrigger Plugin
<https://wiki.jenkins.io/display/JENKINS/ScriptTrigger+Plugin> -
https://github.com/jenkinsci/scripttrigger-plugin
- BuildResultTrigger Plugin
<https://wiki.jenkins.io/display/JENKINS/BuildResultTrigger+Plugin> (a.k.a
JobTrigger) - https://github.com/jenkinsci/buildresult-trigger-plugin

All other access appears to be sorted, however.

Can someone assist?

Tony
-

On Fri, Jul 26, 2019 at 1:47 PM Oleg Nenashev 
wrote:

> done. Was waiting for more confirmations, but it got stalled
>
> On Fri, Jul 26, 2019 at 2:37 PM Tony Noble  wrote:
>
>> Pull request looks to have been approved, but not applied - can anyone
>> assist?
>>
>> Cheers,
>>
>> Tony
>>
>> On Sun, Jul 21, 2019 at 1:35 PM Tony Noble  wrote:
>>
>>> Thanks Oleg,
>>>
>>> Pull request created:
>>> https://github.com/jenkins-infra/repository-permissions-updater/pull/1233
>>>
>>> Tony
>>>
>>> On Sun, Jul 21, 2019 at 9:50 AM Oleg Nenashev 
>>> wrote:
>>>
>>>> Hi Tony,
>>>>
>>>> I have granted you write access and made you a default assignee in the
>>>> components.
>>>> If you decide  to become a maintainer of the EnvInject stuff, I will be
>>>> happy to grant your permissions as well.
>>>>
>>>> Some notes:
>>>>
>>>>- To release the components, you will need to create a pull request
>>>>to https://github.com/jenkins-infra/repository-permissions-updater
>>>>- ColMelvin <https://github.com/ColMelvin> has contributed a lot of
>>>>patches which have not been released yet. IIRC I reviewed them 1 year 
>>>> ago,
>>>>but nobody took ownership at that point. Some area for collaboration 
>>>> there,
>>>>maybe
>>>>- For plugin you plan to maintain in longer term, it might make
>>>>sense to use Release Drafter for changelogs (docs
>>>>
>>>> <https://github.com/jenkinsci/.github/blob/master/.github/release-drafter.adoc>
>>>>)
>>>>
>>>> Best regards,
>>>> Oleg
>>>>
>>>> On Saturday, July 20, 2019 at 9:30:49 PM UTC+2, Tony Noble wrote:
>>>>>
>>>>> Okay, so modifications:
>>>>>
>>>>> - No need to add me as maintainer for envinject-lib
>>>>> - XTrigger-lib plugin replacement will be named XTrigger-api-plugin
>>>>>
>>>>> On that basis, if someone could add me as maintainer for the rest,
>>>>> it'd be much appreciated.
>>>>>
>>>>> Tony
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Jul 20, 2019 at 7:15 PM Oleg Nenashev 
>>>>> wrote:
>>>>>
>>>>>> My plan was to keep EnvInject Lib as a temporary lib until all
>>>>>> plugins and "libs" switch to EnvInject API. Then I would have moved the
>>>>>> code and removed the library repository. It was at the time of a Pipeline
>>>>>> compatibility effort 4 years ago. But we have not been able to rework all
>>>>>> Geegory's plugins at that time, switched to other tasks.
>>>>>>
>>>>>> If you rework XTrigger Lib to a plugin, please use EnvInject API
>>>>>> Plugin as a dependency.
>>>>>>
>>>>>> BR, Oleg
>>>>>>
>>>>>> On Sat, Jul 20, 2019, 19:54 Daniel Beck  wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> > On 20. Jul 2019, at 14:52, Tony Noble  wrote:
>>>>>>> >
>>>>>>> > Another point to note - given that the goal for xtrigger-lib is to
>>>>>>> convert to a plugin, the natural name for it would be xtrigger-plugin.  
>>>>>>> But
>>>>>>> that's obviously taken as noted above - rather than go off on the wrong
>>>>>>> track, would 'xtrigger-base-plugin' seem reasonable?
>>>>>>> >
>>>>>>>
>>>>>>> It's customary to name it whatever-api in Jenkins. envinject-lib is
>>>>>>> provided by the plugin 'envinject-api', there's branch-api and scm-api, 
>>>>>>> etc.
>>>>>>&

Re: Adoption of FSTrigger plugin

[Tony Noble]

Hi Tiberius,

There is a general plan to bring all the dependencies for all the XTrigger
projects up to date (and get them working with pipeline), but so far only
one is anywhere near complete.  As small as the change might seem, if you
could raise a PR for it, it would be much appreciated (and will make sure
it gets higher priority in general).

Many thanks,

Tony

On Wed, Nov 27, 2019 at 6:36 PM tiberius soanea 
wrote:

> Hi Tony,
>
> Thanks for the quick response.
> For fixing the issue i just updated the pom with the latest versions for
> the dependecies and added a dependency to the matrix project. I made no
> changes to the code.
> Is this something you are already planning to do soon or should i submit a
> PR?
>
> Best regards,
> Tiberius
>
> miercuri, 27 noiembrie 2019, 17:11:04 UTC+1, Tony Noble a scris:
>>
>> Hi Tiberius,
>>
>> I'm the maintainer of the FSTrigger plugin - apologies for the wiki page
>> not being up to date, I've recently taken all the xtrigger-related plugins
>> on and am still in the process of rationalising / updating.
>>
>> If there's a issue/fix with the plugin, please feel free to submit a PR
>> for the git project and I'll take a look and sort a release.
>>
>> Regards,
>>
>> Tony
>>
>> On Wed, Nov 27, 2019 at 4:05 PM tiberius soanea 
>> wrote:
>>
>>> Hello,
>>>
>>> I am working with Thales on Jenkins and its plugins.
>>> I fixed a ticket regarding FSTrigger plugin that doesn't work correctly
>>> with Jenkins since the 2.107.2 version so i would like to adopt the plugin
>>> to be able to provide the updated version.
>>>
>>> Link to plugin: https://plugins.jenkins.io/fstrigger
>>> GitHub username: TiberiusSoanea
>>> Jenkins infrastructure account id: TiberiusSoanea
>>>
>>> Thank you,
>>> Tiberius Soanea
>>>
>>> --
>>> 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/eed5e799-3f44-4360-82f1-287fd275f034%40googlegroups.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/eed5e799-3f44-4360-82f1-287fd275f034%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/9e28c423-c47f-47f4-95f8-15a9be02d358%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/9e28c423-c47f-47f4-95f8-15a9be02d358%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/CAEWqh9G2OEbHuHhM%3Dc_LC7UamQLsMEvbXz5tHrh8FOtum2gZ6A%40mail.gmail.com.

Re: Adoption of FSTrigger plugin

[Tony Noble]

Hi Tiberius,

I'm the maintainer of the FSTrigger plugin - apologies for the wiki page
not being up to date, I've recently taken all the xtrigger-related plugins
on and am still in the process of rationalising / updating.

If there's a issue/fix with the plugin, please feel free to submit a PR for
the git project and I'll take a look and sort a release.

Regards,

Tony

On Wed, Nov 27, 2019 at 4:05 PM tiberius soanea 
wrote:

> Hello,
>
> I am working with Thales on Jenkins and its plugins.
> I fixed a ticket regarding FSTrigger plugin that doesn't work correctly
> with Jenkins since the 2.107.2 version so i would like to adopt the plugin
> to be able to provide the updated version.
>
> Link to plugin: https://plugins.jenkins.io/fstrigger
> GitHub username: TiberiusSoanea
> Jenkins infrastructure account id: TiberiusSoanea
>
> Thank you,
> Tiberius Soanea
>
> --
> 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/eed5e799-3f44-4360-82f1-287fd275f034%40googlegroups.com
> 
> .
>

-- 
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/CAEWqh9GM-%2BP08StaEheDgQauKFdYbmpgY_eSBsJ5Md02%3DOcBLg%40mail.gmail.com.

Re: XTrigger-Lib needs maintenance/release

[Tony Noble]

Pull request looks to have been approved, but not applied - can anyone
assist?

Cheers,

Tony

On Sun, Jul 21, 2019 at 1:35 PM Tony Noble  wrote:

> Thanks Oleg,
>
> Pull request created:
> https://github.com/jenkins-infra/repository-permissions-updater/pull/1233
>
> Tony
>
> On Sun, Jul 21, 2019 at 9:50 AM Oleg Nenashev 
> wrote:
>
>> Hi Tony,
>>
>> I have granted you write access and made you a default assignee in the
>> components.
>> If you decide  to become a maintainer of the EnvInject stuff, I will be
>> happy to grant your permissions as well.
>>
>> Some notes:
>>
>>- To release the components, you will need to create a pull request
>>to https://github.com/jenkins-infra/repository-permissions-updater
>>- ColMelvin <https://github.com/ColMelvin> has contributed a lot of
>>patches which have not been released yet. IIRC I reviewed them 1 year ago,
>>but nobody took ownership at that point. Some area for collaboration 
>> there,
>>maybe
>>- For plugin you plan to maintain in longer term, it might make sense
>>to use Release Drafter for changelogs (docs
>>
>> <https://github.com/jenkinsci/.github/blob/master/.github/release-drafter.adoc>
>>)
>>
>> Best regards,
>> Oleg
>>
>> On Saturday, July 20, 2019 at 9:30:49 PM UTC+2, Tony Noble wrote:
>>>
>>> Okay, so modifications:
>>>
>>> - No need to add me as maintainer for envinject-lib
>>> - XTrigger-lib plugin replacement will be named XTrigger-api-plugin
>>>
>>> On that basis, if someone could add me as maintainer for the rest, it'd
>>> be much appreciated.
>>>
>>> Tony
>>>
>>>
>>>
>>> On Sat, Jul 20, 2019 at 7:15 PM Oleg Nenashev 
>>> wrote:
>>>
>>>> My plan was to keep EnvInject Lib as a temporary lib until all plugins
>>>> and "libs" switch to EnvInject API. Then I would have moved the code and
>>>> removed the library repository. It was at the time of a Pipeline
>>>> compatibility effort 4 years ago. But we have not been able to rework all
>>>> Geegory's plugins at that time, switched to other tasks.
>>>>
>>>> If you rework XTrigger Lib to a plugin, please use EnvInject API Plugin
>>>> as a dependency.
>>>>
>>>> BR, Oleg
>>>>
>>>> On Sat, Jul 20, 2019, 19:54 Daniel Beck  wrote:
>>>>
>>>>>
>>>>>
>>>>> > On 20. Jul 2019, at 14:52, Tony Noble  wrote:
>>>>> >
>>>>> > Another point to note - given that the goal for xtrigger-lib is to
>>>>> convert to a plugin, the natural name for it would be xtrigger-plugin.  
>>>>> But
>>>>> that's obviously taken as noted above - rather than go off on the wrong
>>>>> track, would 'xtrigger-base-plugin' seem reasonable?
>>>>> >
>>>>>
>>>>> It's customary to name it whatever-api in Jenkins. envinject-lib is
>>>>> provided by the plugin 'envinject-api', there's branch-api and scm-api, 
>>>>> etc.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to a topic in the
>>>>> Google Groups "Jenkins Developers" group.
>>>>> To unsubscribe from this topic, visit
>>>>> https://groups.google.com/d/topic/jenkinsci-dev/Ue9hmTRhqS4/unsubscribe
>>>>> .
>>>>> To unsubscribe from this group and all its topics, send an email to
>>>>> jenkin...@googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/jenkinsci-dev/CFD98BB8-4683-4BB7-8101-D6FAEE28B4EC%40beckweb.net
>>>>> .
>>>>>
>>>> --
>>>> 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/CAPfivLCe-d47xKn9wmOhen02%2BT0fxqXDF%3DQirp2MJqCSdPiCmQ%40mail.gmail.com
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCe-d47xKn9wmOhen02%2BT0fxqXDF%3DQirp2MJqCSdPiCmQ%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/6ea8aa69-4713-43af-ae1f-181dc37e9000%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/6ea8aa69-4713-43af-ae1f-181dc37e9000%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/CAEWqh9HA8ETqBpxbRODcsgZAEEkDPGQ8FRxe8d2hb3EHTNzGOQ%40mail.gmail.com.

Re: XTrigger-Lib needs maintenance/release

[Tony Noble]

Thanks Oleg,

Pull request created:
https://github.com/jenkins-infra/repository-permissions-updater/pull/1233

Tony

On Sun, Jul 21, 2019 at 9:50 AM Oleg Nenashev 
wrote:

> Hi Tony,
>
> I have granted you write access and made you a default assignee in the
> components.
> If you decide  to become a maintainer of the EnvInject stuff, I will be
> happy to grant your permissions as well.
>
> Some notes:
>
>- To release the components, you will need to create a pull request to
>https://github.com/jenkins-infra/repository-permissions-updater
>- ColMelvin <https://github.com/ColMelvin> has contributed a lot of
>patches which have not been released yet. IIRC I reviewed them 1 year ago,
>but nobody took ownership at that point. Some area for collaboration there,
>maybe
>- For plugin you plan to maintain in longer term, it might make sense
>to use Release Drafter for changelogs (docs
>
> <https://github.com/jenkinsci/.github/blob/master/.github/release-drafter.adoc>
>)
>
> Best regards,
> Oleg
>
> On Saturday, July 20, 2019 at 9:30:49 PM UTC+2, Tony Noble wrote:
>>
>> Okay, so modifications:
>>
>> - No need to add me as maintainer for envinject-lib
>> - XTrigger-lib plugin replacement will be named XTrigger-api-plugin
>>
>> On that basis, if someone could add me as maintainer for the rest, it'd
>> be much appreciated.
>>
>> Tony
>>
>>
>>
>> On Sat, Jul 20, 2019 at 7:15 PM Oleg Nenashev  wrote:
>>
>>> My plan was to keep EnvInject Lib as a temporary lib until all plugins
>>> and "libs" switch to EnvInject API. Then I would have moved the code and
>>> removed the library repository. It was at the time of a Pipeline
>>> compatibility effort 4 years ago. But we have not been able to rework all
>>> Geegory's plugins at that time, switched to other tasks.
>>>
>>> If you rework XTrigger Lib to a plugin, please use EnvInject API Plugin
>>> as a dependency.
>>>
>>> BR, Oleg
>>>
>>> On Sat, Jul 20, 2019, 19:54 Daniel Beck  wrote:
>>>
>>>>
>>>>
>>>> > On 20. Jul 2019, at 14:52, Tony Noble  wrote:
>>>> >
>>>> > Another point to note - given that the goal for xtrigger-lib is to
>>>> convert to a plugin, the natural name for it would be xtrigger-plugin.  But
>>>> that's obviously taken as noted above - rather than go off on the wrong
>>>> track, would 'xtrigger-base-plugin' seem reasonable?
>>>> >
>>>>
>>>> It's customary to name it whatever-api in Jenkins. envinject-lib is
>>>> provided by the plugin 'envinject-api', there's branch-api and scm-api, 
>>>> etc.
>>>>
>>>> --
>>>> You received this message because you are subscribed to a topic in the
>>>> Google Groups "Jenkins Developers" group.
>>>> To unsubscribe from this topic, visit
>>>> https://groups.google.com/d/topic/jenkinsci-dev/Ue9hmTRhqS4/unsubscribe
>>>> .
>>>> To unsubscribe from this group and all its topics, send an email to
>>>> jenkin...@googlegroups.com.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/jenkinsci-dev/CFD98BB8-4683-4BB7-8101-D6FAEE28B4EC%40beckweb.net
>>>> .
>>>>
>>> --
>>> 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/CAPfivLCe-d47xKn9wmOhen02%2BT0fxqXDF%3DQirp2MJqCSdPiCmQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCe-d47xKn9wmOhen02%2BT0fxqXDF%3DQirp2MJqCSdPiCmQ%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/6ea8aa69-4713-43af-ae1f-181dc37e9000%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/6ea8aa69-4713-43af-ae1f-181dc37e9000%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/CAEWqh9G7ChHD3apzADbOjYpkNDo1bSh7zf5RSiSQTUV9NcqPJg%40mail.gmail.com.

Re: XTrigger-Lib needs maintenance/release

[Tony Noble]

Okay, so modifications:

- No need to add me as maintainer for envinject-lib
- XTrigger-lib plugin replacement will be named XTrigger-api-plugin

On that basis, if someone could add me as maintainer for the rest, it'd be
much appreciated.

Tony



On Sat, Jul 20, 2019 at 7:15 PM Oleg Nenashev 
wrote:

> My plan was to keep EnvInject Lib as a temporary lib until all plugins and
> "libs" switch to EnvInject API. Then I would have moved the code and
> removed the library repository. It was at the time of a Pipeline
> compatibility effort 4 years ago. But we have not been able to rework all
> Geegory's plugins at that time, switched to other tasks.
>
> If you rework XTrigger Lib to a plugin, please use EnvInject API Plugin as
> a dependency.
>
> BR, Oleg
>
> On Sat, Jul 20, 2019, 19:54 Daniel Beck  wrote:
>
>>
>>
>> > On 20. Jul 2019, at 14:52, Tony Noble  wrote:
>> >
>> > Another point to note - given that the goal for xtrigger-lib is to
>> convert to a plugin, the natural name for it would be xtrigger-plugin.  But
>> that's obviously taken as noted above - rather than go off on the wrong
>> track, would 'xtrigger-base-plugin' seem reasonable?
>> >
>>
>> It's customary to name it whatever-api in Jenkins. envinject-lib is
>> provided by the plugin 'envinject-api', there's branch-api and scm-api, etc.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/jenkinsci-dev/Ue9hmTRhqS4/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/CFD98BB8-4683-4BB7-8101-D6FAEE28B4EC%40beckweb.net
>> .
>>
> --
> 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/CAPfivLCe-d47xKn9wmOhen02%2BT0fxqXDF%3DQirp2MJqCSdPiCmQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLCe-d47xKn9wmOhen02%2BT0fxqXDF%3DQirp2MJqCSdPiCmQ%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/CAEWqh9F7EtEqbZCX%3Do6xNx--Yg4PU0QodxmO1KE3uCN%3DmSjK9g%40mail.gmail.com.

Re: XTrigger-Lib needs maintenance/release

[Tony Noble]

@jglick , @oleg-nenashev

Using xtrigger-plugin as a guide, I'd suggest that the following should be
grouped together as previously owned by Gregory.  As such, please could I
be added as maintainer on github to:

   - FSTrigger Plugin
   <https://wiki.jenkins.io/display/JENKINS/FSTrigger+Plugin> -
   https://github.com/jenkinsci/fstrigger-plugin
   - URLTrigger Plugin
   <https://wiki.jenkins.io/display/JENKINS/URLTrigger+Plugin> -
   https://github.com/jenkinsci/urltrigger-plugin (not required, I'm
   already maintainer)
   - IvyTrigger Plugin
   <https://wiki.jenkins.io/display/JENKINS/IvyTrigger+Plugin> -
   https://github.com/jenkinsci/ivytrigger-plugin
   - ScriptTrigger Plugin
   <https://wiki.jenkins.io/display/JENKINS/ScriptTrigger+Plugin> -
   https://github.com/jenkinsci/scripttrigger-plugin (This looks like
   something full of security holes and possibly in need of deprecation)
   - BuildResultTrigger Plugin
   <https://wiki.jenkins.io/display/JENKINS/BuildResultTrigger+Plugin> (a.k.a
   JobTrigger) - https://github.com/jenkinsci/buildresult-trigger-plugin
   - XTrigger-Lib - https://github.com/jenkinsci/xtrigger-lib
   - EnvInject-Lib - https://github.com/jenkinsci/envinject-lib
   - XTrigger-Plugin - https://github.com/jenkinsci/xtrigger-plugin


I note that EnvInject has since been converted to a plugin - should I
include this, or are you happy with the current setup for it?

Another point to note - given that the goal for xtrigger-lib is to convert
to a plugin, the natural name for it would be xtrigger-plugin.  But that's
obviously taken as noted above - rather than go off on the wrong track,
would 'xtrigger-base-plugin' seem reasonable?

Thanks,

Tony

(GitHub id: TonyNoble , Jenkins id: StealthDJ)


On Thu, Jul 11, 2019 at 11:48 PM Tony Noble  wrote:

> Pull request submitted for release permissions:
> https://github.com/jenkins-infra/repository-permissions-updater/pull/1216
>
> Could I also be give access to the github repo for xtrigger-lib, please?
>
> Repo: https://github.com/jenkinsci/xtrigger-lib
> GitHub id: TonyNoble
> Jenkins id: stealthdj
>
> I'll look at what other plugins depend on xtrigger and submit a separate
> request for those.  Judging by the issues I've discovered with this update
> and previous conversations, I'm guessing that envinject may well also need
> to be included.
>
> Thanks,
>
> Tony
>
> On Thu, Jul 11, 2019 at 7:00 PM Jesse Glick  wrote:
>
>> On Thu, Jul 11, 2019 at 10:27 AM Tony Noble  wrote:
>> > any breaking change of the xtrigger plugin would require all dependant
>> plugins to be updated and a co-ordinated release organised
>>
>> Yes…so do not make breaking changes.
>>
>> > The issue I see there is that (from what I can see) all the dependent
>> plugins, or at least a lot of them, were maintained by Gregory and are now
>> effectively unmaintained
>>
>> I would advise anyone taking over as owner of part of this to ask to
>> be made owner of all of them. (Does not mean other interested parties
>> cannot contribute or even be primarily responsible for substantive
>> changes—just means that you have permissions to make changes to the
>> whole set of things when you need to.)
>>
>> --
>> 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/CANfRfr1N9RfJVZt%3Dtf%2BZtgA%3DHcL%2BdcFjjWxFrJjuVoxESqny%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/CAEWqh9G1Wy0MMMwZCidQ8E_SU9AzXovf1tLdSEL_HJpATKsvhA%40mail.gmail.com.

Re: XTrigger-Lib needs maintenance/release

[Tony Noble]

Pull request submitted for release permissions:
https://github.com/jenkins-infra/repository-permissions-updater/pull/1216

Could I also be give access to the github repo for xtrigger-lib, please?

Repo: https://github.com/jenkinsci/xtrigger-lib
GitHub id: TonyNoble
Jenkins id: stealthdj

I'll look at what other plugins depend on xtrigger and submit a separate
request for those.  Judging by the issues I've discovered with this update
and previous conversations, I'm guessing that envinject may well also need
to be included.

Thanks,

Tony

On Thu, Jul 11, 2019 at 7:00 PM Jesse Glick  wrote:

> On Thu, Jul 11, 2019 at 10:27 AM Tony Noble  wrote:
> > any breaking change of the xtrigger plugin would require all dependant
> plugins to be updated and a co-ordinated release organised
>
> Yes…so do not make breaking changes.
>
> > The issue I see there is that (from what I can see) all the dependent
> plugins, or at least a lot of them, were maintained by Gregory and are now
> effectively unmaintained
>
> I would advise anyone taking over as owner of part of this to ask to
> be made owner of all of them. (Does not mean other interested parties
> cannot contribute or even be primarily responsible for substantive
> changes—just means that you have permissions to make changes to the
> whole set of things when you need to.)
>
> --
> 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/CANfRfr1N9RfJVZt%3Dtf%2BZtgA%3DHcL%2BdcFjjWxFrJjuVoxESqny%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/CAEWqh9HswQKOCBePqePtUFK2oN5WUA333FRh02bwtQYWCGGHSA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: XTrigger-Lib needs maintenance/release

[Tony Noble]

On Thu, Jul 11, 2019 at 3:17 PM Jesse Glick  wrote:

> Completely routine; you just declare a Maven dependency and you are
> done. Certainly less exotic and trouble-prone than the current design.
>
>
> https://jenkins.io/doc/developer/plugin-development/dependencies-and-class-loading/
>
> Thanks.  That gives me somethign to get stuck in to.

The release process for the library is identical to that for a plugin:
>
> mvn release:{prepare,perform}
>
>
Apologies - I meant the process of being added as a maintainer :0)
Thankfully the day job means I'm pretty comfortable with maven releases.

The additional step in the current design is that you then need to go
> to all the plugins using the library, update their dependency, and
> release them too. If we switched the library to a plugin, it would
> suffice to just release it—anyone accepting that update would get the
> new behavior for all the feature plugins, since these would no longer
> be physically bundling the library.
>

True, but then if I read that correctly, any breaking change of the
xtrigger plugin would require all dependant plugins to be updated and a
co-ordinated release organised, rather than the current system where the
dependent plugins simply avoid bumping the version of xtigger until they're
ready?  The issue I see there is that (from what I can see) all the
dependent plugins, or at least a lot of them, were maintained by Gregory
and are now effectively unmaintained...

Admittedly, that's a problem to deal with as and when we get to the
migration and I realise that the answer will probably be "don't make any
breaking changes" :0)

Tony

-- 
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/CAEWqh9GWZG6oN0XyP17uhE%3DyWXAZtEZPpdqnZ%2Bk%3DesM1n6B%2BMA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: XTrigger-Lib needs maintenance/release

[Tony Noble]

Hi @oleg-nenashev,

That sounds ideal.  I do remember the thread now, but have to admit - I'm
very much of the 'just keep it working' approach for the moment, until I
get my head around how to create plugins that are essentially subclasses of
other plugins (which is what would need to happen if xtrigger was migrated
to be a plugin).  And if it's even possible to do all this without breaking
existing user configuration.

I can raise the PR for repository permissions - what needs to happen for
commit access to the repo?

Tony

On Thu, Jul 11, 2019 at 10:53 AM Oleg Nenashev 
wrote:

> FTR, there was a thread about the next steps for XTrigger lib:
> https://groups.google.com/forum/#!searchin/jenkinsci-dev/XTrigger%7Csort:date/jenkinsci-dev/voKBrqz7V_o/rCP5ysYZBwAJ
> AFAICT, we still need to get a release, and ownership has not been fully
> transferred to anyone.
>
> https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/component-xtrigger-lib.yml
>  references
> only Gregory
>
> Tony, if you are fine with that, we can just co-maintain the library for
> now.
> In my case I would rather want to help to get it over the line and to help
> with further releases if needed, I have no time to really "maintain" the
> component
>
> WDYT?
>
>
> On Thursday, July 11, 2019 at 11:48:45 AM UTC+2, Tony Noble wrote:
>>
>> I realise this isn't a plugin as such, so not sure how the process would
>> work.
>>
>> A number of trigger plugins, mine included (urltrigger) rely on
>> xtrigger-lib to perform the core job handling and cron scheduling.  From
>> what I can see, Gregory Boissinot used to maintain this, along with the
>> dependent plugins, but I'm guessing he stepped back from them all at the
>> same time.
>>
>> At the moment, a number of issues within xtrigger-lib prevent the
>> dependent plugins from being pipeline-compliant.  Proposed fixes for them
>> have been merged by @oleg-nenashev , but no release has been performed, so
>> they're not specifically useable.
>>
>> I guess the questions is - how do I go about getting a release created?
>> I'm happy to take the responsibility on myself, if that's what's required,
>> but as mentioned above, I'm not sure how the process would work for a lib
>> rather than a plugin.
>>
>> Tony
>>
> --
> 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/edb112a3-84f7-4acf-8581-ccff5caf4cdf%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/edb112a3-84f7-4acf-8581-ccff5caf4cdf%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/CAEWqh9E93r_Z0k--JZWnx-wqb4q%3Dzozp_5qqi83SfZ3EKOnDHA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

XTrigger-Lib needs maintenance/release

[Tony Noble]

I realise this isn't a plugin as such, so not sure how the process would
work.

A number of trigger plugins, mine included (urltrigger) rely on
xtrigger-lib to perform the core job handling and cron scheduling.  From
what I can see, Gregory Boissinot used to maintain this, along with the
dependent plugins, but I'm guessing he stepped back from them all at the
same time.

At the moment, a number of issues within xtrigger-lib prevent the dependent
plugins from being pipeline-compliant.  Proposed fixes for them have been
merged by @oleg-nenashev , but no release has been performed, so they're
not specifically useable.

I guess the questions is - how do I go about getting a release created?
I'm happy to take the responsibility on myself, if that's what's required,
but as mentioned above, I'm not sure how the process would work for a lib
rather than a plugin.

Tony

-- 
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/CAEWqh9EAKt906QXUPjjZAc%2B-TAu4-wc5FC%2BDutqArEm1eb2tCg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to merge fixes to plugins with no maintainer

[Tony Noble]

Pull request for upload permissions created:
https://github.com/jenkins-infra/repository-permissions-updater/pull/1110

Tony

On Fri, Apr 26, 2019 at 10:10 AM Tony Noble  wrote:

> Sorted, thanks :0)
>
> Tony
>
> On Fri, Apr 26, 2019 at 9:57 AM Oleg Nenashev 
> wrote:
>
>> Hi Tony,
>>
>> Sorry, I have missed the response. I have applied the permission patch in
>> JIRA and GitHub.
>> You should have access to the repository now.
>>
>> You will also need to patch
>> https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-changes-since-last-success.yml
>>  in
>> order to get the permissions to release the plugin.
>>
>> Best regards,
>> Oleg
>>
>>
>> On Fri, Apr 26, 2019 at 10:32 AM Tony Noble  wrote:
>>
>>> Sorry, to be a pain, but this doesn't seem to have come through yet.
>>> Can anyone assist?
>>>
>>> Cheers,
>>>
>>> Tony
>>>
>>> On Tue, Apr 9, 2019 at 11:12 PM Tony Noble  wrote:
>>>
>>>> If you could, please - details below:
>>>>
>>>> (GitHub id: TonyNoble , Jenkins Jira Id: StealthDJ)
>>>>
>>>> Thanks,
>>>>
>>>> Tony
>>>>
>>>>
>>>>
>>>> On Mon, Apr 8, 2019 at 2:04 PM Oleg Nenashev 
>>>> wrote:
>>>>
>>>>> Yes, I think so.
>>>>> Happy to do the transfer
>>>>>
>>>>> On Mon, Apr 8, 2019, 15:57 Tony Noble  wrote:
>>>>>
>>>>>> @ndeloof has explicitly stated he no longer maintains this plugin and
>>>>>> that it is up for adoption (
>>>>>> https://github.com/jenkinsci/changes-since-last-success-plugin/pull/3#issuecomment-476476085)
>>>>>>
>>>>>>
>>>>>> Is it possible to transfer it across to me?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Tony
>>>>>>
>>>>>> On Wed, Mar 27, 2019 at 9:41 AM Tony Noble 
>>>>>> wrote:
>>>>>>
>>>>>>> Looks like a fairly simple plugin.  I can take it if required and
>>>>>>> the GSOC student doesn't wish to.
>>>>>>>
>>>>>>> Tony
>>>>>>>
>>>>>>> (GitHub id: TonyNoble , Jenkins Jira Id: StealthDJ)
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Mar 27, 2019 at 7:47 AM Oleg Nenashev <
>>>>>>> o.v.nenas...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Hello Martin,
>>>>>>>>
>>>>>>>> Weird thing is that there are 3 exactly similar pull requests from
>>>>>>>> different contributors. The students PR is the last one to be created, 
>>>>>>>> so I
>>>>>>>> I would rather close it as a duplicate TBH.
>>>>>>>>
>>>>>>>> W.r.t merge/release, I do not think we can do a lot without active
>>>>>>>> maintainer there. Somebody would need to adopt the plugin and to cut a 
>>>>>>>> new
>>>>>>>> release.
>>>>>>>> https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Oleg
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tuesday, March 26, 2019 at 9:58:30 PM UTC+1, martinda wrote:
>>>>>>>>>
>>>>>>>>> A GSoC student wants to merge a trivial fix to a plugin that no
>>>>>>>>> longer has a maintainer.
>>>>>>>>>
>>>>>>>>> The plugin is changes-since-last-success-plugin
>>>>>>>>> <https://plugins.jenkins.io/changes-since-last-success> (ndeloof
>>>>>>>>> is no longer the maintainer as per this message
>>>>>>>>> <https://groups.google.com/d/msg/jenkinsci-dev/BLIfRisUyag/MX7lfaDKBAAJ>
>>>>>>>>> )
>>>>>>>>>
>>>>>>>>> The PR is:
>>>>>>>>>
>>>>>>>>> https://github.com/jenkinsci/changes-since-last-success-plugin/pull/3
>>>>>>>>>
>>>>>>>>> How does the s

Re: How to merge fixes to plugins with no maintainer

[Tony Noble]

Sorted, thanks :0)

Tony

On Fri, Apr 26, 2019 at 9:57 AM Oleg Nenashev 
wrote:

> Hi Tony,
>
> Sorry, I have missed the response. I have applied the permission patch in
> JIRA and GitHub.
> You should have access to the repository now.
>
> You will also need to patch
> https://github.com/jenkins-infra/repository-permissions-updater/blob/master/permissions/plugin-changes-since-last-success.yml
>  in
> order to get the permissions to release the plugin.
>
> Best regards,
> Oleg
>
>
> On Fri, Apr 26, 2019 at 10:32 AM Tony Noble  wrote:
>
>> Sorry, to be a pain, but this doesn't seem to have come through yet.  Can
>> anyone assist?
>>
>> Cheers,
>>
>> Tony
>>
>> On Tue, Apr 9, 2019 at 11:12 PM Tony Noble  wrote:
>>
>>> If you could, please - details below:
>>>
>>> (GitHub id: TonyNoble , Jenkins Jira Id: StealthDJ)
>>>
>>> Thanks,
>>>
>>> Tony
>>>
>>>
>>>
>>> On Mon, Apr 8, 2019 at 2:04 PM Oleg Nenashev 
>>> wrote:
>>>
>>>> Yes, I think so.
>>>> Happy to do the transfer
>>>>
>>>> On Mon, Apr 8, 2019, 15:57 Tony Noble  wrote:
>>>>
>>>>> @ndeloof has explicitly stated he no longer maintains this plugin and
>>>>> that it is up for adoption (
>>>>> https://github.com/jenkinsci/changes-since-last-success-plugin/pull/3#issuecomment-476476085)
>>>>>
>>>>>
>>>>> Is it possible to transfer it across to me?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Tony
>>>>>
>>>>> On Wed, Mar 27, 2019 at 9:41 AM Tony Noble 
>>>>> wrote:
>>>>>
>>>>>> Looks like a fairly simple plugin.  I can take it if required and the
>>>>>> GSOC student doesn't wish to.
>>>>>>
>>>>>> Tony
>>>>>>
>>>>>> (GitHub id: TonyNoble , Jenkins Jira Id: StealthDJ)
>>>>>>
>>>>>>
>>>>>> On Wed, Mar 27, 2019 at 7:47 AM Oleg Nenashev 
>>>>>> wrote:
>>>>>>
>>>>>>> Hello Martin,
>>>>>>>
>>>>>>> Weird thing is that there are 3 exactly similar pull requests from
>>>>>>> different contributors. The students PR is the last one to be created, 
>>>>>>> so I
>>>>>>> I would rather close it as a duplicate TBH.
>>>>>>>
>>>>>>> W.r.t merge/release, I do not think we can do a lot without active
>>>>>>> maintainer there. Somebody would need to adopt the plugin and to cut a 
>>>>>>> new
>>>>>>> release.
>>>>>>> https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Oleg
>>>>>>>
>>>>>>>
>>>>>>> On Tuesday, March 26, 2019 at 9:58:30 PM UTC+1, martinda wrote:
>>>>>>>>
>>>>>>>> A GSoC student wants to merge a trivial fix to a plugin that no
>>>>>>>> longer has a maintainer.
>>>>>>>>
>>>>>>>> The plugin is changes-since-last-success-plugin
>>>>>>>> <https://plugins.jenkins.io/changes-since-last-success> (ndeloof
>>>>>>>> is no longer the maintainer as per this message
>>>>>>>> <https://groups.google.com/d/msg/jenkinsci-dev/BLIfRisUyag/MX7lfaDKBAAJ>
>>>>>>>> )
>>>>>>>>
>>>>>>>> The PR is:
>>>>>>>>
>>>>>>>> https://github.com/jenkinsci/changes-since-last-success-plugin/pull/3
>>>>>>>>
>>>>>>>> How does the student proceed?
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Martin
>>>>>>>>
>>>>>>> --
>>>>>>> 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
>>>>>>>

Re: How to merge fixes to plugins with no maintainer

[Tony Noble]

Sorry, to be a pain, but this doesn't seem to have come through yet.  Can
anyone assist?

Cheers,

Tony

On Tue, Apr 9, 2019 at 11:12 PM Tony Noble  wrote:

> If you could, please - details below:
>
> (GitHub id: TonyNoble , Jenkins Jira Id: StealthDJ)
>
> Thanks,
>
> Tony
>
>
>
> On Mon, Apr 8, 2019 at 2:04 PM Oleg Nenashev 
> wrote:
>
>> Yes, I think so.
>> Happy to do the transfer
>>
>> On Mon, Apr 8, 2019, 15:57 Tony Noble  wrote:
>>
>>> @ndeloof has explicitly stated he no longer maintains this plugin and
>>> that it is up for adoption (
>>> https://github.com/jenkinsci/changes-since-last-success-plugin/pull/3#issuecomment-476476085)
>>>
>>>
>>> Is it possible to transfer it across to me?
>>>
>>> Thanks,
>>>
>>> Tony
>>>
>>> On Wed, Mar 27, 2019 at 9:41 AM Tony Noble  wrote:
>>>
>>>> Looks like a fairly simple plugin.  I can take it if required and the
>>>> GSOC student doesn't wish to.
>>>>
>>>> Tony
>>>>
>>>> (GitHub id: TonyNoble , Jenkins Jira Id: StealthDJ)
>>>>
>>>>
>>>> On Wed, Mar 27, 2019 at 7:47 AM Oleg Nenashev 
>>>> wrote:
>>>>
>>>>> Hello Martin,
>>>>>
>>>>> Weird thing is that there are 3 exactly similar pull requests from
>>>>> different contributors. The students PR is the last one to be created, so 
>>>>> I
>>>>> I would rather close it as a duplicate TBH.
>>>>>
>>>>> W.r.t merge/release, I do not think we can do a lot without active
>>>>> maintainer there. Somebody would need to adopt the plugin and to cut a new
>>>>> release.
>>>>> https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin
>>>>>
>>>>> Best regards,
>>>>> Oleg
>>>>>
>>>>>
>>>>> On Tuesday, March 26, 2019 at 9:58:30 PM UTC+1, martinda wrote:
>>>>>>
>>>>>> A GSoC student wants to merge a trivial fix to a plugin that no
>>>>>> longer has a maintainer.
>>>>>>
>>>>>> The plugin is changes-since-last-success-plugin
>>>>>> <https://plugins.jenkins.io/changes-since-last-success> (ndeloof is
>>>>>> no longer the maintainer as per this message
>>>>>> <https://groups.google.com/d/msg/jenkinsci-dev/BLIfRisUyag/MX7lfaDKBAAJ>
>>>>>> )
>>>>>>
>>>>>> The PR is:
>>>>>> https://github.com/jenkinsci/changes-since-last-success-plugin/pull/3
>>>>>>
>>>>>> How does the student proceed?
>>>>>>
>>>>>> Thanks,
>>>>>> Martin
>>>>>>
>>>>> --
>>>>> 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/dbb7b139-f5fe-4e69-8940-5c6bb291e949%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/dbb7b139-f5fe-4e69-8940-5c6bb291e949%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 a topic in the
>>> Google Groups "Jenkins Developers" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/jenkinsci-dev/886mRunmnTI/unsubscribe.
>>> To unsubscribe from this group and all its topics, 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/CAEWqh9GWTtcP8gEG-MawgEUX19hwXdu8BsKNkErJU1CC%3DdPMDA%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAEWqh9GWTtcP8gEG-MawgEUX19hwXdu8BsKNkErJU1CC%3DdPMDA%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/CAPfivLDaCe8oC1KK3Qt5inoaVBYCw-Fofpjfmdc_saF9ERHUBg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDaCe8oC1KK3Qt5inoaVBYCw-Fofpjfmdc_saF9ERHUBg%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/CAEWqh9Fbv1hDHJ%3DgKLhf21j9XYZHh3w4B2a%3DYNOtPscY176YVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to merge fixes to plugins with no maintainer

[Tony Noble]

If you could, please - details below:

(GitHub id: TonyNoble , Jenkins Jira Id: StealthDJ)

Thanks,

Tony



On Mon, Apr 8, 2019 at 2:04 PM Oleg Nenashev  wrote:

> Yes, I think so.
> Happy to do the transfer
>
> On Mon, Apr 8, 2019, 15:57 Tony Noble  wrote:
>
>> @ndeloof has explicitly stated he no longer maintains this plugin and
>> that it is up for adoption (
>> https://github.com/jenkinsci/changes-since-last-success-plugin/pull/3#issuecomment-476476085)
>>
>>
>> Is it possible to transfer it across to me?
>>
>> Thanks,
>>
>> Tony
>>
>> On Wed, Mar 27, 2019 at 9:41 AM Tony Noble  wrote:
>>
>>> Looks like a fairly simple plugin.  I can take it if required and the
>>> GSOC student doesn't wish to.
>>>
>>> Tony
>>>
>>> (GitHub id: TonyNoble , Jenkins Jira Id: StealthDJ)
>>>
>>>
>>> On Wed, Mar 27, 2019 at 7:47 AM Oleg Nenashev 
>>> wrote:
>>>
>>>> Hello Martin,
>>>>
>>>> Weird thing is that there are 3 exactly similar pull requests from
>>>> different contributors. The students PR is the last one to be created, so I
>>>> I would rather close it as a duplicate TBH.
>>>>
>>>> W.r.t merge/release, I do not think we can do a lot without active
>>>> maintainer there. Somebody would need to adopt the plugin and to cut a new
>>>> release.
>>>> https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin
>>>>
>>>> Best regards,
>>>> Oleg
>>>>
>>>>
>>>> On Tuesday, March 26, 2019 at 9:58:30 PM UTC+1, martinda wrote:
>>>>>
>>>>> A GSoC student wants to merge a trivial fix to a plugin that no longer
>>>>> has a maintainer.
>>>>>
>>>>> The plugin is changes-since-last-success-plugin
>>>>> <https://plugins.jenkins.io/changes-since-last-success> (ndeloof is
>>>>> no longer the maintainer as per this message
>>>>> <https://groups.google.com/d/msg/jenkinsci-dev/BLIfRisUyag/MX7lfaDKBAAJ>
>>>>> )
>>>>>
>>>>> The PR is:
>>>>> https://github.com/jenkinsci/changes-since-last-success-plugin/pull/3
>>>>>
>>>>> How does the student proceed?
>>>>>
>>>>> Thanks,
>>>>> Martin
>>>>>
>>>> --
>>>> 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/dbb7b139-f5fe-4e69-8940-5c6bb291e949%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/jenkinsci-dev/dbb7b139-f5fe-4e69-8940-5c6bb291e949%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 a topic in the
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/jenkinsci-dev/886mRunmnTI/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/CAEWqh9GWTtcP8gEG-MawgEUX19hwXdu8BsKNkErJU1CC%3DdPMDA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/CAEWqh9GWTtcP8gEG-MawgEUX19hwXdu8BsKNkErJU1CC%3DdPMDA%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/CAPfivLDaCe8oC1KK3Qt5inoaVBYCw-Fofpjfmdc_saF9ERHUBg%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLDaCe8oC1KK3Qt5inoaVBYCw-Fofpjfmdc_saF9ERHUBg%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/CAEWqh9Hg19NS0CeiHV3kfVjCDU6J3_s8Ec1fgtSNONYAjEZdsg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to merge fixes to plugins with no maintainer

[Tony Noble]

@ndeloof has explicitly stated he no longer maintains this plugin and that
it is up for adoption (
https://github.com/jenkinsci/changes-since-last-success-plugin/pull/3#issuecomment-476476085)


Is it possible to transfer it across to me?

Thanks,

Tony

On Wed, Mar 27, 2019 at 9:41 AM Tony Noble  wrote:

> Looks like a fairly simple plugin.  I can take it if required and the GSOC
> student doesn't wish to.
>
> Tony
>
> (GitHub id: TonyNoble , Jenkins Jira Id: StealthDJ)
>
>
> On Wed, Mar 27, 2019 at 7:47 AM Oleg Nenashev 
> wrote:
>
>> Hello Martin,
>>
>> Weird thing is that there are 3 exactly similar pull requests from
>> different contributors. The students PR is the last one to be created, so I
>> I would rather close it as a duplicate TBH.
>>
>> W.r.t merge/release, I do not think we can do a lot without active
>> maintainer there. Somebody would need to adopt the plugin and to cut a new
>> release.
>> https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin
>>
>> Best regards,
>> Oleg
>>
>>
>> On Tuesday, March 26, 2019 at 9:58:30 PM UTC+1, martinda wrote:
>>>
>>> A GSoC student wants to merge a trivial fix to a plugin that no longer
>>> has a maintainer.
>>>
>>> The plugin is changes-since-last-success-plugin
>>> <https://plugins.jenkins.io/changes-since-last-success> (ndeloof is no
>>> longer the maintainer as per this message
>>> <https://groups.google.com/d/msg/jenkinsci-dev/BLIfRisUyag/MX7lfaDKBAAJ>
>>> )
>>>
>>> The PR is:
>>> https://github.com/jenkinsci/changes-since-last-success-plugin/pull/3
>>>
>>> How does the student proceed?
>>>
>>> Thanks,
>>> Martin
>>>
>> --
>> 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/dbb7b139-f5fe-4e69-8940-5c6bb291e949%40googlegroups.com
>> <https://groups.google.com/d/msgid/jenkinsci-dev/dbb7b139-f5fe-4e69-8940-5c6bb291e949%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/CAEWqh9GWTtcP8gEG-MawgEUX19hwXdu8BsKNkErJU1CC%3DdPMDA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to merge fixes to plugins with no maintainer

[Tony Noble]

Looks like a fairly simple plugin.  I can take it if required and the GSOC
student doesn't wish to.

Tony

(GitHub id: TonyNoble , Jenkins Jira Id: StealthDJ)


On Wed, Mar 27, 2019 at 7:47 AM Oleg Nenashev 
wrote:

> Hello Martin,
>
> Weird thing is that there are 3 exactly similar pull requests from
> different contributors. The students PR is the last one to be created, so I
> I would rather close it as a duplicate TBH.
>
> W.r.t merge/release, I do not think we can do a lot without active
> maintainer there. Somebody would need to adopt the plugin and to cut a new
> release.
> https://wiki.jenkins.io/display/JENKINS/Adopt+a+Plugin
>
> Best regards,
> Oleg
>
>
> On Tuesday, March 26, 2019 at 9:58:30 PM UTC+1, martinda wrote:
>>
>> A GSoC student wants to merge a trivial fix to a plugin that no longer
>> has a maintainer.
>>
>> The plugin is changes-since-last-success-plugin
>>  (ndeloof is no
>> longer the maintainer as per this message
>> )
>>
>> The PR is:
>> https://github.com/jenkinsci/changes-since-last-success-plugin/pull/3
>>
>> How does the student proceed?
>>
>> Thanks,
>> Martin
>>
> --
> 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/dbb7b139-f5fe-4e69-8940-5c6bb291e949%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/CAEWqh9EptJZs2N%3DAesaJFVouO50mP_poyx2nccDhd__7ahos4A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Disposable Jenkins & GitOps do not make a good match

[Tony Noble]

This is something that can be annoying at times.

Would it not make sense to for Jenkins to at least attempt to parse the
pipeline script when the job is created / amended?  Even if it ignores
'stages' and just looks at 'parameters' and 'triggers', that would at least
get round not only this issue but also the need to write pipelines in such
a way that they don't cause mayhem when running for the first time with no
parameter definitions (or with parameter definitions that are no longer
correct).

Tony


On Mon, Dec 3, 2018 at 12:38 PM Tomas Bjerre 
wrote:

> But I don't configure the trigger part with a pipeline script.
>
> I use Job DSL to create a pipeline job. In that pipeline job I configure
> the triggering-part with Job DSL and only keep the build process in the
> pipeline script.
>
> Then I don't have to run the pipeline script once before it all works.
>
> Like this:
>
> pipelineJob("my pipeline job") {
>  triggers {
>    // Job DSL with triggering configuration
>  }
>
>  definition {
>   cps {
>script(...) //Pipeline with build process
>sandbox()
>   }
>  }
> }
>
>
>
>
> Den mån 3 dec. 2018 kl 13:20 skrev domi :
>
>> Hi Tomas,
>> I do this too, but this does not mean I don’t have to start the build at
>> least once to make the webhooks work.
>> /Domi
>>
>> On 3 Dec 2018, at 09:25, Tomas Bjerre  wrote:
>>
>> Regarding configuration of webhooks with pipelines. This is why I always
>> configure that with Job DSL. I configure the Jenkins job and the Git
>> service (usually some rest-call) in the same Groovy (Job DSL) script.
>>
>> Den måndag 3 december 2018 kl. 09:15:05 UTC+1 skrev domi:
>>>
>>> Thanks Jesse, it probably is, but even though - do you see a chance to
>>> fix the issues I mentioned?
>>> e.g. why do I need to run a pipeline once before it accepts webhooks
>>> from GitHub or Bitbucket? I do understand that I can configure additional
>>> SCM sources from within a pipeline, but why does it not listen on the one I
>>> have defined on the I have defined to load the "Pipeline from SCM”?
>>> /Domi
>>>
>>> > On 30 Nov 2018, at 17:59, Jesse Glick  wrote:
>>> >
>>> > The simplest approach, starting from what you are doing now, would be
>>> > to keep the build records and other state files from your Jenkins
>>> > installation, recreating only the configuration files from Git.
>>> >
>>> > --
>>> > 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/CANfRfr1W_8-%3DU8GJSuw_oazA0PSiXGyYDhv8mSKzLV0bScStFg%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/d21bf102-f345-4c6b-a234-4ab8ad3c6995%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/jenkinsci-dev/1gc8t6MAl4g/unsubscribe.
>> To unsubscribe from this group and all its topics, 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/A03F3239-D428-4EC3-8167-E7C3AD02CE7C%40fortysix.ch
>> 
>> .
>> 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/CAK89W5K9YFGn%2BC4rELF12u68QOY%2Bye978a1SJCrQwJ%2Bs8h6N2g%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 

Re: Request to become maintainer of the Parameterized Remote Trigger Plugin

[Tony Noble]

I did spend some time looking at that PR, but it appears as though there is
still work to be done on it, or at least, changes requested.

Is that not the case?  I got a little lost trying to figure out what was
still to be done.

Tony

On Tue, Apr 24, 2018 at 12:18 PM, 'Alexander Link' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Hi,
>
>
>
> as Oleg mentioned we did many changes to this plugin in the last 2 years –
> in our fork unfortunately, since contribution did not work due to missing
> maintainers.
>
> You find *all* changes in our openSource branch: https://github.com/sap-
> production/parameterized-remote-trigger-plugin/tree/openSource
>
>
>
> We don’t have enough resources to become maintainers ourselves, but we are
> happy to support you with this plugin.
>
>
>
> My recommendation would be to decide on this PR first to avoid later
> conflicts: https://github.com/jenkinsci/parameterized-remote-trigger-
> plugin/pull/32
>
>
>
> Kind regards, Alex
>
>
>
> PS: Here some additional comments about the Pull Request:
>
> https://github.com/jenkinsci/parameterized-remote-trigger-
> plugin/pull/32#issuecomment-373000207
>
> https://github.com/jenkinsci/parameterized-remote-trigger-
> plugin/pull/32#issuecomment-338175831
>
>
>
>
> Am Dienstag, 24. April 2018 10:31:16 UTC+2 schrieb Oleg Nenashev:
>>
>> I would like to point out that there is a major work being done on
>> Pipeline compatibility in https://github.com/jenkinsci/p
>> arameterized-remote-trigger-plugin/pull/32 . It would be great to invite
>> Alejandra Ferreiro Vidal and Alexander Link to this discussion. Will do
>> that.
>>
>> BR, Oleg
>>
>> On Monday, April 23, 2018 at 8:13:54 AM UTC+2, Kai-Hsiang Chang wrote:
>>>
>>> @Tony, thx for the cc.
>>>
>>> github id: cashlalala
>>> Jenkins JIRA id: cashlalala
>>>
>>> Tony Noble於 2018年4月20日星期五 UTC+8下午8時41分52秒寫道：
>>>>
>>>> I'll happily co-maintain if required.  There's a PR needing to be
>>>> merged to make it work with CSRF protection (that I've suggested a minor
>>>> change to) that really could do with being applied, amongst others.
>>>>
>>>> Christoph shows as last person to make any git commits, so I've cc'd
>>>> him.
>>>>
>>>> Tony
>>>>
>>>> github id: TonyNoble
>>>> Jenkins JIRA id: stealthdj
>>>>
>>>> On Fri, Apr 20, 2018 at 9:11 AM, Daniel Beck <m...@beckweb.net> wrote:
>>>>
>>>>>
>>>>> > On 20. Apr 2018, at 03:51, Kai-Hsiang Chang <cash...@gmail.com>
>>>>> wrote:
>>>>> >
>>>>> > this plugin hasn't been updated for at least 2 years,
>>>>> >
>>>>> > I'd like to ask the permission to maintain the plugin.
>>>>> >
>>>>> > please help me with that.
>>>>> >
>>>>>
>>>>> Please follow the instructions from https://wiki.jenkins.io/displa
>>>>> y/JENKINS/Adopt+a+Plugin#AdoptaPlugin-IknowwhichpluginIwanttohelpwith,
>>>>> whatshouldIdonow?
>>>>>
>>>>> --
>>>>> 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/EA80C67F-95F
>>>>> 0-4E4C-A83C-4451B8439B56%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/372bf671-47a6-4fa1-ae10-132599a3ca28%
> 40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/372bf671-47a6-4fa1-ae10-132599a3ca28%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/CAEWqh9Ea8ee-CS2WJp8ikex-%2Bbe1wHfAwQD0ojCcgsfjbeZcnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request to become maintainer of the Parameterized Remote Trigger Plugin

[Tony Noble]

I'll happily co-maintain if required.  There's a PR needing to be merged to
make it work with CSRF protection (that I've suggested a minor change to)
that really could do with being applied, amongst others.

Christoph shows as last person to make any git commits, so I've cc'd him.

Tony

github id: TonyNoble
Jenkins JIRA id: stealthdj

On Fri, Apr 20, 2018 at 9:11 AM, Daniel Beck  wrote:

>
> > On 20. Apr 2018, at 03:51, Kai-Hsiang Chang  wrote:
> >
> > this plugin hasn't been updated for at least 2 years,
> >
> > I'd like to ask the permission to maintain the plugin.
> >
> > please help me with that.
> >
>
> Please follow the instructions from https://wiki.jenkins.io/
> display/JENKINS/Adopt+a+Plugin#AdoptaPlugin-IknowwhichpluginIwanttohelpwit
> h,whatshouldIdonow?
>
> --
> 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/EA80C67F-95F0-4E4C-A83C-4451B8439B56%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/CAEWqh9HLeeV3Z-kbohH8CAsbnH_mKfgzMiy%2BHrPezCUJJ2r%3DGw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: URLTrigger plugin maintainer

[Tony Noble]

Hi Oleg,

Thanks.  The change I have in mind would be cleaner if at least some of the
work was done in EnvInject plugin - do I need to be added as a maintainer
for this as well?

Tony

On Wed, Jan 31, 2018 at 7:44 AM, Oleg Nenashev <o.v.nenas...@gmail.com>
wrote:

> Hi Tony,
>
> Yes, the plugin is not being actively developed. There are some
> discussions about reworking the underlying EnvInject and XTrigger
> libraries, but we are not there yet. Any contributions will br more than
> welcome.
>
> I have granted you permissions, you should receive an invitation to the
> jenkinsci GitHub organization soon.
> Please update the Wiki and release permissions
> <https://github.com/jenkins-infra/repository-permissions-updater/> before
> doing the release.
>
> Welcome aboard!
>
> BR, Oleg
>
> понедельник, 29 января 2018 г., 18:47:32 UTC+1 пользователь Tony Noble
> написал:
>>
>> Hi,
>>
>> I was looking to suggest some changes / fixes to this plugin as it's one
>> I use on a daily basis.  However, I note the plugin is looking for a
>> maintainer, so I guess it's not actively being developed?
>>
>> I'm happy to take on maintenance of this plugin, if this is the case - my
>> github id is TonyNoble and Jenkins infrastructure id is StealthDJ
>>
>> Cheers,
>>
>> Tony
>>
> --
> 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/58786d4b-d8a5-43d1-896a-c0e769b8162d%
> 40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/58786d4b-d8a5-43d1-896a-c0e769b8162d%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/CAEWqh9EBGcBSdLL4r6%3D7M%2BFX%2ByK765b1TppZifhAfcavT-MFgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

URLTrigger plugin maintainer

[Tony Noble]

Hi,

I was looking to suggest some changes / fixes to this plugin as it's one I 
use on a daily basis.  However, I note the plugin is looking for a 
maintainer, so I guess it's not actively being developed?

I'm happy to take on maintenance of this plugin, if this is the case - my 
github id is TonyNoble and Jenkins infrastructure id is StealthDJ

Cheers,

Tony

-- 
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/2927653a-2bcd-48a0-8be7-2284ee2c4ff8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.