Using JDK 11 instead of JDK 8 in default docker images

[Mark Waite]

The Jenkins docker images are currently using Java 8 unless the image name 
specifically includes 'jdk11' in the name. 

The platform SIG discussed last Friday that we think September 2021 would 
be a good goal to deliver JDK 11 as the standard JDK in those images 
instead of JDK 8.

This change is independent of Java 17 support, but would happen at roughly 
the time when the new Java LTS (Java 17) is expected to be released.  This 
change does not have any dependency on Java 17 and does not assume any 
requirement for support (or non-support) of Java 17.

This thread is intended to start the discussions.  I'd love to have the 
discussions concluded before the June 25, 2021 Jenkins Contributor Summit 
associated with cdCon.

We'd write a blog post announcing the change like we did for the controller 
change from Debian Stretch to Debian Buster.  We would include information 
about the change in the upgrade guide for the September LTS release.

What concerns do you have related to that idea?

The images that would change include:

   - Controller Image - jenkins/jenkins
  - lts
  - lts-centos7
  - centos7
  - lts-centos
  - centos
  - lts-slim
  - slim
  - lts-alpine
  - alpine
  - latest
   - Agent Base Image - jenkins/agent
  - stretch (obsolete)
  - buster
  - alpine
  - latest
   - SSH Agent Image - jenkins/ssh-agent
  - stretch
  - alpine
  - latest (which is an unlabeled buster)
   - Inbound Agent Image - jenkins/inbound-agent
  - alpine
  - latest
   
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/7b4ac5ab-0d8d-414b-a9c4-b1bc68a6f923n%40googlegroups.com.

ScheduledFutures and Cancelling?

[Bryan Stopp]

When writing a custom step that creates a scheduled task, are you 
responsible for calling the "cancel()" method before/after you call 
"onSuccess/onFailure"

I'm getting an error:

completed: already completed CpsStepContext

after my timer has called the onSuccess method, so I assume i'm not doing 
things in the correct order.

Is there a good example of the proper methodology for this? The only 
example i can find is the WaitConditionStep - but that calls a body with 
callback, and so it sets up a net-new timer w/ new runnable instance; not a 
repeated call of the same Runnable.

Right now with this error i'm guessing i should do, these steps *always* in 
this order:

onSuccess/onFailure (depending on state)
task.cancel(true);
task = null;
return;

Am i wrong or missing something?

Thanks in advance!

-Bryan

-- 
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/d9f92ef1-0a19-42c5-929c-8499b8020addn%40googlegroups.com.

Plugin end-of-life (EOL) policy

[Basil Crow]

Abandoned plugins cause friction for both Jenkins users and contributors
alike.

They cause friction for users because they are unlikely to be simpatico
with newer features like Pipeline. In the worst case, they are downright
incompatible with newer features like Configuration Form Modernization
and cause breakage that is difficult for users to resolve.

They cause friction for contributors by making it difficult to perform
project-wide changes, such as Configuration Form Modernization or
dependency updates.

True, distributing as many plugins as possible for as long as possible
maximizes the value the project provides and maintains the project's
strong reputation for flexibility. Yet, treating abandoned plugins as
first-class citizens indefinitely carries a non-trivial cost, and that
cost only increases the longer a plugin remains abandoned.

The project is over 15 years old, and some plugins have been abandoned
for the better part of a decade. Many of these plugins will likely
remain abandoned for the next decade. At what point does the cost of
carrying these plugins outweigh the benefit?

I do not know the answer, but I do know that the answer is not "never".
Contributor bandwidth is a finite resource. However, there remain
hundreds of plugins that have been abandoned for the better part of a
decade yet are seemingly presented as first-class citizens without so
much as a deprecation notice. This does not seem sustainable.

I would like to propose that we define a process for plugin end-of-life:
initially marking such plugins as deprecated, then eventually removing
such plugins from distribution.

How would we decide when to deprecate a plugin or remove it from
distribution? We could use metrics such as the number of days since the
last release and the number of installations. For example, we could
declare that any plugin that has not been released in five years would
be automatically deprecated and that any plugin that has remained
deprecated for more than five years would be removed from distribution.
We could put escape hatches in place to exempt sufficiently popular
plugins from this policy.

I do not have a strong preference as to how long the support window
should be. But I do have a strong preference that it be finite:
supporting an unbounded number of plugins as first-class citizens for an
unbounded amount of time does not seem sustainable.

I can already hear Oleg calling for a blog post to be written announcing
such a policy months in advance of its implementation, were such a
policy to be agreed upon. That would be fine by me as well. Again, the
point is not to be overly aggressive or to surprise users, but rather to
put reasonable limits in place that support the project's long-term
goals given the finite resources that are available.

-- 
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/CAFwNDjoNMRbkDdkcjYMZSauCfE%2BRQ6pkv_jGG5W2RTqaDiJM2w%40mail.gmail.com.

Re: Jenkins won't start after plugin update?

[G. Michael Carter]

Funny never fails, searching for an answer on and off since Apr 20th...5
minutes after asking for help... actually found it... (was what you were
basically saying)

Turns out one of the other developers/admins quietly changed
the slaveAgentPort port and didn't tell anyone.   When I asked in our team
meeting everyone said they hadn't changed anything in months.   Someone
lied.   Too bad this only tracks the user as "SYSTEM"... think people
forget we have this thing enabled... good thing too.

2021-04-18_17-00-25/config.xml:  45001
2021-04-19_09-46-03/config.xml:  443


On Mon, Apr 26, 2021 at 12:23 PM 'Gavin Mogan' via Jenkins Developers <
jenkinsci-dev@googlegroups.com> wrote:

> Permission denied sounds like your either using a port that is already
> used, or using below 1024. I don't think either are plugin related per say.
>
> On Mon, Apr 26, 2021 at 9:14 AM Michael Carter 
> wrote:
>
>> I was testing out my new changes to my plugin.   Did update all on all
>> plugins.
>>
>> Did systemctl restart jenkins.
>>
>> Now starting I get:
>>
>> 2021-04-26 16:08:28.416+ [id=86] INFO 
>> hudson.model.AsyncPeriodicWork#lambda$doRun$0:
>> Finished Download metadata. 461 ms
>> 2021-04-26 16:08:28.941+ [id=34] INFO 
>> jenkins.InitReactorRunner$1#onAttained:
>> Completed initialization
>> 2021-04-26 16:08:29.077+ [id=22] SEVERE hudson.util.BootFailure#publish:
>> Failed to initialize Jenkins
>> java.net.SocketException: Permission denied
>> at sun.nio.ch.Net.bind0(Native Method)
>> at sun.nio.ch.Net.bind(Net.java:444)
>> at sun.nio.ch.Net.bind(Net.java:436)
>> at
>> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:225)
>> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
>> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
>> at hudson.TcpSlaveAgentListener.(TcpSlaveAgentListener.java:100)
>> at jenkins.model.Jenkins.launchTcpSlaveAgentListener(Jenkins.java:1298)
>> at jenkins.model.Jenkins.(Jenkins.java:985)
>> at hudson.model.Hudson.(Hudson.java:85)
>> at hudson.model.Hudson.(Hudson.java:81)
>> at hudson.WebAppMain$3.run(WebAppMain.java:295)
>> Caused: hudson.util.HudsonFailedToLoad
>> at hudson.WebAppMain$3.run(WebAppMain.java:312)
>> 2021-04-26 16:08:29.169+ [id=22] INFO jenkins.model.Jenkins#cleanUp:
>> Stopping Jenkins
>>
>> Tried disabling the plugin in question, disabling all nodes, copying over
>> the jenkins.war file sync'ing the plugin directory from a working setup
>>
>> how do I track down the main cause?
>>
>> The other two servers I have using the same setup works fine so I'm
>> assuming some file got corrupted somewhere.
>>
>> --
>> 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/cca3a6f8-ca9f-4d2a-86be-06c9cb075ea3n%40googlegroups.com
>> 
>> .
>>
> --
> 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/3z_hNyCCtWs/unsubscribe.
> To unsubscribe from this group and all its topics, 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_DuvmqaOO%2Bu6Y1Uha2SSOOEdNMWBoHsuBuMgv2x_D%3D_Javw%40mail.gmail.com
> 
> .
>


-- 

*G. Michael Carter*
Contact: 1-519-217-0441
Google Talk: xmpp:mikeycarter1...@gmail.com
Instagram:  mikey.carter
Facebook: https://www.facebook.com/MikeyCarter1974







-- 
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/CANjusZfamaiRpuq5C2TfaroqToA-puzqiHKsj0TWd08pwCzUtA%40mail.gmail.com.

Re: ANN - DevOps World 2021 CFP is Open

[Oleg Nenashev]

On May 04 we will host the Ask-Me-Anything session for the community track 
and call for papers! The conference will take place on Sep 28-30. If you 
are interested to participate, please vote for timeslots in this Doodle 
. 
The session will be recorded, but joining live is good if you have any 
quesrions.

Best regards,
Oleg Nenashev


On Thursday, April 22, 2021 at 2:30:40 AM UTC+2 alytong13 wrote:

> Hi all,
>
> DevOps World 2021  is now accepting speaking 
> proposals, and will end on May 20. The conference will be virtual on Sept 
> 28 - 30.  Jenkins plans to have workshops, Ask the Experts, contributor 
> summit at this event. More details to come as we get closer to September. 
>
> In the meantime, we'd love to receive your Jenkins, DevOps stories. We're 
> looking for:
>
>- tips & tricks
>- best practices
>- war stories
>- how you overcame barriers and challenges
>
> Thank you,
> alyssa & Oleg
>
> 
>

-- 
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/7e2492f1-a529-47db-8c6d-f775ee6ede61n%40googlegroups.com.

Re: Jenkins won't start after plugin update?

['Gavin Mogan' via Jenkins Developers]

Permission denied sounds like your either using a port that is already
used, or using below 1024. I don't think either are plugin related per say.

On Mon, Apr 26, 2021 at 9:14 AM Michael Carter 
wrote:

> I was testing out my new changes to my plugin.   Did update all on all
> plugins.
>
> Did systemctl restart jenkins.
>
> Now starting I get:
>
> 2021-04-26 16:08:28.416+ [id=86] INFO 
> hudson.model.AsyncPeriodicWork#lambda$doRun$0:
> Finished Download metadata. 461 ms
> 2021-04-26 16:08:28.941+ [id=34] INFO 
> jenkins.InitReactorRunner$1#onAttained:
> Completed initialization
> 2021-04-26 16:08:29.077+ [id=22] SEVERE hudson.util.BootFailure#publish:
> Failed to initialize Jenkins
> java.net.SocketException: Permission denied
> at sun.nio.ch.Net.bind0(Native Method)
> at sun.nio.ch.Net.bind(Net.java:444)
> at sun.nio.ch.Net.bind(Net.java:436)
> at
> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:225)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> at hudson.TcpSlaveAgentListener.(TcpSlaveAgentListener.java:100)
> at jenkins.model.Jenkins.launchTcpSlaveAgentListener(Jenkins.java:1298)
> at jenkins.model.Jenkins.(Jenkins.java:985)
> at hudson.model.Hudson.(Hudson.java:85)
> at hudson.model.Hudson.(Hudson.java:81)
> at hudson.WebAppMain$3.run(WebAppMain.java:295)
> Caused: hudson.util.HudsonFailedToLoad
> at hudson.WebAppMain$3.run(WebAppMain.java:312)
> 2021-04-26 16:08:29.169+ [id=22] INFO jenkins.model.Jenkins#cleanUp:
> Stopping Jenkins
>
> Tried disabling the plugin in question, disabling all nodes, copying over
> the jenkins.war file sync'ing the plugin directory from a working setup
>
> how do I track down the main cause?
>
> The other two servers I have using the same setup works fine so I'm
> assuming some file got corrupted somewhere.
>
> --
> 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/cca3a6f8-ca9f-4d2a-86be-06c9cb075ea3n%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_DuvmqaOO%2Bu6Y1Uha2SSOOEdNMWBoHsuBuMgv2x_D%3D_Javw%40mail.gmail.com.

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

[Oleg Nenashev]

Dear all,

Thanks to everyone who contributed their ideas in the sub-term definitions 
list 
.
 
We've got a number of ideas and identified the missing terms where we need 
decisions. Most notable ones which require discussion:

   - Jenkins as node
   - Jenkins “main node” label - Aligned with “Jenkins as node”
   - Jenkins master pod - for K8s components
   - “Master branch” in documentation, not the repository layout
   
I suggest we continue the discussion and finalize the term decisions at the 
next governance meeting on May 05. I encourage all contributors to review 
the doc, vote for terms and let us know if you see any term missing. 
Hopefully we could build a consensus before th governance meeting happens.

Thanks for your time,
Oleg Nenashev


On Tuesday, April 20, 2021 at 12:42:14 PM UTC+2 Oleg Nenashev wrote:

> Dear all,
>
> As discussed in the Jenkins chats, we would like to continue the 
> terminology definitions we agreed on in 2020. Just to summarize the status 
> from this thread 
>  
> and the related announcements:
>
>- We adopted "controller" as a term to define the main Jenkins 
>instance which acts as a web interface and the Jenkins system controller 
>(context, agent controller, endpoint for CLI and REST API, etc.). Formerly 
>known as "master", yes
>- We agreed that localizations for the term are to be reviewed on a 
>case-by-case basis by maintainers and localization leaders. 
> Recommendations 
>for German, French, Spanish, Chinese, Italian and Russian are defined 
>here 
>
> 
>.
>- We agreed to follow-up on the naming for sub-entities of the 
>controller instance: e.g. Web interface, Jenkins as a "main" node, labels, 
>etc. This follow-up has not happened yet...
>
> In this thread I suggest to finally agree on terms for the third item so 
> that we could ensure that all patches use the same terminology. It is 
> *VERY* important, because such sub-entity terms are widespread in the 
> Jenkins Web UI. For example, a screenshot from Danioel Beck:
>
> [image: image.png]
>
> I have started a table for sub-entity terms here 
> ,
>  
> this document is open for any suggestions. We kindly invite all interested 
> contributors to:
>
>- Help us identify areas where "controller"/"master" terms need to be 
>amended. These terms might be used inside the Jenkins core or in any other 
>Jenkins components: docs, plugins, etc. Whatever you see, let's fix that
>- Come up with term proposals or comment on already proposed ones
>
> Thanks in advance to all contributors!
>
> Best regards,
> Oleg Nenashev
> Jenkins Governance Board
>
>
>

-- 
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/418e46bd-a0b9-4db8-b702-f1c4f3a2aca3n%40googlegroups.com.

Jenkins won't start after plugin update?

[Michael Carter]

I was testing out my new changes to my plugin.   Did update all on all 
plugins.

Did systemctl restart jenkins.

Now starting I get: 

2021-04-26 16:08:28.416+ [id=86] INFO 
hudson.model.AsyncPeriodicWork#lambda$doRun$0: 
Finished Download metadata. 461 ms
2021-04-26 16:08:28.941+ [id=34] INFO 
jenkins.InitReactorRunner$1#onAttained: 
Completed initialization
2021-04-26 16:08:29.077+ [id=22] SEVERE hudson.util.BootFailure#publish: 
Failed to initialize Jenkins
java.net.SocketException: Permission denied
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:444)
at sun.nio.ch.Net.bind(Net.java:436)
at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:225)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
at hudson.TcpSlaveAgentListener.(TcpSlaveAgentListener.java:100)
at jenkins.model.Jenkins.launchTcpSlaveAgentListener(Jenkins.java:1298)
at jenkins.model.Jenkins.(Jenkins.java:985)
at hudson.model.Hudson.(Hudson.java:85)
at hudson.model.Hudson.(Hudson.java:81)
at hudson.WebAppMain$3.run(WebAppMain.java:295)
Caused: hudson.util.HudsonFailedToLoad
at hudson.WebAppMain$3.run(WebAppMain.java:312)
2021-04-26 16:08:29.169+ [id=22] INFO jenkins.model.Jenkins#cleanUp: 
Stopping Jenkins

Tried disabling the plugin in question, disabling all nodes, copying over 
the jenkins.war file sync'ing the plugin directory from a working setup 

how do I track down the main cause?

The other two servers I have using the same setup works fine so I'm 
assuming some file got corrupted somewhere.

-- 
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/cca3a6f8-ca9f-4d2a-86be-06c9cb075ea3n%40googlegroups.com.

Re: Removing the "Vulnerability" banner on the Nomad plugin page

[Jonathan Ballet]

Hi Daniel,

On Mon, 26 Apr 2021, at 14:35, Daniel Beck wrote:
> Thanks for letting us know!
> 
> The documentation for this specifically is at 
> https://www.jenkins.io/security/plugins/#followup

Oh right, I completely missed it, thanks for pointing this out!

> I filed https://github.com/jenkins-infra/update-center2/pull/515 updating the 
> warning and will merge it once I confirm the issue was fully resolved. This 
> will remove the banner from plugins.jenkins.io and the warning shown to 
> admins inside Jenkins.

Perfect, thanks a lot!

Best,

 Jonathan

> 
> On Mon, Apr 26, 2021 at 1:41 PM j...@multani.info  wrote:
>> 
>> Hi,
>> 
>> I became recently maintainer for the Nomad plugin 
>> , and it currently shows a banner saying 
>> "The current version of this plugin contains a vulnerability", although it 
>> has been fixed (AFAIK) a 2 years ago 
>> ,
>>  and released in version v0.5.1 (latest version is v0.7.4).
>> 
>> I'm also new to being a plugin maintainer, and after reading the security 
>> documentation for maintainers 
>> , I'm still not sure:
>> 
>> * How is this banner generated?
>> * How to acknowledge the fix and remove the banner from both the plugin page 
>> and from Jenkins itself?
>> * Or, if there's an automated process that still finds the error, how to see 
>> that and fix the problem?
>> 
>> Thanks for the pointers,
>> 
>>  Jonathan

-- 
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/d1cbcbbd-1c92-4ea5-a3cd-aa81e5f8da01%40www.fastmail.com.

Re: Removing the "Vulnerability" banner on the Nomad plugin page

[Daniel Beck]

Thanks for letting us know!

The documentation for this specifically is at
https://www.jenkins.io/security/plugins/#followup

I filed https://github.com/jenkins-infra/update-center2/pull/515 updating
the warning and will merge it once I confirm the issue was fully resolved.
This will remove the banner from plugins.jenkins.io and the warning shown
to admins inside Jenkins.

On Mon, Apr 26, 2021 at 1:41 PM j...@multani.info  wrote:

>
> Hi,
>
> I became recently maintainer for the Nomad plugin
> , and it currently shows a banner
> saying "The current version of this plugin contains a vulnerability",
> although it has been fixed (AFAIK) a 2 years ago
> ,
> and released in version v0.5.1 (latest version is v0.7.4).
>
> I'm also new to being a plugin maintainer, and after reading the security
> documentation for maintainers
> , I'm still not sure:
>
> * How is this banner generated?
> * How to acknowledge the fix and remove the banner from both the plugin
> page and from Jenkins itself?
> * Or, if there's an automated process that still finds the error, how to
> see that and fix the problem?
>
> Thanks for the pointers,
>
>  Jonathan
>
> --
> 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/1999ea96-461a-47ac-ab70-65c912b6d10dn%40googlegroups.com
> 
> .
>


-- 

Daniel Beck
Senior Software 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/CAMo7PtL6XNpuULKCVddL5xgv0-kReKXT5XqiVybz8O3MXoQ5Dg%40mail.gmail.com.

Removing the "Vulnerability" banner on the Nomad plugin page

[j...@multani.info]

Hi,

I became recently maintainer for the Nomad plugin 
, and it currently shows a banner saying 
"The current version of this plugin contains a vulnerability", although it 
has been fixed (AFAIK) a 2 years ago 
,
 
and released in version v0.5.1 (latest version is v0.7.4).

I'm also new to being a plugin maintainer, and after reading the security 
documentation for maintainers 
, I'm still not sure:

* How is this banner generated?
* How to acknowledge the fix and remove the banner from both the plugin 
page and from Jenkins itself?
* Or, if there's an automated process that still finds the error, how to 
see that and fix the problem?

Thanks for the pointers,

 Jonathan

-- 
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/1999ea96-461a-47ac-ab70-65c912b6d10dn%40googlegroups.com.