Re: Grant timja immediate permissions to commons-lang3-api plugin

[Raihaan Shouhell]

+1

This is break is quite severe

Cheers,
Raihaan

On Tue, Jul 19, 2022, 1:20 PM Basil Crow  wrote:

> +UINT64_MAX
>
> On Mon, Jul 18, 2022 at 8:31 PM Mark Waite 
> wrote:
>
>> A release of the Apache mina API plugins (core and common) have exposed a
>> cyclic dependency between the mina plugins, configuration as code, and
>> other plugins.  Details are into from
>> https://issues.jenkins.io/browse/JENKINS-69034
>>  .
>> A workaround is available, but a fix would be much better for users than
>> the workaround.
>>
>> The preferred fix needs a new release of the commons-lang3-api plugin
>> .  The current
>> maintainer has not responded to previous requests nor to the current
>> request
>> 
>> that asks to grant Tim Jacomb permission to maintain the plugin.
>>
>> The usual process would require a 2 week wait for the adoption request to
>> "time out".  I propose an exception in this case based on the need to
>> deliver a new release of the commons-lang3-api-plugin.  Tim is the Jenkins
>> release officer, a long-standing contributor to the Jenkins project, and a
>> strong contributor.
>>
>> I propose that Tim be granted permission immediately to maintain the  
>> commons-lang3-api
>> plugin  as
>> requested in the RPU pull request
>> 
>> .
>>
>> Mark Waite
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/d7ca0365-4600-4097-8dd4-d3c9f93e5327n%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/CAFwNDjrbhAkTTe48on0nY105HbZJCrOx8Yt5MS%3Ddf%3D0sL1Pm4A%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/CAFoxvgw2%2Bdk9UjUOits7hvF4M-qK_H5RLXJHqaEpjwmASa3VLA%40mail.gmail.com.

Re: Grant timja immediate permissions to commons-lang3-api plugin

[Basil Crow]

+UINT64_MAX

On Mon, Jul 18, 2022 at 8:31 PM Mark Waite 
wrote:

> A release of the Apache mina API plugins (core and common) have exposed a
> cyclic dependency between the mina plugins, configuration as code, and
> other plugins.  Details are into from
> https://issues.jenkins.io/browse/JENKINS-69034
>  .
> A workaround is available, but a fix would be much better for users than
> the workaround.
>
> The preferred fix needs a new release of the commons-lang3-api plugin
> .  The current
> maintainer has not responded to previous requests nor to the current
> request
> 
> that asks to grant Tim Jacomb permission to maintain the plugin.
>
> The usual process would require a 2 week wait for the adoption request to
> "time out".  I propose an exception in this case based on the need to
> deliver a new release of the commons-lang3-api-plugin.  Tim is the Jenkins
> release officer, a long-standing contributor to the Jenkins project, and a
> strong contributor.
>
> I propose that Tim be granted permission immediately to maintain the  
> commons-lang3-api
> plugin  as
> requested in the RPU pull request
> 
> .
>
> Mark Waite
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/d7ca0365-4600-4097-8dd4-d3c9f93e5327n%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/CAFwNDjrbhAkTTe48on0nY105HbZJCrOx8Yt5MS%3Ddf%3D0sL1Pm4A%40mail.gmail.com.

Re: Grant timja immediate permissions to commons-lang3-api plugin

['Gavin Mogan' via Jenkins Developers]

your first link doesn't actually goto
https://issues.jenkins.io/browse/JENKINS-69034

I'm very much +1 with the mess of that sshd plugin has caused all day.
I've been redirecting threads and issues and stuff.

Gavin

On Mon, Jul 18, 2022 at 8:31 PM Mark Waite  wrote:
>
> A release of the Apache mina API plugins (core and common) have exposed a 
> cyclic dependency between the mina plugins, configuration as code, and other 
> plugins.  Details are into from 
> https://issues.jenkins.io/browse/JENKINS-69034 .  A workaround is available, 
> but a fix would be much better for users than the workaround.
>
> The preferred fix needs a new release of the commons-lang3-api plugin.  The 
> current maintainer has not responded to previous requests nor to the current 
> request that asks to grant Tim Jacomb permission to maintain the plugin.
>
> The usual process would require a 2 week wait for the adoption request to 
> "time out".  I propose an exception in this case based on the need to deliver 
> a new release of the commons-lang3-api-plugin.  Tim is the Jenkins release 
> officer, a long-standing contributor to the Jenkins project, and a strong 
> contributor.
>
> I propose that Tim be granted permission immediately to maintain the  
> commons-lang3-api plugin as requested in the RPU pull request.
>
> Mark Waite
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/d7ca0365-4600-4097-8dd4-d3c9f93e5327n%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/CAG%3D_Dusji%2B10cuJwT6E78tOSS4bjTg9hQg1F8werY6e3599AVw%40mail.gmail.com.

Grant timja immediate permissions to commons-lang3-api plugin

[Mark Waite]

A release of the Apache mina API plugins (core and common) have exposed a 
cyclic dependency between the mina plugins, configuration as code, and 
other plugins.  Details are into from 
https://issues.jenkins.io/browse/JENKINS-69034 
 .  
A workaround is available, but a fix would be much better for users than 
the workaround.

The preferred fix needs a new release of the commons-lang3-api plugin 
.  The current 
maintainer has not responded to previous requests nor to the current request 
 
that asks to grant Tim Jacomb permission to maintain the plugin.

The usual process would require a 2 week wait for the adoption request to 
"time out".  I propose an exception in this case based on the need to 
deliver a new release of the commons-lang3-api-plugin.  Tim is the Jenkins 
release officer, a long-standing contributor to the Jenkins project, and a 
strong contributor.

I propose that Tim be granted permission immediately to maintain the  
commons-lang3-api 
plugin  as 
requested in the RPU pull request 
.

Mark Waite

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

[Stapler Framework Support for IntelliJ] StackOverflow fix testing

['Denys Digtiar' via Jenkins Developers]

If you've been using the Stapler Framework Support IntelliJ plugin to edit 
Jelly files, you might have noticed the StackOverflowError in the JetBrains 
error reporter. The bug is tracked in 
https://github.com/jenkinsci/idea-stapler-plugin/issues/66

I tried to fix it. It is a somewhat significant change. Given the dearth of 
automated tests, I wonder if any brave souls are willing to test the PR. 
See https://github.com/jenkinsci/idea-stapler-plugin/pull/99  
on how to build 
and install it. I am interested if you can detect any regressions. Or find 
any Jelly files that still cause StackOverflowError.

-- 
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/8d66cdbd-779f-4ae7-81a1-9bae41c81dd6n%40googlegroups.com.

Re: Let renovate handle dependency updates in jenkinsci/jenkins

[Basil Crow]

On Mon, Jul 18, 2022 at 2:48 PM Alexander Brandes  wrote:
> Although, I don't think we need two bots alongside for different package 
> ecosystems, when one bot can do both.

We do if we want to optimize globally (organization-wide) rather than
locally (repository-wide) for decreased cognitive load, as I already
explained in my last post. And successful long-term maintenance
involves carefully managing cognitive load, so I think we do want to
optimize globally. Combining multiple Java dependency updates together
is indeed an advantage, but I do not think it is a compelling enough
advantage to deviate from the technology stack we already use to
manage Jenkins plugin Java dependencies given the concomitant
permanent increase in cognitive load associated with using two
different technology stacks concurrently for the same purpose
(managing Java dependencies). If combining multiple Java dependency
updates together is the only advantage, then I would be in favor of
changing the technology stack used for managing Jenkins core Java
dependencies if and only if the technology stack used to manage
Jenkins plugin Java dependencies were also changed.

-- 
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/CAFwNDjrHUe4mN-oN529FVXKHOrdYXWyp_BphCqW5TC5qkNo8sQ%40mail.gmail.com.

Re: Let renovate handle dependency updates in jenkinsci/jenkins

[Alexander Brandes]

> Is there a compelling reason to prefer Renovate for Jenkins core Java 
dependencies? 

dependabot and renovate can manage Java dependencies equally fine, the 
drawback for frontend deps apply here too, you get one PR each, if that is 
a reasonable and frequent concern (it is not from what I've seen).

Although, I don't think we need two bots alongside for different package 
ecosystems, when one bot can do both.
If renovate doesn't turn out well for Java dependency updates or exposes 
unforeseen issues that can't be fixed, we can still switch back to 
dependabot for java dependency updates.

On Monday, 18 July 2022 at 23:38:37 UTC+2 m...@basilcrow.com wrote:

> +1 for Renovate for JavaScript dependencies, for the reasons you have 
> pointed out: it does a better job of combining multiple updates 
> together, increasing the success rate of the resulting proposed 
> change. 
>
> Is there a compelling reason to prefer Renovate for Jenkins core Java 
> dependencies? I can think of one reason to prefer Dependabot in this 
> scenario: it is consistent with our technology choice for managing 
> Jenkins plugin Java dependencies. Using the same technology to manage 
> Jenkins core Java dependencies and Jenkins plugin Java dependencies 
> buys us the advantage of consistency and familiarity. For example, 
> over the years I have become familiar with Dependabot's 
> implementation, includings both its strengths and weaknesses, and I 
> have stepped through its Ruby code in a debugger on more than one 
> occasion to solve some mysteries (despite the fact that I am not much 
> of a Ruby programmer). Switching to a new technology stack for 
> managing Jenkins core Java dependencies while retaining the existing 
> technology stack for managing Jenkins plugin Java dependencies would 
> increase cognitive load by forcing developers to learn a new 
> technology stack (Renovate) while not allowing them to forget the 
> technology stack they already know (Dependabot). This wouldn't be out 
> of the question if the advantages were compelling enough, but you did 
> not present an argument that they were. 
>

-- 
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/2f480f44-920c-4523-987d-8cd598477fa7n%40googlegroups.com.

Re: Let renovate handle dependency updates in jenkinsci/jenkins

[Basil Crow]

+1 for Renovate for JavaScript dependencies, for the reasons you have
pointed out: it does a better job of combining multiple updates
together, increasing the success rate of the resulting proposed
change.

Is there a compelling reason to prefer Renovate for Jenkins core Java
dependencies? I can think of one reason to prefer Dependabot in this
scenario: it is consistent with our technology choice for managing
Jenkins plugin Java dependencies. Using the same technology to manage
Jenkins core Java dependencies and Jenkins plugin Java dependencies
buys us the advantage of consistency and familiarity. For example,
over the years I have become familiar with Dependabot's
implementation, includings both its strengths and weaknesses, and I
have stepped through its Ruby code in a debugger on more than one
occasion to solve some mysteries (despite the fact that I am not much
of a Ruby programmer). Switching to a new technology stack for
managing Jenkins core Java dependencies while retaining the existing
technology stack for managing Jenkins plugin Java dependencies would
increase cognitive load by forcing developers to learn a new
technology stack (Renovate) while not allowing them to forget the
technology stack they already know (Dependabot). This wouldn't be out
of the question if the advantages were compelling enough, but you did
not present an argument that they were.

-- 
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/CAFwNDjr_DJ8zvbUZGSER97wCU0ce-L50jvTNGeykWYf10ORhWg%40mail.gmail.com.

Re: Let renovate handle dependency updates in jenkinsci/jenkins

[Tim Jacomb]

+1 for renovate for at least JS deps, dependabot doesn’t support yarn v3
either so we would need to move at that point anyway

On Mon, 18 Jul 2022 at 22:09, 'Gavin Mogan' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> I'm a big fan of renovate, so I think its a good idea, but I also
> don't touch core, so have no idea what the impact would be.
>
> On Mon, Jul 18, 2022 at 1:19 PM Alexander Brandes 
> wrote:
> >
> > Small ammandment: The semantic commit messages on the PoC can be turned
> off, but are picked up, because recent (my) commits use them.
> >
> > On Monday, 18 July 2022 at 22:15:32 UTC+2 Alexander Brandes wrote:
> >>
> >> Hey everyone,
> >>
> >> dependabot does a good job at handling single artifacts, but it does a
> bad to no job handling modules of monorepos, see babel -cli, -core, -env,
> etc. for example.
> >>
> >> This typically leads me to moving several submodule dependency update
> PRs into a single PR, before reviewing, considering updating one part of a
> dependency without the other often doesn't work out well.
> >> See #6878 and #6879 landing in #6877 for such a case.
> >> This is just one example, there are more dependencies that fall into
> this category.
> >>
> >> I create a PoC of using renovate over dependabot on core available on
> https://github.com/NotMyFault/jenkins-renovate-poc
> >> renovate is very well able to create these kinds of "merged" PRs for
> submodules of a dependency, see #4 for example.
> >>
> >> For the reasons outlined above, I'd like to see renovate to handle
> dependency updates in core in the future.
> >>
> >> Kind regards
> >> 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/456baae8-e49f-4d87-8d3e-0038257ea5d4n%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/CAG%3D_DuusFce4CdvXeoxb6Hck_t2kiOs77%3DoE5Hz8J6H%2BM0ZxsA%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/CAH-3BicFOunUH429B%3DByT3Dg0P05aNgTusuBzc2zRyiY4EoBxw%40mail.gmail.com.

Re: Let renovate handle dependency updates in jenkinsci/jenkins

[Alexander Brandes]

> don't touch core, so have no idea what the impact would be.

The PoC contains a renovate file 

 instead 
of the dependabot file, but the configuration has been carried over.
The transition would be a drop in replacement, if renovate is already 
installed on the org, otherwise someone with the sufficient permissions has 
to do that and enable it for core.

> I'm a big fan of renovate, so I think its a good idea

So am I, using it frequently in other projects.

On Monday, 18 July 2022 at 23:09:33 UTC+2 ga...@gavinmogan.com wrote:

> I'm a big fan of renovate, so I think its a good idea, but I also
> don't touch core, so have no idea what the impact would be.
>
> On Mon, Jul 18, 2022 at 1:19 PM Alexander Brandes  
> wrote:
> >
> > Small ammandment: The semantic commit messages on the PoC can be turned 
> off, but are picked up, because recent (my) commits use them.
> >
> > On Monday, 18 July 2022 at 22:15:32 UTC+2 Alexander Brandes wrote:
> >>
> >> Hey everyone,
> >>
> >> dependabot does a good job at handling single artifacts, but it does a 
> bad to no job handling modules of monorepos, see babel -cli, -core, -env, 
> etc. for example.
> >>
> >> This typically leads me to moving several submodule dependency update 
> PRs into a single PR, before reviewing, considering updating one part of a 
> dependency without the other often doesn't work out well.
> >> See #6878 and #6879 landing in #6877 for such a case.
> >> This is just one example, there are more dependencies that fall into 
> this category.
> >>
> >> I create a PoC of using renovate over dependabot on core available on 
> https://github.com/NotMyFault/jenkins-renovate-poc
> >> renovate is very well able to create these kinds of "merged" PRs for 
> submodules of a dependency, see #4 for example.
> >>
> >> For the reasons outlined above, I'd like to see renovate to handle 
> dependency updates in core in the future.
> >>
> >> Kind regards
> >> 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-de...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/jenkinsci-dev/456baae8-e49f-4d87-8d3e-0038257ea5d4n%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/c31229b2-2391-4d41-8961-330b64791644n%40googlegroups.com.

Re: Let renovate handle dependency updates in jenkinsci/jenkins

['Gavin Mogan' via Jenkins Developers]

I'm a big fan of renovate, so I think its a good idea, but I also
don't touch core, so have no idea what the impact would be.

On Mon, Jul 18, 2022 at 1:19 PM Alexander Brandes  wrote:
>
> Small ammandment: The semantic commit messages on the PoC can be turned off, 
> but are picked up, because recent (my) commits use them.
>
> On Monday, 18 July 2022 at 22:15:32 UTC+2 Alexander Brandes wrote:
>>
>> Hey everyone,
>>
>> dependabot does a good job at handling single artifacts, but it does a bad 
>> to no job handling modules of monorepos, see babel -cli, -core, -env, etc. 
>> for example.
>>
>> This typically leads me to moving several submodule dependency update PRs 
>> into a single PR, before reviewing, considering updating one part of a 
>> dependency without the other often doesn't work out well.
>> See #6878 and #6879 landing in #6877 for such a case.
>> This is just one example, there are more dependencies that fall into this 
>> category.
>>
>> I create a PoC of using renovate over dependabot on core available on 
>> https://github.com/NotMyFault/jenkins-renovate-poc
>> renovate is very well able to create these kinds of "merged" PRs for 
>> submodules of a dependency, see #4 for example.
>>
>> For the reasons outlined above, I'd like to see renovate to handle 
>> dependency updates in core in the future.
>>
>> Kind regards
>> 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/456baae8-e49f-4d87-8d3e-0038257ea5d4n%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/CAG%3D_DuusFce4CdvXeoxb6Hck_t2kiOs77%3DoE5Hz8J6H%2BM0ZxsA%40mail.gmail.com.

Re: Releasing a new plugin fails due to 'Check interesting categories' failure

['Gavin Mogan' via Jenkins Developers]

gh api /repos/jenkinsci/bmc-change-manager-imstm-plugin/releases
10++ jq -e -r '.[] | select(.draft == true and .name == "next") | .body'
11++ egrep '[⚠]|:(boom|tada|construction_worker):'

Seems like it gets "releases" for the plugin, looks for a draft named
"next" and then checks for any of those emojis/phrases

I'm also not seeing a failure, just that it says there's no
interesting items in the release notes.


On Mon, Jul 18, 2022 at 12:22 PM Marit M  wrote:
>
> https://github.com/jenkinsci/bmc-change-manager-imstm-plugin/runs/7396269153?check_suite_focus=true
>
> Though I added an appropriate category label ( enhancement) to the PR before 
> merging.https://github.com/jenkinsci/bmc-change-manager-imstm-plugin/pull/2
>
> Please advise how to proceed.
> Thanks,
> Marit.
>
> --
> 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/2a4e7dc6-e7ce-4890-ab7a-ac5289babc2an%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/CAG%3D_DuvBqU%3D%3DRw00fEGoXiO2LnNN0zK6b5_nF5LXADYxx8pHUQ%40mail.gmail.com.

Re: Let renovate handle dependency updates in jenkinsci/jenkins

[Alexander Brandes]

Small ammandment: The semantic commit messages on the PoC can be turned 
off, but are picked up, because recent (my) commits use them.

On Monday, 18 July 2022 at 22:15:32 UTC+2 Alexander Brandes wrote:

> Hey everyone,
>
> dependabot does a good job at handling single artifacts, but it does a bad 
> to no job handling modules of monorepos, see babel -cli, -core, -env, etc. 
> for example.
>
> This typically leads me to moving several submodule dependency update PRs 
> into a single PR, before reviewing, considering updating one part of a 
> dependency without the other often doesn't work out well.
> See #6878  and #6879 
>  landing in #6877 
>  for such a case.
> This is just one example, there are more dependencies that fall into this 
> category.
>
> I create a PoC of using renovate over dependabot on core available on 
> https://github.com/NotMyFault/jenkins-renovate-poc
> renovate is very well able to create these kinds of "merged" PRs for 
> submodules of a dependency, see #4 
>  for example.
>
> For the reasons outlined above, I'd like to see renovate to handle 
> dependency updates in core in the future.
>
> Kind regards
> 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/456baae8-e49f-4d87-8d3e-0038257ea5d4n%40googlegroups.com.

Let renovate handle dependency updates in jenkinsci/jenkins

[Alexander Brandes]

Hey everyone,

dependabot does a good job at handling single artifacts, but it does a bad 
to no job handling modules of monorepos, see babel -cli, -core, -env, etc. 
for example.

This typically leads me to moving several submodule dependency update PRs 
into a single PR, before reviewing, considering updating one part of a 
dependency without the other often doesn't work out well.
See #6878  and #6879 
 landing in #6877 
 for such a case.
This is just one example, there are more dependencies that fall into this 
category.

I create a PoC of using renovate over dependabot on core available 
on https://github.com/NotMyFault/jenkins-renovate-poc
renovate is very well able to create these kinds of "merged" PRs for 
submodules of a dependency, see #4 
 for example.

For the reasons outlined above, I'd like to see renovate to handle 
dependency updates in core in the future.

Kind regards
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/d4fa35b6-c5df-49e7-825e-3c5c9611641dn%40googlegroups.com.

Re: java.lang.NoClassDefFoundError: hudson/os/PosixAPI

[Marit M]

Thanks, I updated the plugin parent POM to 4.32.

ב-יום שני, 18 ביולי 2022 בשעה 18:25:17 UTC+3, m...@basilcrow.com כתב/ה:

> As of jenkinsci/jenkins#6323 
>  (released in 2.338 
> ), you 
> need to be running jenkinsci/jenkins-test-harness#350 
>  (released in 
> 1657.vf8a824e79147 
> ),
>  
> included in the plugin parent POM starting with 4.32 
> .
>

-- 
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/a73947a4-fd38-4758-8eae-76aaadb181a2n%40googlegroups.com.

Releasing a new plugin fails due to 'Check interesting categories' failure

[Marit M]

https://github.com/jenkinsci/bmc-change-manager-imstm-plugin/runs/7396269153?check_suite_focus=true

Though I added *an appropriate category label* ( enhancement) to the PR 
before 
merging.https://github.com/jenkinsci/bmc-change-manager-imstm-plugin/pull/2

Please advise how to proceed.
Thanks,
Marit.

-- 
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/2a4e7dc6-e7ce-4890-ab7a-ac5289babc2an%40googlegroups.com.

Re: java.lang.NoClassDefFoundError: hudson/os/PosixAPI

[Basil Crow]

As of jenkinsci/jenkins#6323
 (released in 2.338
), you
need to be running jenkinsci/jenkins-test-harness#350
 (released in
1657.vf8a824e79147
),
included in the plugin parent POM starting with 4.32
.

-- 
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/CAFwNDjoEZ1drzQng1dk_NTep7yh-OCE-nN5G1oL1nsGEQZ8t1g%40mail.gmail.com.

java.lang.NoClassDefFoundError: hudson/os/PosixAPI

[Marit M]

Hi,

I'm trying to release a new plugin, and I get the following error:

https://ci.jenkins.io/job/Plugins/job/bmc-change-manager-imstm-plugin/view/change-requests/job/PR-1/4/console

*18:10:16* [INFO] --- 
*18:10:16* [INFO] T E S T S *18:10:16* [INFO] 
--- *18:10:17* [INFO] 
Running InjectedTest *18:10:17* [ERROR] Tests run: 1, Failures: 0, Errors: 
1, Skipped: 0, Time elapsed: 0.284 s <<< FAILURE! - in InjectedTest 
*18:10:17* [ERROR] initializationError(InjectedTest) Time elapsed: 0.022 s 
<<< ERROR! *18:10:17* java.lang.NoClassDefFoundError: hudson/os/PosixAPI 
*18:10:17*at 
org.jvnet.hudson.test.HudsonTestCase.(HudsonTestCase.java:1780)

Please advise how to proceed.

Thanks,
Marit.

-- 
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/fc28f9d0-ab82-491e-844d-11560f235827n%40googlegroups.com.

New Gradle Plugin for JTE Plugin

[steven...@gmail.com]

Hey everyone, 

I'm going to be publishing a Gradle plugin that extends the Gradle JPI 
Plugin  that allows users 
to package their libraries for the Jenkins Templating Engine 
 as their own 
stand-alone plugin.

Given this is a gradle plugin and not a Jenkins plugin, i'm trying to 
understand:

   1. How can I request that the Gradle JTE Plugin 
    repository be 
   forked into the jenkinsci organization?
   2. Are there any restrictions to who can post gradle plugins under the 
   jenkins namespace? 


Thank you!

-- 
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/d99a7ffd-5e46-4036-a8c7-55c9706a2cf4n%40googlegroups.com.