Error handling in Groovy initialization scripts vs JCasC

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

Re: Sign-up for 'beta projects' in GitHub issues

Thanks! Yes, I would like to try it on https://github.com/jenkins-infra/jenkins.io . On Wed, Jun 23, 2021 at 2:26 PM 'Olblak' via Jenkins Developers < jenkinsci-dev@googlegroups.com> wrote: > I added jenkins-infra to the waiting list > > On Wed, Jun 23, 2021, at 10:03 PM, Tim Jacomb wrote: > >

Re: Question regarding the one shot workers to be gracefully terminated

Thanks Jesse, I'll prepare the context with that PR and reproduce the warning On Tuesday, 22 June 2021 at 18:13:46 UTC+1 Jesse Glick wrote: > On Tue, Jun 22, 2021 at 12:28 PM Victor Martinez > wrote: > >> *INFO hudson.remoting.Request$2#run: Failed to send back a reply to the >> request

Re: Sign-up for 'beta projects' in GitHub issues

I added jenkins-infra to the waiting list On Wed, Jun 23, 2021, at 10:03 PM, Tim Jacomb wrote: > Mark mentioned on Twitter he’s like to try it on Jenkins.io too > https://twitter.com/markewaite/status/1407780053769850882?s=21 > > On Wed, 23 Jun 2021 at 20:04, Tim Jacomb wrote: >> Hello, >>

Re: Sign-up for 'beta projects' in GitHub issues

Mark mentioned on Twitter he’s like to try it on Jenkins.io too https://twitter.com/markewaite/status/1407780053769850882?s=21 On Wed, 23 Jun 2021 at 20:04, Tim Jacomb wrote: > Hello, > > Should we sign-up for the new beta projects in jenkinsci? > > https://github.com/features/issues > > Would

Sign-up for 'beta projects' in GitHub issues

Hello, Should we sign-up for the new beta projects in jenkinsci? https://github.com/features/issues Would be useful to be able to set-up more featureful boards across plugins, probably other use-cases too. Thanks Tim -- You received this message because you are subscribed to the Google

Multiple Plugin Update Sites

I would like to suggest - not sure if this was already considered and dismissed - a change in how plugins are managed. The use case begins with a company that either gets their plugins from one or more third parties or builds their own plugins (considered for this use case a third party).

Re: programmatic links to most recent LTS RC war

Hello No not currently RC side is all manual currently and doesn’t go through the same automation that releases do On Wed, 23 Jun 2021 at 16:57, Niv Keidan wrote: > Is there a link that always redirects to the most recent LTS RC ? > > I'm seeing the last RCs being made available from >

programmatic links to most recent LTS RC war

Is there a link that always redirects to the most recent LTS RC ? I'm seeing the last RCs being made available from https://repo.jenkins-ci.org/snapshots/org/jenkins-ci/main/jenkins-war/ and I know in the past we used http://mirrors.jenkins-ci.org/war-stable-rc/latest/ We use this to automate

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

Hello all :) As a developer at CloudBees I am part of a team that is trying to participate in the terminology change effort and we had the same concern about the limits of changes (UI, logs, console, local variable, package name ??). So I can share our way of working so far => What we do

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

+1 to what Gavin said. I cannot comment on a particular EPIC, but renaming classes is generally in the scope for the terminology cleanup initiative: https://community.jenkins.io/t/jenkins-terminology-cleanup-initiative-coordination/180#full-scope-5 "Being in scope" does not mean it will happen