Re: Docker agent build script wrapper

[Oleksandr Rudak]

>
> We have reached acceptable solution for the problem. It is loading groovy 
> script with black magic around closure. Attaching code for the community 
> benefit.
>

It boils down to construct in the loaded groovy module:
def container(myImageName, Closure body){
docker.image(myImageName).inside(dockerArgs(), body)
}


 And then using it passing closure body:
def myImage = 'php:latest'
def modelId = drun.modelId()

echo modelId

drun.container(myImage) {
stage ('setup'){
sh 'id'
echo 'value = ' + modelId
}

stage('stage 1'){
sh '/usr/local/bin/php -version'
}
}

There is also custom step returning map of properties from the environment 
implemented as Java class:
public class DrunPropertiesStep extends Step {
...
public static class Execution extends SynchronousStepExecution {
private static final long serialVersionUID = 1;

Execution(StepContext context) {
super(context);
}

@Override
protected Object run() throws Exception {
Run run = getContext().get(Run.class);
//todo: implement

JSONObject json = Utils.getJson(run.getRootDir().getPath(), 
run.getLogReader());

Map map = new HashMap();
Iterator iter = json.keys();
while( iter.hasNext() ) {
String key = iter.next().toString();

map.put(key, json.getString(key));
}

return map;
}
}
...
}

Hope it will help to prevent someone from banging a head against the 
keyboard :)

Thanks
Alex

-- 
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/3cd3005a-9a64-48a4-b67b-2cae076d0e93%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


drun.groovy
Description: Binary data


Jenkinsfile
Description: Binary data

Re: Removing the Everyone team in the jenkinsci GitHub org

[Daniel Beck]

> On 30. Nov 2017, at 00:17, Kanstantsin Shautsou  
> wrote:
> 
> Kohsuke, do you publicly approve that jenkins is not the bazaar anymore?

Could we please keep this thread focused on the specific proposed initiative?

-- 
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/DEB6ED3C-255C-4047-9C5A-C63706E1B7EA%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: Removing the Everyone team in the jenkinsci GitHub org

[Kanstantsin Shautsou]

Last time Kohsuke blocked this question with his veto because jenkinsci 
should be a bazaar model (and everybody should be able to work on any 
plugin). 
What happened since last time when i (and some other persons) tried to 
implement this and remove RW from everyone? 
*Kohsuke, do you publicly approve that jenkins is not the bazaar anymore? *
PS Or JEP now removes King of project position?

Thanks.
On Tuesday, November 28, 2017 at 6:58:53 AM UTC+3, Kohsuke Kawaguchi wrote:
>
> Thanks for driving this. 
>
> If this change inadvertently remove somebody's commit access, presumably 
> we expect people to follow this 
> 
>  and 
> mail this list?
>
> On Mon, Nov 27, 2017 at 4:25 PM Daniel Beck  > wrote:
>
>> Hi everyone,
>>
>> For a long time, we didn't really manage GitHub permissions for plugins: 
>> We just added new repos and contributors to the 'Everyone' team, giving 
>> everyone access to everything, and that was it. Contrary to its name, it 
>> doesn't actually include _everyone_, at least not anymore: We've moved away 
>> from adding people to the Everyone team over a year ago. But it still has 
>> hundreds of members, and provides write access to more than 1200 
>> repositories.
>>
>> While contributors are mostly well-behaved, we've occasionally seen PRs 
>> merged by people who weren't regular contributors to those plugins, 
>> resulting in conflict with actual maintainers. Since these users cannot 
>> release the plugins anyway, the benefit of being able to do this is 
>> questionable at best. Not to mention the problem of malicious or accidental 
>> data loss through people force-pushing into Git (this, accidentally, has 
>> happened with dozens -- hundreds? -- of repositories back in 2015, and 
>> caused a considerable mess).
>>
>> I know that quite a few plugin maintainers have long removed the Everyone 
>> team from their plugin repositories to prevent such problems, but the 
>> default is still to add the team to a new plugin repo.
>>
>> Given the size of the Jenkins project, this is untenable. I plan to 
>> remove the Everyone team from all repositories, instead granting direct 
>> access to contributors who previously got their write access from the 
>> Everyone team. This way, we should be able to retain access for those who 
>> legitimately have it, while removing those who have no relationship to any 
>> particular plugin.
>>
>> Right now, I plan to grant direct write access to a plugin to users who:
>>
>> 1. Have write access to a repository through the Everyone team only
>> 2. Are considered 'contributors' by GitHub (meaning they have commits 
>> associated with them in the repo)
>> 3. Have at least 5 'contributions' (~commits in the contributors graph)
>>
>> The first two should be obvious (with the caveat that badly set up GH 
>> accounts -- their commits not associated with the account -- will lose 
>> access). The third is where it gets tricky: Not everyone who contributed to 
>> a repository, and currently has write access to it via 'Everyone' team, 
>> should legitimately have write access to it in the future. Unfortunately, 
>> GitHub makes it impossible to efficiently determine who has performed 
>> various maintainer-specific actions, such as created a release tag, or 
>> merged a pull request -- and these might still miss legitimate 
>> co-maintainers who just don't have direct access.
>>
>> So I will instead use a minimum number (currently 5) of contributions 
>> required for someone to retain access. Once we've drastically limited who 
>> has access to any given repo, we can always fine-tune this later. There 
>> will also be a log of what changed so this can be referenced later in case 
>> of questions related to lost permissions.
>>
>> While this may be a painful change if the above rules get the needed 
>> permissions wrong, it's an important one, and I'm trying to make it as 
>> smooth as possible. Please bring up your concerns and questions in this 
>> thread and I'll do my best to address them.
>>
>> I don't think this is JEPable, as this doesn't actually create a 
>> longer-running process, it's just a one-time legacy permission migration.
>>
>> Daniel
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-de...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/ABF8E55F-0896-4DD0-AB07-6778F39F5A10%40beckweb.net
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
> Kohsuke Kawaguchi
>

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

Re: Asking for commiter access to amazon-ecs-plugin

[Yaramada Surya tej]

Hi Mathus,
  It would be great if any one can change the maintainer of 
this plugin to Douglas as he is willing to took it so that we can utilize 
this plugin , many of us are waiting to get this pull request merged.


Thanks
Surya

On Thursday, 7 September 2017 17:33:57 UTC-4, Baptiste Mathus wrote:
>
> Hello,
> Seems like Jan is not active either these days or anymore at all.
>
> So either you can see if you want to adopt this plugin (in that case 
> please follow the process described on the wiki), or this is likely to stay 
> this way until someone does I suspect.
>
> Baptiste
>
> Le 7 sept. 2017 17:22, "Surya yaramada`"  
> a écrit :
>
>> Hi,
>>  I am sorry for interrupting again but can I please know if there is 
>> a chance to merge the pull requests for AMAZON-ECS plugin.
>>
>>
>> Thanks 
>> Surya
>>
>> On Thursday, August 24, 2017 at 4:12:47 PM UTC-4, Daniel Beck wrote:
>>>
>>>
>>> > On 24. Aug 2017, at 22:09, Surya yaramada`  
>>> wrote: 
>>> > 
>>> >  Can I get any updates on this? 
>>> > 
>>>
>>> There's no need for multiple emails per day. Give him a week or so. Jan 
>>> may well be on vacation. 
>>>
>>> -- 
>> 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/4f569b34-cfb3-427f-adc3-40406f9c6b3e%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/491f8e18-fbe5-4dd5-b9fe-8d274d517487%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Remote Parameterized Trigger Plugin

[Nabel Sawiris]

I can be the maintainer, do I need to start a new thread?

GitHub and Jenkins Id are both: n360speed

>
> > I think that if you have questions about taking over the plugin you 
> could ask Daniel Beck (https://github.com/daniel-beck). 
>
> I'm reading :-) 
>
>

-- 
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/0d5b6f12-89f6-459a-95b3-0502dd68608f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Samuel Van Oort]

> Am I the only one to think it strange that we are discussing using 
very limited core developer resources to replace a library used 
pervasively throughout the Jenkins code base with a functionally 
identical library with no demonstrable benefit to users and rather 
marginal impact on developers

No, you're not -- I'd also like to see a case where profiling shows simple 
log formatting is a significant bottleneck.  If it wasn't an impactful 
change I'd say "sure, micro-optimize" but after seeing applications broken 
due to SLF4J API changes it seems like a risky change which is only 
beneficial in edge cases (high logging throughput). 

Now, I *have* seen bottlenecks around AnnotatedLargeText and console 
annotation -- particularly in pipeline, although the logging there is 
getting a rework anyway that will reduce the impact of that.  

If we want to optimize logging performance,* I think it makes more sense to 
target the build logging APIs for optimization, specifically the I/O bits *-- 
there's some room to optimize the way we use & interact with the streams, 
and use more modern NIO APIs.  Would also like to see reuse of buffers, 
because this is a *key cause* of high GC pressure from Jenkins if you're 
touching small log files, and one of the main reasons we see hundreds of 
MB/s of object garbage generated (continuously reallocating byte arrays 
that could be reused).  Remoting is another cause of GC pressure (depending 
on the protocol used).

On Tuesday, November 28, 2017 at 10:35:54 AM UTC-5, Jesse Glick wrote:
>
> On Mon, Nov 27, 2017 at 7:56 PM, Stephen Connolly 
>  wrote: 
> > any other user provided handler could [also queue unformatted log 
> records] 
>
> Theoretically. I cannot think of any such case. Handlers are known to 
> be registered by Jenkins core; the `support-core` plugin; and the 
> servlet container. 
>
> Am I the only one to think it strange that we are discussing using 
> very limited core developer resources to replace a library used 
> pervasively throughout the Jenkins code base with a functionally 
> identical library with no demonstrable benefit to users and rather 
> marginal impact on developers? 
>

-- 
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/e29c3d2f-85fe-43ad-a0df-2b96fd9e6fe1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins 2.89.1 LTS RC testing started

[Jesse Glick]

On Wed, Nov 29, 2017 at 9:33 AM, Daniel Beck  wrote:
> We missed https://issues.jenkins-ci.org/browse/JENKINS-47909 because it was 
> kept open.

Oops, my fault for not double-checking JIRA after seeing that the PR was merged.

> https://github.com/jenkinsci/jenkins/commit/7c06a9ba946800151c5d9fc38793ac4bbd3fea5f
>  seems reasonably straightforward, could we still include this?

I would recommend backporting it at least to .2 if it is too late for
.1. The fix seems rather safe, and for those users affected by the bug
the regression was pretty serious. (Yes there was a workaround, but
you would need to find it, and in the meantime you have a complete
service outage.)

-- 
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/CANfRfr1FQVoDVdvCrnNfJhVDW8iHvza5oup3sZr%3DeaCymBBEvw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [PROPOSAL] Split js-libs repo in individual repos (one per module)

[Jesse Glick]

On Wed, Nov 29, 2017 at 6:47 AM, Victor Martinez
 wrote:
> I'd like to purpose to standardise as individual git repos therefore their
> release lifecycle and versioning can be independent and also get the
> benefits of using different parent POM versions.

+1, makes sense. `maven-release-plugin` _can_ be run in subdirectories
but that is really not the conventional usage.

> I know it might be a bit of
> overwhelming work (git repos, move history, Jenkins pipelines...)

Probably not that hard. I would not bother moving history (i.e., `git
filter-branch` black magic) in this case, since there are only 126
commits, and the history is not all that interesting—it is not likely
someone three years from now is going to want to `git bisect` why some
version number was incremented in a `package.json`.

> no
> idea how to proceed (maybe raising a jira ticket in case we agree)

Probably just requires the usual `HOSTING` ticket if there is
consensus. Do you expect to help maintain this stuff? Adding Tom
Fennelly to CC.

-- 
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/CANfRfr39S6foTNMjbatbvijTjMYd-teyo9ft%3DNQXd66ypw_ULQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Jenkins 2.89.1 LTS RC testing started

[Daniel Beck]

> On 23. Nov 2017, at 12:44, Daniel Beck  wrote:
> 
> https://issues.jenkins-ci.org/issues/?jql=labels%20%3D%202.89.1-fixed are the 
> backported fixes.

We missed https://issues.jenkins-ci.org/browse/JENKINS-47909 because it was 
kept open.

https://github.com/jenkinsci/jenkins/commit/7c06a9ba946800151c5d9fc38793ac4bbd3fea5f
 seems reasonably straightforward, could we still include this? WDYT?

-- 
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/DB09A730-F56D-480F-B9A1-BB9DFD117686%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: Removing the Everyone team in the jenkinsci GitHub org

[Daniel Beck]

> On 29. Nov 2017, at 09:56, Ullrich Hafner  wrote:
> 
> Seems that I still can push changes to my repositories but I cannot access 
> the settings anymore (e.g., edit the description, view the collaborators).

AFAICT you never were. I've looked into this about a year ago already, and you 
stood out as _the_ maintainer getting permissions from Everyone team -- and 
that has long (always?) only granted Write access.

> Is this doable per IRC bot? 

Yes, as that bot adds to per-repo team, which will still be around.

> How should the new structure in collaborators look like? I’m not sure if I 
> just missed that part in your mail…
> Should there be only a * developers team? Or should there be a developers and 
> admin team? Or individual users?

Details TBD. I currently plan to make people collaborators with write access. 
This will need to be cleaned up some time in the future, but speculatively 
granting additional permissions (most per-repo teams grant admin access) 
doesn't sit right with me.

> BTW: you also need to update 
> https://jenkins.io/projects/infrastructure/ircbot/

Yep, thanks. The comment 'make NAME a committer' will need to be removed, only 
'make NAME a committer of REPO' will remain. We've only used the latter for a 
while now anyway.

-- 
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/19674B47-638B-4040-B9A4-F3009138E3AE%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: Remote Parameterized Trigger Plugin

[Daniel Beck]

> On 29. Nov 2017, at 09:45, Alejandra Ferreiro Vidal 
>  wrote:
> 
> I did not get a reply for my last comment in this group.

It didn't look like needing a response from anyone but eventual maintainers, 
and nobody has spoken up so far.

While Alejandra, a colleague of Alexander, dropped off their patch in 
https://github.com/jenkinsci/parameterized-remote-trigger-plugin/pull/32 (and 
me not realizing it's related to this thread…), it still needs someone to take 
over the responsibility to release and follow up on issues.

> I think that if you have questions about taking over the plugin you could ask 
> Daniel Beck (https://github.com/daniel-beck).

I'm reading :-)

-- 
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/F1F23AEB-9908-4CE7-8943-4CEF1A3A7908%40beckweb.net.
For more options, visit https://groups.google.com/d/optout.

Re: Removing the Everyone team in the jenkinsci GitHub org

[Robert Sandell]

I don't think I've ever been able to access the settings and edit the
description of the repos I maintain :'(

/B

2017-11-29 9:56 GMT+01:00 Ullrich Hafner :

> Seems that I still can push changes to my repositories but I cannot access
> the settings anymore (e.g., edit the description, view the collaborators).
> Is this doable per IRC bot?
>
> How should the new structure in collaborators look like? I’m not sure if I
> just missed that part in your mail…
> Should there be only a * developers team? Or should there be a developers
> and admin team? Or individual users?
>
> BTW: you also need to update https://jenkins.io/projects/
> infrastructure/ircbot/
>
> Am 28.11.2017 um 01:25 schrieb Daniel Beck :
>
> Hi everyone,
>
> For a long time, we didn't really manage GitHub permissions for plugins:
> We just added new repos and contributors to the 'Everyone' team, giving
> everyone access to everything, and that was it. Contrary to its name, it
> doesn't actually include _everyone_, at least not anymore: We've moved away
> from adding people to the Everyone team over a year ago. But it still has
> hundreds of members, and provides write access to more than 1200
> repositories.
>
> While contributors are mostly well-behaved, we've occasionally seen PRs
> merged by people who weren't regular contributors to those plugins,
> resulting in conflict with actual maintainers. Since these users cannot
> release the plugins anyway, the benefit of being able to do this is
> questionable at best. Not to mention the problem of malicious or accidental
> data loss through people force-pushing into Git (this, accidentally, has
> happened with dozens -- hundreds? -- of repositories back in 2015, and
> caused a considerable mess).
>
> I know that quite a few plugin maintainers have long removed the Everyone
> team from their plugin repositories to prevent such problems, but the
> default is still to add the team to a new plugin repo.
>
> Given the size of the Jenkins project, this is untenable. I plan to remove
> the Everyone team from all repositories, instead granting direct access to
> contributors who previously got their write access from the Everyone team.
> This way, we should be able to retain access for those who legitimately
> have it, while removing those who have no relationship to any particular
> plugin.
>
> Right now, I plan to grant direct write access to a plugin to users who:
>
> 1. Have write access to a repository through the Everyone team only
> 2. Are considered 'contributors' by GitHub (meaning they have commits
> associated with them in the repo)
> 3. Have at least 5 'contributions' (~commits in the contributors graph)
>
> The first two should be obvious (with the caveat that badly set up GH
> accounts -- their commits not associated with the account -- will lose
> access). The third is where it gets tricky: Not everyone who contributed to
> a repository, and currently has write access to it via 'Everyone' team,
> should legitimately have write access to it in the future. Unfortunately,
> GitHub makes it impossible to efficiently determine who has performed
> various maintainer-specific actions, such as created a release tag, or
> merged a pull request -- and these might still miss legitimate
> co-maintainers who just don't have direct access.
>
> So I will instead use a minimum number (currently 5) of contributions
> required for someone to retain access. Once we've drastically limited who
> has access to any given repo, we can always fine-tune this later. There
> will also be a log of what changed so this can be referenced later in case
> of questions related to lost permissions.
>
> While this may be a painful change if the above rules get the needed
> permissions wrong, it's an important one, and I'm trying to make it as
> smooth as possible. Please bring up your concerns and questions in this
> thread and I'll do my best to address them.
>
> I don't think this is JEPable, as this doesn't actually create a
> longer-running process, it's just a one-time legacy permission migration.
>
> Daniel
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/ABF8E55F-0896-4DD0-AB07-6778F39F5A10%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/C5B832CF-81CD-4E41-A332-02835A4904A9%40gmail.com
> 

Re: Coexistence of two equal plugins

[Robert Sandell]

Class full name and artifact id, changing group id has no effect.

/B

2017-11-29 4:53 GMT+01:00 Slide :

> Please don't double post.
>
> On Tue, Nov 28, 2017, 16:50 Virginia Mesa  wrote:
>
>> Hi, I modified a Jenkins plugin in which there was a drop-down and I
>> wanted a textbox. Once modified, my idea was to upload this version of
>> plugin and at the same time keep the previous one unchanged, so as not to
>> disrupt the execution of other jobs that use it. I have changed the
>> idartifactory, the name of the Display ... in short, all the possible
>> identifiers that I have found. But I do not know why, even though I install
>> it as two different plugins ... when I'm going to add the step, it just
>> finds me one ... it's like I know it's the same and it's overwritten. Does
>> anyone know how it is that Jenkins identifies the plugins? Thank you very
>> much, A greeting.
>>
>> --
>> 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/8231fd62-0a0b-44b4-b3ac-9eac4141230e%
>> 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/CAPiUgVcA7BBSByFpLYbhF6kLc2P5j
> -2hJ_x1H7y35zndFTq55g%40mail.gmail.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Robert Sandell
*Software Engineer*
*CloudBees Inc.*

-- 
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/CALzHZS0yyQK-EGFw2N5fDqz65ftnBaRhrmbjOyd5nhpvFw8UQg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[PROPOSAL] Split js-libs repo in individual repos (one per module)

[Victor Martinez]

Hi there,

I've seen when using maven multimodes git repos in Jenkins plugins are 
mostly based on the same general versioning, such as the previous 
pipeline-plugin , blueocean 
, but I've found a minor 
discrepancy in that particular assumption and it's about the js-libs 
.

This particular repo combine different plugins and each plugin is a maven 
module with a different version, for instance:

   - ace-editor 
    got 1.2.2 
   version
   - bootstrap  got 
   1.3.3 version
   - numeraljs  got 
   1.1.1 version
   - ...

I'd like to purpose to standardise as individual git repos therefore their 
release lifecycle and versioning can be independent and also get the 
benefits of using different parent POM versions. I know it might be a bit 
of overwhelming work (git repos, move history, Jenkins pipelines...), and 
no idea how to proceed (maybe raising a jira ticket in case we agree) but 
IMO it's worth to keep some homogenous standard. What do you think? 

Cheers

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/82ccb4a1-ef4f-4e9d-8fd0-63984c6a6264%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Removing the Everyone team in the jenkinsci GitHub org

[Ullrich Hafner]

Seems that I still can push changes to my repositories but I cannot access the 
settings anymore (e.g., edit the description, view the collaborators). Is this 
doable per IRC bot?

How should the new structure in collaborators look like? I’m not sure if I just 
missed that part in your mail…
Should there be only a * developers team? Or should there be a developers and 
admin team? Or individual users?

BTW: you also need to update https://jenkins.io/projects/infrastructure/ircbot/ 


> Am 28.11.2017 um 01:25 schrieb Daniel Beck :
> 
> Hi everyone,
> 
> For a long time, we didn't really manage GitHub permissions for plugins: We 
> just added new repos and contributors to the 'Everyone' team, giving everyone 
> access to everything, and that was it. Contrary to its name, it doesn't 
> actually include _everyone_, at least not anymore: We've moved away from 
> adding people to the Everyone team over a year ago. But it still has hundreds 
> of members, and provides write access to more than 1200 repositories.
> 
> While contributors are mostly well-behaved, we've occasionally seen PRs 
> merged by people who weren't regular contributors to those plugins, resulting 
> in conflict with actual maintainers. Since these users cannot release the 
> plugins anyway, the benefit of being able to do this is questionable at best. 
> Not to mention the problem of malicious or accidental data loss through 
> people force-pushing into Git (this, accidentally, has happened with dozens 
> -- hundreds? -- of repositories back in 2015, and caused a considerable mess).
> 
> I know that quite a few plugin maintainers have long removed the Everyone 
> team from their plugin repositories to prevent such problems, but the default 
> is still to add the team to a new plugin repo.
> 
> Given the size of the Jenkins project, this is untenable. I plan to remove 
> the Everyone team from all repositories, instead granting direct access to 
> contributors who previously got their write access from the Everyone team. 
> This way, we should be able to retain access for those who legitimately have 
> it, while removing those who have no relationship to any particular plugin.
> 
> Right now, I plan to grant direct write access to a plugin to users who:
> 
> 1. Have write access to a repository through the Everyone team only
> 2. Are considered 'contributors' by GitHub (meaning they have commits 
> associated with them in the repo)
> 3. Have at least 5 'contributions' (~commits in the contributors graph)
> 
> The first two should be obvious (with the caveat that badly set up GH 
> accounts -- their commits not associated with the account -- will lose 
> access). The third is where it gets tricky: Not everyone who contributed to a 
> repository, and currently has write access to it via 'Everyone' team, should 
> legitimately have write access to it in the future. Unfortunately, GitHub 
> makes it impossible to efficiently determine who has performed various 
> maintainer-specific actions, such as created a release tag, or merged a pull 
> request -- and these might still miss legitimate co-maintainers who just 
> don't have direct access.
> 
> So I will instead use a minimum number (currently 5) of contributions 
> required for someone to retain access. Once we've drastically limited who has 
> access to any given repo, we can always fine-tune this later. There will also 
> be a log of what changed so this can be referenced later in case of questions 
> related to lost permissions.
> 
> While this may be a painful change if the above rules get the needed 
> permissions wrong, it's an important one, and I'm trying to make it as smooth 
> as possible. Please bring up your concerns and questions in this thread and 
> I'll do my best to address them.
> 
> I don't think this is JEPable, as this doesn't actually create a 
> longer-running process, it's just a one-time legacy permission migration.
> 
> Daniel
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/ABF8E55F-0896-4DD0-AB07-6778F39F5A10%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/C5B832CF-81CD-4E41-A332-02835A4904A9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

Re: Remote Parameterized Trigger Plugin

[Alejandra Ferreiro Vidal]

Hi Nabel,

There is no one committed to maintain this plugin. It would be great if you 
request to be a maintainer 
https://jenkins.io/project/governance/#helping-and-taking-over-dormant-plugins, 
and also if you merge the pull request 
https://github.com/jenkinsci/parameterized-remote-trigger-plugin/pull/32.

I did not get a reply for my last comment in this group. I think that if 
you have questions about taking over the plugin you could ask Daniel Beck 
(https://github.com/daniel-beck).

Best regards,
Alejandra


El martes, 28 de noviembre de 2017, 19:27:46 (UTC+1), Nabel Sawiris 
escribió:
>
> Did anyone ever get access to commit? I was hoping to request to be a 
> maintainer as well. I found that the plugin was doing a fire and forget, so 
> I fixed that with one of my pull requests. I also see pull request 
> https://github.com/jenkinsci/parameterized-remote-trigger-plugin/pull/32 is 
> pretty much ready to be commited.
>
> On Tuesday, May 16, 2017 at 11:20:11 AM UTC-7, Kevin Phillips wrote:
>>
>> I'd like to offer my assistance with the Remote Parameterized Trigger 
>> plugin project. There are a handful of issues and merge requests reported 
>> against the project, with minimal activity in recent months, and I think I 
>> could help move some of these forward. 
>>
>> I have extensive experience with the Jenkins REST API which I think would 
>> overlap nicely with this particular plugin.
>>
>> If I could be granted commit access to this repo that would be great. I'm 
>> not sure if there is an official maintainer for the plugin, but if not I 
>> wouldn't mind adopting that responsibility as well.
>>
>> My GitHub ID is TheFriendlyCoder, and my Jenkins account ID is leedega.
>>
>> Kevin
>>
>

-- 
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/4dc530c3-3e06-4f72-b8cd-24cf008930dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.