Re: Using JDK 11 instead of JDK 8 in default docker images

[Basil Crow]

Allow me to append myself to the list of developers who would like access
to Java 11 APIs. If we had access to Java 11 APIs, then this

(and similar code in a CloudBees-proprietary plugin) could be switched to
the Java Platform's ProcessHandle#pid() (to say nothing of ProcessTree in
Jenkins core), which would mean that we could get rid of JNR from Jenkins
core, which would mean that we could get rid of ASM from Jenkins core,
which would eliminate a long-standing pain point in the dependency tree.

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send 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-sMcNyCyjc%3DH1hoG4ziwOFdH2HbYj9EsSr6aATySMKQ%40mail.gmail.com.

Re: is the branch indexing needed for the plugins ci.jenkins.io?

[Victor Martinez]

Hi

Hello Victor, would you be able to attend tomorrow's Infra session (or does 
> it collide with yours?).
>
I think they don't clash, but I'm not sure though 

That would be a great discussion (sounds like webhooks and rebuild can be 
> discussed and at least clarified)
>
+1 :) 

Thanks a lot!
>
np
 

> I'm sorry i dont understand what your referring to. Do you mean that we do 
>> ci builds for each branch and pr? That seems like the main purpose of ci
>>
> Yes, you are right, ideally it should work like that but it's also 
expensive in terms of computing

What problem are you trying to solve?
>>
> I was curious about the existing configuration in the those projects and 
whether there was any threshold in terms of how often those branch indexing 
run and whether the obsoleted PRs should be part or not from that 
automation.

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

Re: Error handling in Groovy initialization scripts vs JCasC

[Jesse Glick]

On Thu, Jun 24, 2021 at 5:18 AM Ullrich Hafner 
wrote:

> I often have this problem that my working JCasC configuration suddenly
> breaks after an upgrade of JCasC (or another plugin) and Jenkins just not
> starts up. And then you need to dig into log files to see what happens. It
> would be much better if those errors would be reported in the UI
>

Maybe it depends on how you are using JCasC. If you treat your JCasC YAML
plus a pinned set of versions of Jenkins core and plugins as an atomic
configuration set describing your whole system, with a PR-type workflow,
then failing fast is a feature not a bug: if either a change to YAML *or* a
change to some component version causes a failure, then you can clearly see
that this is a bad PR and it should not be merged until the issue is
resolved.

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

Re: Error handling in Groovy initialization scripts vs JCasC

[Basil Crow]

On Thu, Jun 24, 2021 at 9:07 AM Tim Jacomb  wrote:
>
> There are some flags you can use to tune this behaviour:
> https://github.com/jenkinsci/configuration-as-code-plugin/blob/a6983ff60e0cf198ce02d7992bcba927197174db/test-harness/src/test/resources/io/jenkins/plugins/casc/validSelfConfig.yml#L1-L5

Those flags don't work in all cases. Try the following JCasC YAML file
when Theme Manager is installed but Dark Theme is not installed:

configuration-as-code:
 version: 1
 deprecated: warn
 restricted: warn
 unknown: warn

unclassified:
 themeManager:
   disableUserThemes: false
   theme: "darkSystem"

Jenkins will not start up.

Now try starting Jenkins with a
io.jenkins.plugins.thememanager.ThemeManagerPageDecorator.xml file
that references
io.jenkins.plugins.darktheme.DarkThemeSystemManagerFactory when Theme
Manager is installed but Dark Theme is not installed. Jenkins does
start up. (No warning is displayed and the default theme is used.)

I think the ideal behavior in both cases would be for Jenkins to start
up and display an administrative monitor warning that invalid
configuration was not applied. (Obviously, this would not apply to
security-related configuration per Antonio's point.)

> I think the consensus has been it's 'good enough', there's plenty of room for 
> improvement, but in general it works 'just fine' for most use-cases

I don't disagree. Yet I also recall listening to an interview with
Kohsuke where he explicitly talked about wanting to build a tool that
was not only good enough but also a pleasure to use. That seems like
an example worth following.

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

Re: is the branch indexing needed for the plugins ci.jenkins.io?

[Damien Duportal]

Hello Victor, would you be able to attend tomorrow's Infra session (or does 
it collide with yours?).

That would be a great discussion (sounds like webhooks and rebuild can be 
discussed and at least clarified)

Thanks a lot!

Damien

Le jeudi 24 juin 2021 à 17:35:12 UTC+2, ga...@gavinmogan.com a écrit :

> I'm sorry i dont understand what your referring to. Do you mean that we do 
> ci builds for each branch and pr? That seems like the main purpose of ci
>
> What problem are you trying to solve?
>
> On Thu., Jun. 24, 2021, 1:56 a.m. Victor Martinez,  
> wrote:
>
>> Hi there,
>>
>> I've seen the branch indexing enabled for the plugins in ci.jenkins.io, 
>> and I'm not sure if this is needed or something that should be skipped in 
>> terms of reducing the cost of the infrastructure.
>>
>> I did a quick search in the jenkins-infra org but I could not find any 
>> references to the GHOrganization that could answer my question.
>>
>> Thanks
>>
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to jenkinsci-de...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/jenkinsci-dev/c82620d0-4e7f-4b56-a3f9-19f66aadbcd9n%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/fd558ffa-9d42-4a03-925f-62638ff7e1a8n%40googlegroups.com.

Re: Error handling in Groovy initialization scripts vs JCasC

['Gavin Mogan' via Jenkins Developers]

I've had times when those groovy scripts "silently" fail on startup, and
while isn't a big deal when I'm just restarting an existing instance, it
does suck when I'm spinning up a new instance and suddely I don't have
security setup.

I used to pair my jcasc config with my jenkins docker image, so I could
roll back when things fail to start (I hit a helm bug and had to split them
up again). I like the idea in that case of not being able to spin up a
broken install. But I also understand that lots of people just tweak
existing installs, and probably want warnings without fatals for parsing.
So I really like that override behavior. I don't think the default should
be warn though since it could potentially lead to insecure setups.

On Thu, Jun 24, 2021 at 9:08 AM Tim Jacomb  wrote:

> There are some flags you can use to tune this behaviour:
>
> https://github.com/jenkinsci/configuration-as-code-plugin/blob/a6983ff60e0cf198ce02d7992bcba927197174db/test-harness/src/test/resources/io/jenkins/plugins/casc/validSelfConfig.yml#L1-L5
>
> The default is to show an error page with what failed.
>
> > I concur. My initial impression is that JCasC lacks polish, and I was
> > surprised to see it promoted so heavily when issues like this remain.
>
> I think the consensus has been it's 'good enough', there's plenty of room
> for improvement, but in general it works 'just fine' for most use-cases
>
>
>
> On Thu, 24 Jun 2021 at 16:54, Basil Crow  wrote:
>
>> On Thu, Jun 24, 2021 at 2:18 AM Ullrich Hafner 
>> wrote:
>> > This is a very bad user experience (actually I don’t know of any other
>> application that does not start because of a configuration error).
>>
>> I concur. My initial impression is that JCasC lacks polish, and I was
>> surprised to see it promoted so heavily when issues like this remain.
>>
>> > This is also the approach that we are using if a plugin changes
>> serialization (or if a plugin cannot be started because of missing
>> dependencies): in this case Jenkins still continues to work and the
>> problems are highlighted in the UI.
>>
>> Core isn't entirely consistent in this regard, either. Yes
>> OldDataMonitor and PluginWrapperAdministrativeMonitor exist. But I
>> just tried corrupting core's config.xml file and Jenkins wouldn't
>> start at all. But when I corrupted Email Extension's
>> hudson.plugins.emailext.ExtendedEmailPublisher.xml, Jenkins started
>> but with the default values for Email Extension and no administrative
>> monitor in the UI. The latter clearly could use some improvement, but
>> I'm not sure about the former. It seems that we want _some_
>> configuration loading errors to be fatal. But which ones, exactly? In
>> the JCasC issue on GitHub, Antonio raised the valid point that errors
>> in loading security-related configuration should be fatal (for obvious
>> reasons).
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Jenkins Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to jenkinsci-dev+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjrLf3jJ-dTk%2BOX1E4b2%3DvB2rsWDFgMX0%2BzKNHMbcgRcJA%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-3BidoM3VfGS%2B4hiMs5dncaVywyrVm7OMt%3DZN6Yj%2BCTDwCyA%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/CAG%3D_Duvc4Ai%3D6PXbkTXgOkH4K%2BOU7FbLT5ZE7UR9Y%3Dzymxp%2Byw%40mail.gmail.com.

Re: Error handling in Groovy initialization scripts vs JCasC

[Tim Jacomb]

There are some flags you can use to tune this behaviour:
https://github.com/jenkinsci/configuration-as-code-plugin/blob/a6983ff60e0cf198ce02d7992bcba927197174db/test-harness/src/test/resources/io/jenkins/plugins/casc/validSelfConfig.yml#L1-L5

The default is to show an error page with what failed.

> I concur. My initial impression is that JCasC lacks polish, and I was
> surprised to see it promoted so heavily when issues like this remain.

I think the consensus has been it's 'good enough', there's plenty of room
for improvement, but in general it works 'just fine' for most use-cases



On Thu, 24 Jun 2021 at 16:54, Basil Crow  wrote:

> On Thu, Jun 24, 2021 at 2:18 AM Ullrich Hafner 
> wrote:
> > This is a very bad user experience (actually I don’t know of any other
> application that does not start because of a configuration error).
>
> I concur. My initial impression is that JCasC lacks polish, and I was
> surprised to see it promoted so heavily when issues like this remain.
>
> > This is also the approach that we are using if a plugin changes
> serialization (or if a plugin cannot be started because of missing
> dependencies): in this case Jenkins still continues to work and the
> problems are highlighted in the UI.
>
> Core isn't entirely consistent in this regard, either. Yes
> OldDataMonitor and PluginWrapperAdministrativeMonitor exist. But I
> just tried corrupting core's config.xml file and Jenkins wouldn't
> start at all. But when I corrupted Email Extension's
> hudson.plugins.emailext.ExtendedEmailPublisher.xml, Jenkins started
> but with the default values for Email Extension and no administrative
> monitor in the UI. The latter clearly could use some improvement, but
> I'm not sure about the former. It seems that we want _some_
> configuration loading errors to be fatal. But which ones, exactly? In
> the JCasC issue on GitHub, Antonio raised the valid point that errors
> in loading security-related configuration should be fatal (for obvious
> reasons).
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjrLf3jJ-dTk%2BOX1E4b2%3DvB2rsWDFgMX0%2BzKNHMbcgRcJA%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-3BidoM3VfGS%2B4hiMs5dncaVywyrVm7OMt%3DZN6Yj%2BCTDwCyA%40mail.gmail.com.

Re: Error handling in Groovy initialization scripts vs JCasC

[Basil Crow]

On Thu, Jun 24, 2021 at 2:18 AM Ullrich Hafner  wrote:
> This is a very bad user experience (actually I don’t know of any other 
> application that does not start because of a configuration error).

I concur. My initial impression is that JCasC lacks polish, and I was
surprised to see it promoted so heavily when issues like this remain.

> This is also the approach that we are using if a plugin changes serialization 
> (or if a plugin cannot be started because of missing dependencies): in this 
> case Jenkins still continues to work and the problems are highlighted in the 
> UI.

Core isn't entirely consistent in this regard, either. Yes
OldDataMonitor and PluginWrapperAdministrativeMonitor exist. But I
just tried corrupting core's config.xml file and Jenkins wouldn't
start at all. But when I corrupted Email Extension's
hudson.plugins.emailext.ExtendedEmailPublisher.xml, Jenkins started
but with the default values for Email Extension and no administrative
monitor in the UI. The latter clearly could use some improvement, but
I'm not sure about the former. It seems that we want _some_
configuration loading errors to be fatal. But which ones, exactly? In
the JCasC issue on GitHub, Antonio raised the valid point that errors
in loading security-related configuration should be fatal (for obvious
reasons).

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

Re: is the branch indexing needed for the plugins ci.jenkins.io?

['Gavin Mogan' via Jenkins Developers]

I'm sorry i dont understand what your referring to. Do you mean that we do
ci builds for each branch and pr? That seems like the main purpose of ci

What problem are you trying to solve?

On Thu., Jun. 24, 2021, 1:56 a.m. Victor Martinez, <
victormartinezru...@gmail.com> wrote:

> Hi there,
>
> I've seen the branch indexing enabled for the plugins in ci.jenkins.io,
> and I'm not sure if this is needed or something that should be skipped in
> terms of reducing the cost of the infrastructure.
>
> I did a quick search in the jenkins-infra org but I could not find any
> references to the GHOrganization that could answer my question.
>
> Thanks
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/c82620d0-4e7f-4b56-a3f9-19f66aadbcd9n%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_DuucKQ7jk%3DCo0tnsbOtPX2bB7KKFaLT1_dZ18Ea9XZtHEA%40mail.gmail.com.

Re: Adoption of plugin Google Container Registry Auth

[Vincent Gerris]

Hi, any updates on this?
I have not been able to fix this tests yet, it seems Mockito related.
If you can help a bit with that Wei, I am happy to take this over if nobody 
responds.
A simply change to the line that has the quote is probably also good, then 
the issue is gone too.

On Saturday, May 15, 2021 at 5:43:36 PM UTC+2 Oleg Nenashev wrote:

> Hello, thanks for the response!
> What would be an approximate response timeline?
>
> Thanks in advance,
> Oleg
>
> On Wed, May 12, 2021 at 6:15 PM wei zheng  wrote:
>
>> I am no longer working for Google. 
>>
>> I am contacting my friends in Google and see if they can find the 
>> relevant team to maintain it.
>>
>> Thanks.
>>
>>
>> On Wed, May 5, 2021 at 1:52 AM Oleg Nenashev  wrote:
>>
>>> CCed Wei Z who is currently listed as the plugin maintainer. According 
>>> to the plugin adoption policy 
>>> , 
>>> we will wait for 2 weeks for a response. An earlier response will be 
>>> appreciated!
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/57dbe7fb-11b8-453a-88b7-de45e6042f5an%40googlegroups.com.

Re: Error handling in Groovy initialization scripts vs JCasC

[Antonio Muñiz]

Cf. https://github.com/jenkinsci/configuration-as-code-plugin/issues/912

On Thu, 24 Jun 2021 at 11:18, Ullrich Hafner 
wrote:

>
>
> > Am 24.06.2021 um 00:54 schrieb Basil Crow :
> >
> > After all these years, we finally migrated from Groovy initialization
> > scripts to JCasC on our Jenkins controllers.
> >
> > While any configuration error is a problem, I noticed that the way
> > these errors are reported differs from one mechanism to the next. With
> > Groovy initialization scripts, errors in one initialization script are
> > logged but this does not prevent subsequent initialization scripts
> > from running and startup from completing. In contrast, an error in a
> > JCasC configuation file causes subsequent changes not to be applied
> > and halts Jenkins startup.
> >
> > Do others view this lack of consistency as a problem? If so, would we
> > want to resolve the inconsistency by making JCasC more lenient or by
> > making Groovy initialization scripts more draconian? I could see
> > arguments both ways: making things more draconian is likely to break
> > things for someone out there, while making things more lenient is
> > likely to hide legitimate errors and decrease operability. I could
> > also see an argument for maintaining the status quo if people are
> > happy with it. If there is a consensus about this I could look into
> > implementing the change.
>
>
> From a user experience view I think that the error handling of JCasC
> currently should be changed (and improved). I’m not using Groovy scripts so
> I don’t care about consistency in that context. But I think that no
> application should totally break because of a misconfigured configuration
> value. This is a very bad user experience (actually I don’t know of any
> other application that does not start because of a configuration error). I
> often have this problem that my working JCasC configuration suddenly breaks
> after an upgrade of JCasC (or another plugin) and Jenkins just not starts
> up. And then you need to dig into log files to see what happens. It would
> be much better if those errors would be reported in the UI and the rest of
> the configuration will be applied (and the broken configuration will be
> initialized with default values). This is also the approach that we are
> using if a plugin changes serialization (or if a plugin cannot be started
> because of missing dependencies): in this case Jenkins still continues to
> work and the problems are highlighted in the UI. The broken components are
> just disabled or default values are used.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to jenkinsci-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CCA1297B-34F4-4D7E-93C1-65D70AA7B7A2%40gmail.com
> .
>


-- 
Antonio Muñiz
Human, 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/CAJc7kzTfr7QumVupqzzbZG23E0X_FWq5aqNozGKaHSu96jHOYw%40mail.gmail.com.

Re: Error handling in Groovy initialization scripts vs JCasC

[Ullrich Hafner]

> Am 24.06.2021 um 00:54 schrieb Basil Crow :
> 
> After all these years, we finally migrated from Groovy initialization
> scripts to JCasC on our Jenkins controllers.
> 
> While any configuration error is a problem, I noticed that the way
> these errors are reported differs from one mechanism to the next. With
> Groovy initialization scripts, errors in one initialization script are
> logged but this does not prevent subsequent initialization scripts
> from running and startup from completing. In contrast, an error in a
> JCasC configuation file causes subsequent changes not to be applied
> and halts Jenkins startup.
> 
> Do others view this lack of consistency as a problem? If so, would we
> want to resolve the inconsistency by making JCasC more lenient or by
> making Groovy initialization scripts more draconian? I could see
> arguments both ways: making things more draconian is likely to break
> things for someone out there, while making things more lenient is
> likely to hide legitimate errors and decrease operability. I could
> also see an argument for maintaining the status quo if people are
> happy with it. If there is a consensus about this I could look into
> implementing the change.


>From a user experience view I think that the error handling of JCasC currently 
>should be changed (and improved). I’m not using Groovy scripts so I don’t care 
>about consistency in that context. But I think that no application should 
>totally break because of a misconfigured configuration value. This is a very 
>bad user experience (actually I don’t know of any other application that does 
>not start because of a configuration error). I often have this problem that my 
>working JCasC configuration suddenly breaks after an upgrade of JCasC (or 
>another plugin) and Jenkins just not starts up. And then you need to dig into 
>log files to see what happens. It would be much better if those errors would 
>be reported in the UI and the rest of the configuration will be applied (and 
>the broken configuration will be initialized with default values). This is 
>also the approach that we are using if a plugin changes serialization (or if a 
>plugin cannot be started because of missing dependencies): in this case 
>Jenkins still continues to work and the problems are highlighted in the UI. 
>The broken components are just disabled or default values are used. 

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to jenkinsci-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CCA1297B-34F4-4D7E-93C1-65D70AA7B7A2%40gmail.com.

Editing a GitHub PR description triggers a new build in ci.jenkins.io

[Victor Martinez]

I've just reported https://issues.jenkins.io/browse/JENKINS-65978

I started to see recently that editing a GitHub PR title triggers a build 
in the CI even for the same commit that was built previously. I initially 
though it could be some misconfiguration in my company's CI, but then I've 
found the same behaviour in ci.jenkins.io.

Just wanted to give some heads up in case there is something to be done to 
mitigate the number of builds that could potentially get triggered only by 
changing their description, and therefore could somehow increase the cost 
of the infrastructure.

Please forgive me if this is not the right place to comment this kind of 
issues

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/968416a1-d866-402c-8ed6-2b58238121a9n%40googlegroups.com.

is the branch indexing needed for the plugins ci.jenkins.io?

[Victor Martinez]

Hi there,

I've seen the branch indexing enabled for the plugins in ci.jenkins.io, and 
I'm not sure if this is needed or something that should be skipped in terms 
of reducing the cost of the infrastructure.

I did a quick search in the jenkins-infra org but I could not find any 
references to the GHOrganization that could answer my question.

Thanks



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

ci.jenkins.io: update of EC2 and Azure VM agents

[Damien Duportal]

Hello dear ci.jenkins.io users,

This email is a notice that today, the agents on ci.jenkins.io that are 
virtual machines (ubuntu, ubuntu High-Mem and Windows 2019) will be 
upgraded as per https://issues.jenkins.io/browse/INFRA-2976.

The main changes to have in minde are the following (if you are using such 
agents):

   - OpenJDK 8 will be upgraded to 8u292-b10
   - OpenJDK 11 will be upgraded to 11.0.11+9
   - docker-compose is available in Windows Server
   - git-lfs is available in Ubuntu VMs
   - LXC, LXD and Snap have been remved in all Ubuntu


If there is any issue with this change, even after, please answer to this 
email and describe the issue so we can find a solution.

Please note that the agents labelled "maven-*" are using containers which 
are not part of this upgrade, but expect some changes in this area during 
the summer.

For the Jenkins Infra team,

Damien DUPORTAL

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