Re: [jenkins/blueocean] the url to access stage log is inconsistent

['Henry Xu' via Jenkins Developers]

What I am looking for is a method to get log of stages by their stage id 
(which I have already find a way to get in the scripted pipeline) and 
blueocean seem to be the best choice since it already have the API 
endpoint, but unfortunately the API design is kind of broken.  And yes, if 
there are plugins that allow to provide the same feature will also work to 
me. 

On Friday, September 3, 2021 at 3:39:45 AM UTC+8 ga...@gavinmogan.com wrote:

> I remember that node parser was one of the most tweaked code in all of 
> blue ocean. If I remember correctly it's due to how scripted stages are 
> processed and when they are available. Blue ocean tends to work better with 
> declarative.
>
> That said blue ocean is in maintaince mode. Afaik the only fixes are for 
> cloudbees customers or maybe PRs.
>
> I'm going to recommend 
> https://community.jenkins.io/t/blue-ocean-but-in-classic-ui/96 but this 
> is moving away from a dev topic.
>
> On Thu., Sep. 2, 2021, 2:04 a.m. 'Henry Xu' via Jenkins Developers, <
> jenkin...@googlegroups.com> wrote:
>
>> [image: 
>> Cursor_and_jenkins___Jupiter-Neo-Pipeline_Jupiter-JPT-Pipeline-Dev___Jupiter-JPT-Pipeline-Dev35.png]
>> A image to make it easier to understand the problem.
>>
>> On Thursday, September 2, 2021 at 5:00:23 PM UTC+8 Henry Xu wrote:
>>
>>> Stage log is  one of my favorite features of Blue Ocean. But the 
>>> inconsistent link to the stage log make me feel annoyed.
>>> As a Jenkins share library maintainer, I want to get the url of stage 
>>> log and put them in the report to make it easier for users to debug the 
>>> issue.
>>> I can get the correct stage ID in scripted pipeline, the problem is, if 
>>> the stage is not in parallel block, it works well to access the log via 
>>> stage ID. But if the stage is in parallel block then its log cannot be 
>>> accessed by stage ID, but I have to find its parent parallel node's ID to 
>>> access the log. It will throw the following error if you try to access it 
>>> via the stage id:
>>>
>>> { "message" : "Stage 157 not found in pipeline my-pipeline", "code" : 
>>> 404, "errors" : [ ] }
>>>
>>> I did some research myself and find it may have something to do with how 
>>> blueocean render flow graph. 
>>> (blueocean-pipeline-api-impl/src/main/java/io/jenkins/blueocean/rest/impl/pipeline/PipelineNodeGraphVisitor.java)
>>> I think a better way for doing this is to provide a general purpose rest 
>>> API endpoint to allow users to access the stage log via stage id, which 
>>> will make it more easier for the end user to use this awesome feature.
>>>
>>> -- 
>> 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/20b8a7a8-e59e-458e-980a-3d6f35dfc606n%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/37f9d258-63dc-4b46-8468-cbe281c1f802n%40googlegroups.com.

Re: LTS backporting policy

[Baptiste Mathus]

Right, re-reading this part well (thanks Tim), I think this should be
enough indeed?
Not fully sure about the term "fix" being too precise, or vague :), but
probably that's nitpicking.

WDYT James, do you feel making a more precise note around "dependency
update with known CVE" or so would still be important for some reason?

Thanks

Le jeu. 2 sept. 2021 à 12:18, Tim Jacomb  a écrit :

> This is already covered as far as I can tell:
>
> https://www.jenkins.io/download/lts/#backporting-process
> > Aside from the model set out above, backporters apply some subjective
> selection — for example whether a fix is easy and safe to backport,
> confidence in the fix, importance/impact of the problem, how much time is
> left until the end of backporting window and so on.
>
> We have already been back-porting some dependency updates (e.g. xstream),
> as security scanners pick them up even though we know we aren't vulnerable.
>
> Do you think that's enough? Or some more specific wording on that page?
>
> Thanks
> Tim
>
>
>
> On Wed, 1 Sept 2021 at 15:48, jn...@cloudbees.com 
> wrote:
>
>> Sure,
>>
>> I was just asking it to be added to the list of eligible criteria.  As
>> with any bug that is also eligible there is a decision to be made as to if
>> we are to cherry-pick the change or not.
>>
>> (on a randomly different note - if we where actually vulnerable - we
>> would not have this luxury!)
>>
>> /James
>>
>>
>>
>> On Wednesday, September 1, 2021 at 3:36:05 PM UTC+1 Oleg Nenashev wrote:
>>
>>> I am +0.5, but being eligible does not immediately mean the change would
>>> be backported. Dependency updates may also introduce regressions. As any
>>> other backport, risks need to be evaluated. IMHO it should be up for
>>> backporting requesters to prove the safety of changes and to ensure there
>>> is enough soak testing and test coverage. Same for any other non-critical
>>> backport
>>>
>>> On Tuesday, August 31, 2021 at 8:16:08 PM UTC+2 boa...@gmail.com wrote:
>>>
 Are there specific libraries we can list for safe upgrades? Like
 XStream, Jackson, Commons, etc, for common upgrades. I wouldn’t be super
 comfortable with a blanket policy, but for all our more stable ones, I
 think it’s a good idea.

 Matt Sicker

 On Aug 31, 2021, at 09:01, wfoll...@cloudbees.com <
 wfoll...@cloudbees.com> wrote:

 Totally agree. Especially when the update is not a major bump of 3
 versions. Most of the time it's just a minor/bug version bump.

 That will greatly help on the security scanners area, where the "fear"
 dominates the market :-)

 Thanks James for the suggestion, great idea.

 Wadeck

 On Tuesday, August 31, 2021 at 3:58:38 PM UTC+2 jn...@cloudbees.com
 wrote:

> Hi all,
>
> I would like to propose that we add to the list of eligible criteria
> for backporting the following
>
> * is a dependency update with a known security issue
>
> The reason for this if we have a dependency with a security issue that
> is exploitable from Jenkins we already do include that as a LTS issue via
> the current SECURITY process, however if the issue is *not*
> exploitable then we do not. (for example the recent XStream issues have 
> not
> impacts Jenkins as we already use an allow list).
>
> However as supply chain issues are becoming more prominent to our
> users, they are scanning software with automated tools that look at the
> dependencies, and these scanners do not understand how a library is used
> or  configured, and has the potential to:
>
> * make the software look insecure (thus be a barrier to adoption)
> or
> * cause extra nose asking about CVE-2021-123456
>
> WDYT?
>
> /James
>
 --
 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/6d65b90e-1e31-475c-b3f6-9920bb4ee33en%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/bad90cc0-1307-4184-9d3f-2a6a27345ddan%40googlegroups.com
>> 
>> .
>>
> --
> You received this message because you are subscribed to the 

Re: Docker LTS image: issue with locale, should we rebuild?

[Matt Sicker]

Just like the Helm chart version doesn’t match exactly with the Jenkins 
version. A rebuilt image should use a new version, but it would help to use a 
naming scheme that doesn’t conflict with real Jenkins release versions.

Matt Sicker

> On Sep 2, 2021, at 08:59, Raul Arabaolaza  wrote:
> 
> I do fully agree with James here, if there is a bug on a concrete image 
> rebuild it, put some classifier on the version so people can understand what 
> is happening and no tags are modified. I do not see the need to rebuild 
> everything but the docker images to generate a new release that is gonna be 
> exactly the same than the previous one but with a different version number  
> 
>> On Monday, August 30, 2021 at 10:34:35 AM UTC+2 damien@gmail.com wrote:
>> 
>> Hello dear developers and maintainers,
>> 
>> We (the Jenkins Infra team) were recently bitten by a change in the latest 
>> Docker image for Jenkins controller, in its LTS 2.303.1 (released last week).
>> 
>> The issue is related to a change of locale from "C.UTF-8" to "POSIX" when 
>> using Debian image (as an upstream change from Debian bullseye).
>> 
>> A fix has already been made by a user in 
>> https://github.com/jenkinsci/docker/pull/1194 and is already merge in GitHub.
>> 
>> We (the Jenkins Infra team) would like to rebuild the Docker image for the 
>> LTS 2.303.1 to avoid our users to be annoyed by this issue.
>> - It should not imply any tagging version change (as the Docker image tags 
>> are only about the Core version of Jenkins used, not about the other 
>> dependencies on the image)
>> - It should only impact the Debian images (amd64 and arm64)
>> - It should not impact the weekly (next weekly will have the fix of course)
>> - It should make the image being advertised as updated a few days after the 
>> official LTS release
>> 
>> - Is there any issue or counter voice to this change?
>> - Is there any question or element unclear?
>> 
>> 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/c43a5a95-4666-4601-9944-28614abcbe32n%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/54D5C969-1320-4C4B-BBA6-4A768601729D%40gmail.com.

Re: Docker LTS image: issue with locale, should we rebuild?

[Raul Arabaolaza]

I do fully agree with James here, if there is a bug on a concrete image 
rebuild it, put some classifier on the version so people can understand 
what is happening and no tags are modified. I do not see the need to 
rebuild everything but the docker images to generate a new release that is 
gonna be exactly the same than the previous one but with a different 
version number  

On Monday, August 30, 2021 at 10:34:35 AM UTC+2 damien@gmail.com wrote:

>
> Hello dear developers and maintainers,
>
> We (the Jenkins Infra team) were recently bitten by a change in the latest 
> Docker image for Jenkins controller, in its LTS 2.303.1 (released last 
> week).
>
> The issue is related to a change of locale from "C.UTF-8" to "POSIX" when 
> using Debian image (as an upstream change from Debian bullseye).
>
> A fix has already been made by a user in 
> https://github.com/jenkinsci/docker/pull/1194 and is already merge in 
> GitHub.
>
> We (the Jenkins Infra team) would like to rebuild the Docker image for the 
> LTS 2.303.1 to avoid our users to be annoyed by this issue.
> - It should not imply any tagging version change (as the Docker image tags 
> are only about the Core version of Jenkins used, not about the other 
> dependencies on the image)
> - It should only impact the Debian images (amd64 and arm64)
> - It should not impact the weekly (next weekly will have the fix of course)
> - It should make the image being advertised as updated a few days after 
> the official LTS release
>
> - Is there any issue or counter voice to this change?
> - Is there any question or element unclear?
>
> 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/c43a5a95-4666-4601-9944-28614abcbe32n%40googlegroups.com.

Re: Docker LTS image: issue with locale, should we rebuild?

[jn...@cloudbees.com]

> see no reason in separating their versioning from the Jenkins LTS 
releases.

what would the rationale be as to why this does this necessitate a bump in 
the LTS?  (

the docker images are (where) published with several tags
`lts` `lts-jdk8`   ok so maybe the `2.203.1` tag you don't want to 
republish - but that only affects people using an explicit tag that *currently 
expect *it to be immutable.
I would suggest that a `2.303.1_2` would be published or something like 
that along with the generic lts tags if we do not want to replace the 
`2.303.1` tag.

However going forward we need to make sure people do not think actual tags 
are immutable" (the only tag that should be immutable is one with an 
explicit (for the docker build) build number, anything else can be updated 
and would be just the same as the last `{lts_version}_{latest_build_number)`

I would hate to ask if a seriously exploitable JRE issue came to light, so 
this does seem like an issue if we are tying LTS jenkins version to an 
actual package version, thus this is something that should be happening 
anyway.

If we publish a .2 just for a packaging issue then this will trigger 
upgrade warnings for all users on Jenkins who have just upgraded, and they 
will have absolutely zero changes, or we do have changes and then we have 
LTS with changes out of schedule - and that can impact people that are 
planning based on a predictable release cycle.  (the same really should 
hold for all packages)

/James
On Thursday, September 2, 2021 at 11:24:20 AM UTC+1 timja...@gmail.com 
wrote:

> Hello
>
> Is the suggestion to do a normal LTS release with backporting or just bump 
> the version with the same code and new docker build?
> (Any volunteers to run the release? The next scheduled release is on 22nd 
> September)
>
>
> On Mon, 30 Aug 2021 at 17:15, Damien Duportal  
> wrote:
>
>> Thanks fro your answers.
>>
>> If I understand correctly, we would have to bump the Jenkins Core LTS 
>> version is that correct?
>>
>> In that case, I defer to the usual release officer for driving this (that 
>> means not before Wednesday as Tuesday is weekly release day).
>>
>>
>> Damien
>>
>> Le lundi 30 août 2021 à 15:33:00 UTC+2, jonbr...@gmail.com a écrit :
>>
>>> +1 for Olegs recommendation of bumping the build number. Versioned 
>>> artifacts should be immutable.
>>>
>>> On Monday, August 30, 2021 at 2:39:10 PM UTC+2 Oleg Nenashev wrote:
>>>
 I would rather recommend 2.303.2. Docker images are so popular at the 
 moment, I see no reason in separating their versioning from the Jenkins 
 LTS 
 releases.
 On Monday, August 30, 2021 at 2:26:38 PM UTC+2 ma...@torstenwalter.de 
 wrote:

> Would be great if you could announce once it's done. So that people 
> who build images based on it have the chance of triggering a re-build.
> People who use it in Kubernetes might have a problem with the updated 
> images in case they use image pull policy IfNotPresent.
>
>
> Am Mo., 30. Aug. 2021 um 14:09 Uhr schrieb Mark Waite <
> mark.ea...@gmail.com>:
>
>> No issue or objection from me to have the 2.303.1 Debian images 
>> updated.
>>
>> On Mon, Aug 30, 2021 at 2:34 AM Damien Duportal  
>> wrote:
>>
>>>
>>> Hello dear developers and maintainers,
>>>
>>> We (the Jenkins Infra team) were recently bitten by a change in the 
>>> latest Docker image for Jenkins controller, in its LTS 2.303.1 
>>> (released 
>>> last week).
>>>
>>> The issue is related to a change of locale from "C.UTF-8" to "POSIX" 
>>> when using Debian image (as an upstream change from Debian bullseye).
>>>
>>> A fix has already been made by a user in 
>>> https://github.com/jenkinsci/docker/pull/1194 and is already merge 
>>> in GitHub.
>>>
>>> We (the Jenkins Infra team) would like to rebuild the Docker image 
>>> for the LTS 2.303.1 to avoid our users to be annoyed by this issue.
>>> - It should not imply any tagging version change (as the Docker 
>>> image tags are only about the Core version of Jenkins used, not about 
>>> the 
>>> other dependencies on the image)
>>> - It should only impact the Debian images (amd64 and arm64)
>>> - It should not impact the weekly (next weekly will have the fix of 
>>> course)
>>> - It should make the image being advertised as updated a few days 
>>> after the official LTS release
>>>
>>> - Is there any issue or counter voice to this change?
>>> - Is there any question or element unclear?
>>>
>>> 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-de...@googlegroups.com.
>>> To view this discussion on the 

Re: Docker LTS image: issue with locale, should we rebuild?

[Tim Jacomb]

Hello

Is the suggestion to do a normal LTS release with backporting or just bump
the version with the same code and new docker build?
(Any volunteers to run the release? The next scheduled release is on 22nd
September)


On Mon, 30 Aug 2021 at 17:15, Damien Duportal 
wrote:

> Thanks fro your answers.
>
> If I understand correctly, we would have to bump the Jenkins Core LTS
> version is that correct?
>
> In that case, I defer to the usual release officer for driving this (that
> means not before Wednesday as Tuesday is weekly release day).
>
>
> Damien
>
> Le lundi 30 août 2021 à 15:33:00 UTC+2, jonbr...@gmail.com a écrit :
>
>> +1 for Olegs recommendation of bumping the build number. Versioned
>> artifacts should be immutable.
>>
>> On Monday, August 30, 2021 at 2:39:10 PM UTC+2 Oleg Nenashev wrote:
>>
>>> I would rather recommend 2.303.2. Docker images are so popular at the
>>> moment, I see no reason in separating their versioning from the Jenkins LTS
>>> releases.
>>> On Monday, August 30, 2021 at 2:26:38 PM UTC+2 ma...@torstenwalter.de
>>> wrote:
>>>
 Would be great if you could announce once it's done. So that people who
 build images based on it have the chance of triggering a re-build.
 People who use it in Kubernetes might have a problem with the updated
 images in case they use image pull policy IfNotPresent.


 Am Mo., 30. Aug. 2021 um 14:09 Uhr schrieb Mark Waite <
 mark.ea...@gmail.com>:

> No issue or objection from me to have the 2.303.1 Debian images
> updated.
>
> On Mon, Aug 30, 2021 at 2:34 AM Damien Duportal 
> wrote:
>
>>
>> Hello dear developers and maintainers,
>>
>> We (the Jenkins Infra team) were recently bitten by a change in the
>> latest Docker image for Jenkins controller, in its LTS 2.303.1 (released
>> last week).
>>
>> The issue is related to a change of locale from "C.UTF-8" to "POSIX"
>> when using Debian image (as an upstream change from Debian bullseye).
>>
>> A fix has already been made by a user in
>> https://github.com/jenkinsci/docker/pull/1194 and is already merge
>> in GitHub.
>>
>> We (the Jenkins Infra team) would like to rebuild the Docker image
>> for the LTS 2.303.1 to avoid our users to be annoyed by this issue.
>> - It should not imply any tagging version change (as the Docker image
>> tags are only about the Core version of Jenkins used, not about the other
>> dependencies on the image)
>> - It should only impact the Debian images (amd64 and arm64)
>> - It should not impact the weekly (next weekly will have the fix of
>> course)
>> - It should make the image being advertised as updated a few days
>> after the official LTS release
>>
>> - Is there any issue or counter voice to this change?
>> - Is there any question or element unclear?
>>
>> 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-de...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/jenkinsci-dev/0e3ad65e-9bd7-4074-9fc6-e35328f837dcn%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-de...@googlegroups.com.
>
 To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtFUzjbbxT5jbcFxGW3D52ViNJ3LOwNzeNKFhQOGbEEQnQ%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/7c27bda5-ee41-4570-b616-abea45fc7832n%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 

Re: LTS backporting policy

[Tim Jacomb]

This is already covered as far as I can tell:

https://www.jenkins.io/download/lts/#backporting-process
> Aside from the model set out above, backporters apply some subjective
selection — for example whether a fix is easy and safe to backport,
confidence in the fix, importance/impact of the problem, how much time is
left until the end of backporting window and so on.

We have already been back-porting some dependency updates (e.g. xstream),
as security scanners pick them up even though we know we aren't vulnerable.

Do you think that's enough? Or some more specific wording on that page?

Thanks
Tim



On Wed, 1 Sept 2021 at 15:48, jn...@cloudbees.com 
wrote:

> Sure,
>
> I was just asking it to be added to the list of eligible criteria.  As
> with any bug that is also eligible there is a decision to be made as to if
> we are to cherry-pick the change or not.
>
> (on a randomly different note - if we where actually vulnerable - we would
> not have this luxury!)
>
> /James
>
>
>
> On Wednesday, September 1, 2021 at 3:36:05 PM UTC+1 Oleg Nenashev wrote:
>
>> I am +0.5, but being eligible does not immediately mean the change would
>> be backported. Dependency updates may also introduce regressions. As any
>> other backport, risks need to be evaluated. IMHO it should be up for
>> backporting requesters to prove the safety of changes and to ensure there
>> is enough soak testing and test coverage. Same for any other non-critical
>> backport
>>
>> On Tuesday, August 31, 2021 at 8:16:08 PM UTC+2 boa...@gmail.com wrote:
>>
>>> Are there specific libraries we can list for safe upgrades? Like
>>> XStream, Jackson, Commons, etc, for common upgrades. I wouldn’t be super
>>> comfortable with a blanket policy, but for all our more stable ones, I
>>> think it’s a good idea.
>>>
>>> Matt Sicker
>>>
>>> On Aug 31, 2021, at 09:01, wfoll...@cloudbees.com <
>>> wfoll...@cloudbees.com> wrote:
>>>
>>> Totally agree. Especially when the update is not a major bump of 3
>>> versions. Most of the time it's just a minor/bug version bump.
>>>
>>> That will greatly help on the security scanners area, where the "fear"
>>> dominates the market :-)
>>>
>>> Thanks James for the suggestion, great idea.
>>>
>>> Wadeck
>>>
>>> On Tuesday, August 31, 2021 at 3:58:38 PM UTC+2 jn...@cloudbees.com
>>> wrote:
>>>
 Hi all,

 I would like to propose that we add to the list of eligible criteria
 for backporting the following

 * is a dependency update with a known security issue

 The reason for this if we have a dependency with a security issue that
 is exploitable from Jenkins we already do include that as a LTS issue via
 the current SECURITY process, however if the issue is *not*
 exploitable then we do not. (for example the recent XStream issues have not
 impacts Jenkins as we already use an allow list).

 However as supply chain issues are becoming more prominent to our
 users, they are scanning software with automated tools that look at the
 dependencies, and these scanners do not understand how a library is used
 or  configured, and has the potential to:

 * make the software look insecure (thus be a barrier to adoption)
 or
 * cause extra nose asking about CVE-2021-123456

 WDYT?

 /James

>>> --
>>> 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/6d65b90e-1e31-475c-b3f6-9920bb4ee33en%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/bad90cc0-1307-4184-9d3f-2a6a27345ddan%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/CAH-3BieHQt%3D9hzh2mJjv9p2-LSKSaYtcdz%3D9K0kN9CKMGpioTA%40mail.gmail.com.

[jenkins/blueocean] the url to access stage log is inconsistent

['Henry Xu' via Jenkins Developers]

Stage log is  one of my favorite features of Blue Ocean. But the 
inconsistent link to the stage log make me feel annoyed.
As a Jenkins share library maintainer, I want to get the url of stage log 
and put them in the report to make it easier for users to debug the issue.
I can get the correct stage ID in scripted pipeline, the problem is, if the 
stage is not in parallel block, it works well to access the log via stage 
ID. But if the stage is in parallel block then its log cannot be accessed 
by stage ID, but I have to find its parent parallel node's ID to access the 
log. It will throw the following error if you try to access it via the 
stage id:

{ "message" : "Stage 157 not found in pipeline my-pipeline", "code" : 404, 
"errors" : [ ] }

I did some research myself and find it may have something to do with how 
blueocean render flow graph. 
(blueocean-pipeline-api-impl/src/main/java/io/jenkins/blueocean/rest/impl/pipeline/PipelineNodeGraphVisitor.java)
I think a better way for doing this is to provide a general purpose rest 
API endpoint to allow users to access the stage log via stage id, which 
will make it more easier for the end user to use this awesome feature.

-- 
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/f310523f-dd7e-4cc9-90d1-2fb0a7a18b71n%40googlegroups.com.

Jenkins Election 2021 Proposal

['Olblak' via Jenkins Developers]

Hi Everybody,

As you may guess with the title, I am looking for feedback regarding the 
upcoming election.
I would like to validate this process by next week's Governance meeting

Feel free to add your suggestion or feedback on community.jenkins.io 


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/1bd57fb3-b4a4-4804-8e47-c16564e764den%40googlegroups.com.

Re: Check whether a plugin is successfully released

[mark chen]

Thanks for all the suggestions. They are indeed very helpful!

On Wednesday, 1 September 2021 at 23:42:32 UTC+8 Jesse Glick wrote:

> Also https://plugins.jenkins.io/lucene-search/#releases though there may 
> be a time lag.
>
> Gavin’s answer is definitive. Also: 
> https://gist.github.com/jglick/0a85759ea65f60e107ac5a85a5032cae
>

-- 
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/1b2128fa-7591-441e-a203-a1f6e07d1724n%40googlegroups.com.