Next LTS baseline selection

[Oliver Gondža]

It is the time of the cycle again for us to choose next LTS baseline as
a successor to 2.190. Please, voice your preference or concerns here so
we can wrap up the discussion on governance meeting today (sorry for not
letting folks more time for the discussion).

My personal suggestion is 2.204, smallish with no radical changes while
reasonable recent.

https://jenkins.io/changelog/
--
oliver

[Jesse Glick]

2.204 sounds reasonable.

[Oleg Nenashev]

2.205 exploded due to https://issues.jenkins-ci.org/browse/JENKINS-60199, but IIUC it could be mitigated by upgrade guidelines.
It discourages selecting 2.205 s the new LTS baseline anyway, IMHO needs more soak testing for other possible regressions

+1 for 2.204. It has some negative community ratings, but I do not see particular issues in JIRA which would block it.

All changes are relatively minor, and 2.203 ratings were fine.

In 2.204 we would really want to have https://issues.jenkins-ci.org/browse/JENKINS-59679 from Zbynek so that we can proceed with plugin documentation migration.without impacting UX for LTS users.

Best regards,

Oleg

On Wednesday, November 20, 2019 at 3:05:23 PM UTC+1, Jesse Glick wrote:

2.204 sounds reasonable.

[Oleg Nenashev]

https://groups.google.com/forum/#!topic/jenkinsci-dev/O_g1kk39TBQ is quite related to this thread.

We might want to consider 2.198 as a baseline, just for discussion. 

[James Nord]

I will bite :)

I would be -1 on that version.

not having the fix in core is allowing silent corruption of configuration.  knowing allowing silent corruption and doing nothing about it has no place to exist in code.

It is not Jenkins that is blowing up but a plugin manipulating Jenkins state before it has been loaded causing race conditions and potential dataloss (infact I have observed data-loss which is why I wrote that defensive code to begin with)

there have not been that many (as far as I can tell) reports of this, so I would say you can work around that in a plugin that at least means you are not susceptible to dataloss (at the expense of Jenkins startup time).

[Oliver Gondža]

Do we have an idea of how often this manifests?

On 20/11/2019 19.00, Oleg Nenashev wrote:
> https://groups.google.com/forum/#!topic/jenkinsci-dev/O_g1kk39TBQ is
> quite related to this thread.
> We might want to consider 2.198 as a baseline, just for discussion.
>
> On Wednesday, November 20, 2019 at 3:49:31 PM UTC+1, Oleg Nenashev wrote:
>
> 2.205 exploded due to
> https://issues.jenkins-ci.org/browse/JENKINS-60199

> <https://issues.jenkins-ci.org/browse/JENKINS-60199>, but IIUC it

> could be mitigated by upgrade guidelines.
> It discourages selecting 2.205 s the new LTS baseline anyway, IMHO
> needs more soak testing for other possible regressions
>
> +1 for 2.204. It has some negative community ratings, but I do not
> see particular issues in JIRA which would block it.
> All changes are relatively minor, and 2.203 ratings were fine.
>
> In 2.204 we would really want to have
> https://issues.jenkins-ci.org/browse/JENKINS-59679
> <https://issues.jenkins-ci.org/browse/JENKINS-59679> from Zbynek so
> that we can proceed with plugin documentation migration.without
> impacting UX for LTS users.
>
> Best regards,
> Oleg
>
> On Wednesday, November 20, 2019 at 3:05:23 PM UTC+1, Jesse Glick wrote:
>
> 2.204 sounds reasonable.
>

> --
> 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
> <mailto:jenkinsci-de...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/a3026a36-8f17-4804-98d3-cc70c24a7d75%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/a3026a36-8f17-4804-98d3-cc70c24a7d75%40googlegroups.com?utm_medium=email&utm_source=footer>.


--
oliver

[Oliver Gondža]

While I agree with James' reasoning in theory, I see breaking JCasC as a
big deal. Even when we would be be able to compensate now in the plugin,
because that would leave several JCasC versions available that are known
to be broken on newer cores.

How about asserting JENKINS-58993 violation only during unit tests, so
we cause plugin maintainers to fix things before they hit people's
production (not in 100% of cases, I know)?

Also, I know I risk this was already discussed, but can we wrap the
whole milestone execution into Jenkins BulkChange so whatever saves will
be acted upon once the milestone is over?

On 20/11/2019 19.52, James Nord wrote:
> I will bite :)
>
> I would be -1 on that version.
> not having the fix in core is allowing silent corruption of
> configuration.  knowing allowing silent corruption and doing nothing
> about it has no place to exist in code.
>
> It is not Jenkins that is blowing up but a plugin manipulating Jenkins
> state before it has been loaded causing race conditions and potential
> dataloss (infact I have observed data-loss which is why I wrote that
> defensive code to begin with)
>
> there have not been that many (as far as I can tell) reports of this, so
> I would say you can work around that in a plugin that at least means you
> are not susceptible to dataloss (at the expense of Jenkins startup time).
>
>
>
> On Wednesday, November 20, 2019 at 6:00:43 PM UTC, Oleg Nenashev wrote:
>
> https://groups.google.com/forum/#!topic/jenkinsci-dev/O_g1kk39TBQ
> <https://groups.google.com/forum/#!topic/jenkinsci-dev/O_g1kk39TBQ> is
> quite related to this thread.
> We might want to consider 2.198 as a baseline, just for discussion.
>
> On Wednesday, November 20, 2019 at 3:49:31 PM UTC+1, Oleg Nenashev
> wrote:
>
> 2.205 exploded due to
> https://issues.jenkins-ci.org/browse/JENKINS-60199

> <https://issues.jenkins-ci.org/browse/JENKINS-60199>, but IIUC

> it could be mitigated by upgrade guidelines.
> It discourages selecting 2.205 s the new LTS baseline anyway,
> IMHO needs more soak testing for other possible regressions
>
> +1 for 2.204. It has some negative community ratings, but I do
> not see particular issues in JIRA which would block it.
> All changes are relatively minor, and 2.203 ratings were fine.
>
> In 2.204 we would really want to have
> https://issues.jenkins-ci.org/browse/JENKINS-59679
> <https://issues.jenkins-ci.org/browse/JENKINS-59679> from Zbynek
> so that we can proceed with plugin documentation
> migration.without impacting UX for LTS users.
>
> Best regards,
> Oleg
>
> On Wednesday, November 20, 2019 at 3:05:23 PM UTC+1, Jesse Glick
> wrote:
>
> 2.204 sounds reasonable.
>

> --
> 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
> <mailto:jenkinsci-de...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/jenkinsci-dev/a5f74add-9e84-4882-aad5-916b24064459%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/a5f74add-9e84-4882-aad5-916b24064459%40googlegroups.com?utm_medium=email&utm_source=footer>.


--
oliver

[James Nord]

I can not speak to Config As Code, but the issue I found that lead me to write the code in Jenkins in the first place was reported reliably by one of CloudBees' customers (they could hit it every single time).
I also saw this on my internal issue sometimes (we randomly lost the cloud configuration and some views) but it was random and we often didn't notice for a bit.

in order to reproduce it I had to write https://github.com/jenkinsci/make-jenkins-slow-plugin .

basically it is a combination of what is in config.xml of Jenkins (the more the merrier because it slows down deserialisation etc), number of cores (more cores more parallel init reactor tasks IIRC), speed of disk and which way the wind is blowing.

> an email to jenkin...@googlegroups.com
> <mailto:jenkinsci-dev+unsub...@googlegroups.com>.

[Jesse Glick]

On Wed, Nov 20, 2019 at 2:33 PM Oliver Gondža <ogo...@gmail.com> wrote:
> Even when we would be be able to compensate now in the plugin,
> because that would leave several JCasC versions available that are known
> to be broken on newer cores.

So just mention in the upgrade guide that you need to update the
`configuration-as-code` plugin (preferably before the core upgrade)?

> asserting JENKINS-58993 violation only during unit tests

I.e., using Java assertions, which should be enabled during tests and
not (normally) enabled in production. Fine from my PoV if you want to
do that in the `stable-2.204` branch so long as it remains a hard fail
in `master`.

This should serve as a reminder that the Jenkins weekly release
process should run PCT against an ever-growing selection of plugins,
and failures should be considered release blockers, or we could even
do this daily (making it part of the PR builder would likely be too
expensive). Requires someone to commit to setting up and maintaining
that infrastructure. The `jenkinsci/bom` Dependabot builds catch some
plugin regressions but this is not set up well for catching core
regressions.

[ogondza]

I like that idea, Jesse. Can we agree on picking 2.204 with JENKINS-58993 patched to only fail when assertions are on?

--

oliver

[Tim Jacomb]

2.205 has the password field redesign in it which would be good to get in, I’ve been bitten by that before.

There’s a PR to the JCasC plugin with the suggested work around which might fix the issue (awaiting feedback before merging)

Thanks

Tim

--

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/95885a12-770a-41cb-ae4a-9279fe904e73%40googlegroups.com.

[James Nord]

I will state this again - no level of dataloss is acceptable - we should not back this change out or make it disabled by default.  

There is a drive by untested PR to Configuration As Code plugin if someone wants to look at it.

https://github.com/jenkinsci/configuration-as-code-plugin/pull/1204

/James

[Daniel Beck]

On Thu, Nov 21, 2019 at 10:27 AM Tim Jacomb <timja...@gmail.com> wrote:

2.205 has the password field redesign in it which would be good to get in, I’ve been bitten by that before.

I see it as valuable (obviously, as the author), but think it could benefit from some more time in weeklies to get user feedback before rolling it out to everyone. Perhaps if it had been around for longer than a few days, but that's not how the schedule worked out.

FWIW I'm +1 on 2.204. No strong opinion on the JCasC issue, although I question how big of a deal it would be to fix it in the plugin and just document it in the upgrade guide. Not a user of that plugin, but it seems like the reliance on internals would break things regularly (e.g. recently last with the useBrowser flag) and JCasC users would need to read changelogs, upgrade guides, etc. anyway.

[Baptiste Mathus]

Not answering on the revert or change of James' fix itself, but FWIW we at CloudBees plan to start deeper testing on the newer baseline, especially >= 2.199 very soon, hopefully in the next few days. 

Hopefully this will provide an additional data point as to the size of the potential impact of this Core change.

--

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/3588ff14-54bc-4d6e-99c8-1144bc502683%40googlegroups.com.

[Oliver Gondža]

I get what you say, James. My point being we ware shipping a core with
this flaw for years (correct me if I wrong), there ware no documentation
plugins should not save before EXTENSIONS_AUGMENTED is completed and
people ware not bitten severely enough to file an issue until recently
(again, correct me if I a wrong). So from this standpoint, I see the
claim that "no level of dataloss is acceptable" (while breaking JCasC
users) a bit, for the lack of better word, fundamentalistic. All I am
after here is to find the reasonable balance between the added safety of
your fix and the impact on the JCasC customers.

So for now, it seems to me the most of the folks lean towards shipping
the fix the way it is and documenting eventual consequences.

Are we ok to see how the JCasC PR is doing before committing to an LTS
baseline?

On 21/11/2019 11.38, James Nord wrote:
> I will state this again -*no level of dataloss is acceptable* - we

> should not back this change out or make it disabled by default.
>
> There is a drive by untested PR to Configuration As Code plugin if
> someone wants to look at it.
>
> https://github.com/jenkinsci/configuration-as-code-plugin/pull/1204
>
> /James
>
> On Thursday, November 21, 2019 at 7:51:39 AM UTC, ogondza wrote:
>
> I like that idea, Jesse. Can we agree on picking 2.204 with
> JENKINS-58993 patched to only fail when assertions are on?
>
> --
> oliver
>

> --
> 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
> <mailto:jenkinsci-de...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/jenkinsci-dev/3588ff14-54bc-4d6e-99c8-1144bc502683%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/3588ff14-54bc-4d6e-99c8-1144bc502683%40googlegroups.com?utm_medium=email&utm_source=footer>.


--
oliver

[Daniel Beck]

On Thu, Nov 21, 2019 at 12:40 PM Oliver Gondža <ogo...@gmail.com> wrote:

Are we ok to see how the JCasC PR is doing before committing to an LTS
baseline?

Are you suggesting we go with 2.198 if the JCasC PR doesn't work out? Or does 'baseline' include a distinction between '2.204' and '2.204 with LTS only revert of 58993'?

[Oliver Gondža]

Good point. I do not suggest to go with 2.198 so this really is about
2.204 with or without JENKINS-58993 enforcement.

Are there any objections to choosing 2.204 as the next baseline and iron
out what to do about JENKINS-58993 in next two weeks?
--
oliver

[夏润泽]

I don't know much about the jenkins master.

I only commented on the JCasC issue.

I have the same idea as James, no level of dataloss is acceptable.

So I will choose 2.199+ as the base line for the next lts.

[Oleg Nenashev]

I do not suggest to go with 2.198 so this really is about 2.204 with or without JENKINS-58993 enforcement.  

2.204 is fine with me since we keep our options open for this issue while we evaluate workarounds 

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/2hPMwmZDZFg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/e3f32aba-061b-4218-aed4-702c834737ad%40googlegroups.com.

[James Nord]

 

My point being we ware shipping a core with
this flaw for years (correct me if I wrong)

Correct 

there ware no documentation
plugins should not save before EXTENSIONS_AUGMENTED is completed and
people ware not bitten severely enough to file an issue until recently
(again, correct me if I a wrong).

I think people have been bitten by this for a long time it was just not obvious and there are only a few plugins that manipulate state like this.

The setup I use at work has been bitten by this for about a year - partly because one of our plugins was badly behaving, we have had some reports going back that some configuration was lost but was a one off for the customer so no extra deep diving occurred at the time.

There are issues reported in Config-As-Code before core prevented the dataloss exactly about dataloss, so I think people have been seeing this in CasC but there was never a correlation (and as Casc adoption is growing explains why we see this a little more).
https://github.com/jenkinsci/configuration-as-code-plugin/issues/280 (reported > 1 year ago but theoretical )
https://github.com/jenkinsci/configuration-as-code-plugin/issues/1171
https://github.com/jenkinsci/configuration-as-code-plugin/issues/1026

Are we ok to see how the JCasC PR is doing before committing to an LTS
baseline? 

From my point of view certainly.

[Daniel Beck]

On Thu, Nov 21, 2019 at 2:17 PM Oliver Gondža <ogo...@gmail.com> wrote:

Are there any objections to choosing 2.204 as the next baseline and iron
out what to do about JENKINS-58993 in next two weeks?

I agree this is the most pragmatic approach.

[Mark Waite]

That is my preference as well. 

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKh0z7hqv5LFF03HQkkj%3DTV57%2BAJviDZ%2B0QrmZC1RtgUA%40mail.gmail.com.

--

Thanks!

Mark Waite

[Oliver Gondža]

Alright, thanks for the inputs. Next LTS line will be 2.204.

On 21/11/2019 19.44, Mark Waite wrote:
>
>
> On Thu, Nov 21, 2019 at 7:54 AM Daniel Beck <db...@cloudbees.com
> <mailto:db...@cloudbees.com>> wrote:
>
>
>
> On Thu, Nov 21, 2019 at 2:17 PM Oliver Gondža <ogo...@gmail.com
> <mailto:ogo...@gmail.com>> wrote:
>
>
> Are there any objections to choosing 2.204 as the next baseline
> and iron
> out what to do about JENKINS-58993 in next two weeks?
>
>
> I agree this is the most pragmatic approach.
>
>
> That is my preference as well.
>
> --
> You received this message because you are subscribed to the Google
> Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to jenkinsci-de...@googlegroups.com

> <mailto:jenkinsci-de...@googlegroups.com>.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKh0z7hqv5LFF03HQkkj%3DTV57%2BAJviDZ%2B0QrmZC1RtgUA%40mail.gmail.com

> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKh0z7hqv5LFF03HQkkj%3DTV57%2BAJviDZ%2B0QrmZC1RtgUA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
>
>
> --
> Thanks!
> 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-de...@googlegroups.com

> <mailto:jenkinsci-de...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH5_oSB2s48VjViRYbXUcXfqigWyWD0idynfhbfXy%2Bfew%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH5_oSB2s48VjViRYbXUcXfqigWyWD0idynfhbfXy%2Bfew%40mail.gmail.com?utm_medium=email&utm_source=footer>.


--
oliver

[James Nord]

just following up the workaound for Config as Code plugin was tested by 夏润泽 and shown to work. it has also been merged.

http://github.com/jenkinsci/configuration-as-code-plugin/pull/1204

On Thursday, November 21, 2019 at 6:54:20 PM UTC, ogondza wrote:

Alright, thanks for the inputs. Next LTS line will be 2.204.

On 21/11/2019 19.44, Mark Waite wrote:
>
>
> On Thu, Nov 21, 2019 at 7:54 AM Daniel Beck <db...@cloudbees.com
> <mailto:db...@cloudbees.com>> wrote:
>
>
>
>     On Thu, Nov 21, 2019 at 2:17 PM Oliver Gondža <ogo...@gmail.com
>     <mailto:ogo...@gmail.com>> wrote:
>
>
>         Are there any objections to choosing 2.204 as the next baseline
>         and iron
>         out what to do about JENKINS-58993 in next two weeks?
>
>
>     I agree this is the most pragmatic approach.
>
>
> That is my preference as well.
>
>     --
>     You received this message because you are subscribed to the Google
>     Groups "Jenkins Developers" group.
>     To unsubscribe from this group and stop receiving emails from it,

>     send an email to jenkin...@googlegroups.com
>     <mailto:jenkinsci-dev+unsub...@googlegroups.com>.

>     To view this discussion on the web visit
>     https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKh0z7hqv5LFF03HQkkj%3DTV57%2BAJviDZ%2B0QrmZC1RtgUA%40mail.gmail.com
>     <https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKh0z7hqv5LFF03HQkkj%3DTV57%2BAJviDZ%2B0QrmZC1RtgUA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
>
>
>
> --
> Thanks!
> 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 jenkin...@googlegroups.com
> <mailto:jenkinsci-dev+unsub...@googlegroups.com>.

[Oliver Gondža]

I am glad to hear that. I have started backporting things today but I am
leaving this thing untouched and waiting for feedback. And that is
positive for now.

On 26/11/2019 12.47, James Nord wrote:
> just following up the workaound for Config as Code plugin was tested by

> 夏润泽and shown to work. it has also been merged.

>
> http://github.com/jenkinsci/configuration-as-code-plugin/pull/1204
>
> On Thursday, November 21, 2019 at 6:54:20 PM UTC, ogondza wrote:
>
> Alright, thanks for the inputs. Next LTS line will be 2.204.
>
> On 21/11/2019 19.44, Mark Waite wrote:
> >
> >
> > On Thu, Nov 21, 2019 at 7:54 AM Daniel Beck <db...@cloudbees.com

> <javascript:>

> > <mailto:db...@cloudbees.com <javascript:>>> wrote:
> >
> >
> >
> >     On Thu, Nov 21, 2019 at 2:17 PM Oliver Gondža

> <ogo...@gmail.com <javascript:>

> >     <mailto:ogo...@gmail.com <javascript:>>> wrote:
> >
> >
> >         Are there any objections to choosing 2.204 as the next
> baseline
> >         and iron
> >         out what to do about JENKINS-58993 in next two weeks?
> >
> >
> >     I agree this is the most pragmatic approach.
> >
> >
> > That is my preference as well.
> >
> >     --
> >     You received this message because you are subscribed to the
> Google
> >     Groups "Jenkins Developers" group.
> >     To unsubscribe from this group and stop receiving emails from
> it,

> >     send an email to jenkin...@googlegroups.com <javascript:>
> >     <mailto:jenkinsci-de...@googlegroups.com
> <javascript:>>.

> >     To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKh0z7hqv5LFF03HQkkj%3DTV57%2BAJviDZ%2B0QrmZC1RtgUA%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKh0z7hqv5LFF03HQkkj%3DTV57%2BAJviDZ%2B0QrmZC1RtgUA%40mail.gmail.com>
>
> >

> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKh0z7hqv5LFF03HQkkj%3DTV57%2BAJviDZ%2B0QrmZC1RtgUA%40mail.gmail.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/jenkinsci-dev/CAMo7PtKh0z7hqv5LFF03HQkkj%3DTV57%2BAJviDZ%2B0QrmZC1RtgUA%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>
> >
> >
> >
> > --
> > Thanks!
> > 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 jenkin...@googlegroups.com <javascript:>
> > <mailto:jenkinsci-de...@googlegroups.com <javascript:>>.

> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH5_oSB2s48VjViRYbXUcXfqigWyWD0idynfhbfXy%2Bfew%40mail.gmail.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH5_oSB2s48VjViRYbXUcXfqigWyWD0idynfhbfXy%2Bfew%40mail.gmail.com>
>
> >

> <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH5_oSB2s48VjViRYbXUcXfqigWyWD0idynfhbfXy%2Bfew%40mail.gmail.com?utm_medium=email&utm_source=footer

> <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtH5_oSB2s48VjViRYbXUcXfqigWyWD0idynfhbfXy%2Bfew%40mail.gmail.com?utm_medium=email&utm_source=footer>>.
>
>
>
> --
> oliver
>

> --
> 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
> <mailto:jenkinsci-de...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/jenkinsci-dev/e7a0ee81-e2c4-411b-97bd-c01256a8ef10%40googlegroups.com
> <https://groups.google.com/d/msgid/jenkinsci-dev/e7a0ee81-e2c4-411b-97bd-c01256a8ef10%40googlegroups.com?utm_medium=email&utm_source=footer>.


--
oliver

[Mark Waite]

Configuration as code 1.34 has released and includes the workaround.  See  https://github.com/jenkinsci/configuration-as-code-plugin/releases/tag/configuration-as-code-1.34

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/70f9835b-4970-6bdf-6bca-99a5474db8d2%40gmail.com.

--

Thanks!

Mark Waite