[Fuego] Installed plugins not listed under ‘Plugin Manager’ -> ‘Installed’ page

[Fuego] Installed plugins not listed under ‘Plugin Manager’ -> ‘Installed’ page

[Dhinakar Kalyanasundaram/FDS SW /SSIR/Staff Engineer/삼성전자]

[-- Attachment #1: Type: text/plain, Size: 1552 bytes --]

Dear Fuego users,

 

I am using Fuego VERSION=1.5.0 and Jenkins ver. 2.164.2

 

I was trying to install a few Jira plugins to interface from Jenkins.

After a while I noticed the below warning message (in many of my plugins) and many of my already installed & setup plugins like ‘Ant’, ‘Structs’, ‘Sidebar Link’, ‘Gerrit Trigger’ etc. were missing even though their folders and *.jpi files were still available under  ‘/var/lib/jenkins/plugins’ directory inside docker container.

 

Warning: This plugin requires dependent plugins that require Jenkins 2.249.1 or newer. Jenkins will refuse to load the dependent plugins requiring a newer version of Jenkins, and in turn loading this plugin will fail.

 

Now, I see many of my above plugin’s next version listed under ‘Plugin Manager’ -> ‘Available’ with the above warning message.

For e.g. Structs 1.20 version is already installed but not listed under ‘Plugin Manager’ -> ‘Installed’ page but instead ‘Plugin Manager’ -> ‘Available’ is showing the next version of ‘Structs’ with the warning shown above (in red italics).

 

I tried removing the newly installed plugins and restart Jenkins & docker container multiple times but still the issue was not solved.

Any suggestions to fix this?

Since I have lot of jobs configured with plugins like ‘Sidebar Link’, ‘Post Build Task’ etc. I cannot reinstall or upgrade fuego.

Thanks in advance.

 

Regards,

Dhinakar

 


[-- Attachment #2.1: Type: text/html, Size: 7541 bytes --]

[-- Attachment #2.2: Type: image/gif, Size: 13402 bytes --]

Re: [Fuego] Installed plugins not listed under ‘Plugin Manager’ -> ‘Installed’ page

[Bird, Tim]

Dhinakar,

I'm sorry that you are having problems with the Jenkins plugins.
This has been a perennial problem for Fuego, trying to keep up with the constant
churn as the versions of Jenkins and its plugins keeps changing.

Here is some information and some tips, in the hopes that it will be useful for you.

When Fuego installs, it uses a hardcoded Jenkins version.
In previous versions of Fuego, we hardcoded frozen versions of the Jenkins plugins,
so that when the docker container was created, it didn't pick up arbitrary plugin
versions, that might not be compatible with the version of Jenkins used in 
the Fuego docker image.

However, the last time we did a Jenkins version upgrade was in Dec 1, 2020.
At that time, for reasons unknown, we changed the Dockerfile so that the
plugin versions could float (that is, the latest version of each Jenkins plugin
would be used).  This code has since been refactored to make native installs
easier, but the use of non-frozen versions of plugins still remains.

In any event, I have an old docker container from December of 2020, that has
the original versions of plugins that were compatible with Jenkins 2.249.3
(which was the version of Jenkins used in the 1.5.0 release of Fuego).

Here are the version of plugins  in that container:
ant:1.11
antisamy-markup-formatter:2.1
bootstrap4-api:4.5.3-1
bouncycastle-api:2.18
checks-api:1.1.1
command-launcher:1.5
description-setter:1.10
display-url-api:2.3.4
echarts-api:4.9.0-2
external-monitor-job:1.7
flot:1.0-SNAPSHOT (private-07/21/2017 10:45-dsl)
font-awesome-api:5.15.1-1
greenballs:1.15
icon-shim:2.0.3
jackson2-api:2.12.0
javadoc:1.6
jdk-tool:1.4
jquery3-api:3.5.1-2
junit:1.45
ldap:1.11
mailer:1.32.1
matrix-auth:2.6.4
matrix-project:1.18
pam-auth:1.6
pegdown-formatter:1.3
plugin-util-api:1.5.0
popper-api:1.16.0-7
scm-api:2.6.4
script-security:1.75
snakeyaml-api:1.27.0
structs:1.20
trilead-api:1.0.4
windows-slaves:1.7
workflow-api:2.40
workflow-step-api:2.23

the Fuego install system uses an external script to install plugins (rather than doing so inside
Jenkins itself).  This script is found inside the fuego docker container at: /usr/local/bin/install-plugins.sh

To use it, you specify a list of plugins to install, on the command line.  You can include a version number
for a package by including the version number following the package name and a colon (e.g. structs:1.20)

It sounds like some of your plugin operations have upgraded your existing plugins, so that now there
are dependency problems with the collection of plugins on your system.

There are 2 ways to proceed:  1) Stay with version 2.249.3 of Jenkins, and try to revert your plugins to ones
that will work with that version of Jenkins, or 2) migrate to a newer version of Jenkins.

Option 2 is, IMHO, fraught with peril. But, depending on the extra modules you want to install and your
sensitivity to security issues, it may be the best route forward.  If the jira plugins you want to install
rely on newer modules which themselves rely on a newer Jenkins version, then in order to install
those you may have no choice but to update the version of Jenkins.

Option 1 also entails some danger (as I have not tried the instructions I am about to provide), but 
it *should* work.  Try uninstalling the plugins that have versions that don't match the ones in
the above list (that are known to be compatible with Jenkins 2.249.3).  Then use install-plugins.sh
to re-install specific versions of the modules that match the list above.

In order to run install-plugins.sh, you need to define two environment variables, to indicate
the Jenkins upload center and the Jenkins plugin directory.  These are names JENKINS_UC
and REF, respectively.

$ export JENKINS_UC=https://updates.jenkins.io
$ export REF=/var/lib/jenkins/plugins
$ ./install-plugins.sh <plugin1> <plugin2> ...

To test the script, and get a list of currently installed plugins, you can specify to install
a non-existent plugin.  Here's what I did, and the output I got back from it:
Note that I get some curl certificate errors, but I think those can be ignored for the purposes
of this operation.

--------

root@timdesk:/usr/local/bin# export JENKINS_UC=https://updates.jenkins.io
root@timdesk:/usr/local/bin# export REF=/var/lib/jenkins/plugins
root@timdesk:/usr/local/bin# ./install-plugins.sh foo
Creating initial locks...
Analyzing war...
Registering preinstalled plugins...
Downloading plugins...
Downloading plugin: foo from https://updates.jenkins.io/download/plugins/foo/latest/foo.hpi
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.
23:57:40 Failure (60) Retrying in 1 seconds...
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.
23:57:42 Failure (60) Retrying in 1 seconds...
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html

curl performs SSL certificate verification by default, using a "bundle"
 of Certificate Authority (CA) public keys (CA certs). If the default
 bundle file isn't adequate, you can specify an alternate file
 using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
 the bundle, the certificate verification probably failed due to a
 problem with the certificate (it might be expired, or the name might
 not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
 the -k (or --insecure) option.
23:57:43 Failure (60) Retrying in 1 seconds...
23:57:44 Failed in the last attempt (curl -sSfL --connect-timeout 20 --retry 3 --retry-delay 0 --retry-max-time 60 https://updates.jenkins.io/download/plugins/foo/latest/foo.hpi -o /var/lib/jenkins/plugins/foo.jpi)
./install-plugins.sh: line 63: $3: unbound variable

WAR bundled plugins:


Installed plugins:
ant:1.11
antisamy-markup-formatter:2.1
bootstrap4-api:4.5.3-1
bouncycastle-api:2.18
checks-api:1.1.1
command-launcher:1.5
description-setter:1.10
display-url-api:2.3.4
echarts-api:4.9.0-2
external-monitor-job:1.7
flot:1.0-SNAPSHOT (private-07/21/2017 10:45-dsl)
font-awesome-api:5.15.1-1
greenballs:1.15
icon-shim:2.0.3
jackson2-api:2.12.0
javadoc:1.6
jdk-tool:1.4
jquery3-api:3.5.1-2
junit:1.45
ldap:1.11
mailer:1.32.1
matrix-auth:2.6.4
matrix-project:1.18
pam-auth:1.6
pegdown-formatter:1.3
plugin-util-api:1.5.0
popper-api:1.16.0-7
scm-api:2.6.4
script-security:1.75
snakeyaml-api:1.27.0
structs:1.20
trilead-api:1.0.4
windows-slaves:1.7
workflow-api:2.40
workflow-step-api:2.23
Cleaning up locks

-----------------

Please try either option 1 or 2 and let me know what happens.

By the way, you can shutdown Jenkins inside the docker container, and restart it, by doing this,
inside the container, as root.
$ service jenkins stop
$ service jenkins start

Doing this might clear up the issue with plugins being present in the installation directory
but not registered with the system.  You probably want to do this after installing plugins
from the docker container command line.

You might also try to reset Jenkins from inside the web interface by going to "manage Jenkins",
"Reload Configuration from Disk".

I hope this helps.  Let me know what you try, and what the eventual outcome is.

Best of luck!
 -- Tim

P.S. If you decide to upgrade the version of Jenkins, make sure you check the Jenkins
config.xml for items that are needed by Fuego for proper Jenkins operations.
Sometimes, newer Jenkins versions will change the items in the config.xml file
in a way that is not backwards compatible.  The config.xml that Fuego uses when
it installs Jenkins into the docker container originally is in: fuego/frontend-install/config.xml


> -----Original Message-----
> From: Dhinakar Kalyanasundaram/FDS SW /SSIR/Staff Engineer/삼성전자 <dhinakar.k@samsung.com>
> 
> Dear Fuego users,
> 
> 
> 
> I am using Fuego VERSION=1.5.0 and Jenkins ver. 2.164.2
> 
> 
> 
> I was trying to install a few Jira plugins to interface from Jenkins.
> 
> After a while I noticed the below warning message (in many of my plugins) and many of my already installed & setup plugins like ‘Ant’,
> ‘Structs’, ‘Sidebar Link’, ‘Gerrit Trigger’ etc. were missing even though their folders and *.jpi files were still available under
> ‘/var/lib/jenkins/plugins’ directory inside docker container.
> 
> 
> 
> Warning: This plugin requires dependent plugins that require Jenkins 2.249.1 or newer. Jenkins will refuse to load the dependent plugins
> requiring a newer version of Jenkins, and in turn loading this plugin will fail.
> 
> 
> 
> Now, I see many of my above plugin’s next version listed under ‘Plugin Manager’ -> ‘Available’ with the above warning message.
> 
> For e.g. Structs 1.20 version is already installed but not listed under ‘Plugin Manager’ -> ‘Installed’ page but instead ‘Plugin Manager’ ->
> ‘Available’ is showing the next version of ‘Structs’ with the warning shown above (in red italics).
> 
> 
> 
> I tried removing the newly installed plugins and restart Jenkins & docker container multiple times but still the issue was not solved.
> 
> Any suggestions to fix this?
> 
> Since I have lot of jobs configured with plugins like ‘Sidebar Link’, ‘Post Build Task’ etc. I cannot reinstall or upgrade fuego.
> 
> Thanks in advance.
> 
> 
> 
> Regards,
> 
> Dhinakar
> 
> 
> 
> 
> 
> 
> 
> 
> 
> <http://ext.samsung.net/mail/ext/v1/external/status/update?userid=dhinakar.k&do=bWFpbElEPTIwMjIwMjE3MTA1NjI3ZXBjYXM1cDFlMjR
> hZDlmZGRjNTA1ZDAyNmRiZmU4NjQ4ZmU4YTVhYSZyZWNpcGllbnRBZGRyZXNzPVRpbS5CaXJkQHNvbnkuY29t>

Re: [Fuego] Installed plugins not listed under ‘Plugin Manager’ -> ‘Installed’ page

[Dhinakar Kalyanasundaram/FDS SW /SSIR/Staff Engineer/삼성전자]

Tim Bird,

Thanks a lot for your detailed response.
I tried with Option 1 first but even though I manually removed and re-installed some of the plugins, I could not see those plugins in http://107.108.73.156:8084/storm/pluginManager/installed page.
Since my jenkins version was 2.164.2 I thought it is better to upgrade jenkins as suggested by you in Option 2.
I first moved to 2.249.3 but still some plugin dependencies could not be resolved I moved to 2.263.1.
Now the plugin issues were resolved, I need to run jobs and check if any hidden issues are there.
Meanwhile, I would like to know what are the common issues faced by users who chose to upgrade jenkins.

Regards,
Dhinakar

> -----Original Message-----
> From: Bird, Tim <Tim.Bird@sony.com>
> Sent: Saturday, February 19, 2022 6:09 AM
> To: Dhinakar Kalyanasundaram/FDS SW /SSIR/Staff Engineer/삼성전자
> <dhinakar.k@samsung.com>; fuego@lists.linuxfoundation.org
> Subject: RE: Installed plugins not listed under ‘Plugin Manager’ -> ‘Installed’
> page
> 
> Dhinakar,
> 
> I'm sorry that you are having problems with the Jenkins plugins.
> This has been a perennial problem for Fuego, trying to keep up with the
> constant churn as the versions of Jenkins and its plugins keeps changing.
> 
> Here is some information and some tips, in the hopes that it will be useful for
> you.
> 
> When Fuego installs, it uses a hardcoded Jenkins version.
> In previous versions of Fuego, we hardcoded frozen versions of the Jenkins
> plugins, so that when the docker container was created, it didn't pick up
> arbitrary plugin versions, that might not be compatible with the version of
> Jenkins used in the Fuego docker image.
> 
> However, the last time we did a Jenkins version upgrade was in Dec 1, 2020.
> At that time, for reasons unknown, we changed the Dockerfile so that the
> plugin versions could float (that is, the latest version of each Jenkins plugin
> would be used).  This code has since been refactored to make native installs
> easier, but the use of non-frozen versions of plugins still remains.
> 
> In any event, I have an old docker container from December of 2020, that has
> the original versions of plugins that were compatible with Jenkins 2.249.3
> (which was the version of Jenkins used in the 1.5.0 release of Fuego).
> 
> Here are the version of plugins  in that container:
> ant:1.11
> antisamy-markup-formatter:2.1
> bootstrap4-api:4.5.3-1
> bouncycastle-api:2.18
> checks-api:1.1.1
> command-launcher:1.5
> description-setter:1.10
> display-url-api:2.3.4
> echarts-api:4.9.0-2
> external-monitor-job:1.7
> flot:1.0-SNAPSHOT (private-07/21/2017 10:45-dsl)
> font-awesome-api:5.15.1-1
> greenballs:1.15
> icon-shim:2.0.3
> jackson2-api:2.12.0
> javadoc:1.6
> jdk-tool:1.4
> jquery3-api:3.5.1-2
> junit:1.45
> ldap:1.11
> mailer:1.32.1
> matrix-auth:2.6.4
> matrix-project:1.18
> pam-auth:1.6
> pegdown-formatter:1.3
> plugin-util-api:1.5.0
> popper-api:1.16.0-7
> scm-api:2.6.4
> script-security:1.75
> snakeyaml-api:1.27.0
> structs:1.20
> trilead-api:1.0.4
> windows-slaves:1.7
> workflow-api:2.40
> workflow-step-api:2.23
> 
> the Fuego install system uses an external script to install plugins (rather than
> doing so inside Jenkins itself).  This script is found inside the fuego docker
> container at: /usr/local/bin/install-plugins.sh
> 
> To use it, you specify a list of plugins to install, on the command line.  You can
> include a version number for a package by including the version number
> following the package name and a colon (e.g. structs:1.20)
> 
> It sounds like some of your plugin operations have upgraded your existing
> plugins, so that now there are dependency problems with the collection of
> plugins on your system.
> 
> There are 2 ways to proceed:  1) Stay with version 2.249.3 of Jenkins, and try
> to revert your plugins to ones that will work with that version of Jenkins, or 2)
> migrate to a newer version of Jenkins.
> 
> Option 2 is, IMHO, fraught with peril. But, depending on the extra modules
> you want to install and your sensitivity to security issues, it may be the best
> route forward.  If the jira plugins you want to install rely on newer modules
> which themselves rely on a newer Jenkins version, then in order to install
> those you may have no choice but to update the version of Jenkins.
> 
> Option 1 also entails some danger (as I have not tried the instructions I am
> about to provide), but it *should* work.  Try uninstalling the plugins that
> have versions that don't match the ones in the above list (that are known to
> be compatible with Jenkins 2.249.3).  Then use install-plugins.sh to re-install
> specific versions of the modules that match the list above.
> 
> In order to run install-plugins.sh, you need to define two environment
> variables, to indicate the Jenkins upload center and the Jenkins plugin
> directory.  These are names JENKINS_UC and REF, respectively.
> 
> $ export JENKINS_UC=https://updates.jenkins.io
> $ export REF=/var/lib/jenkins/plugins
> $ ./install-plugins.sh <plugin1> <plugin2> ...
> 
> To test the script, and get a list of currently installed plugins, you can specify
> to install a non-existent plugin.  Here's what I did, and the output I got back
> from it:
> Note that I get some curl certificate errors, but I think those can be ignored
> for the purposes of this operation.
> 
> --------
> 
> root@timdesk:/usr/local/bin# export
> JENKINS_UC=https://updates.jenkins.io
> root@timdesk:/usr/local/bin# export REF=/var/lib/jenkins/plugins
> root@timdesk:/usr/local/bin# ./install-plugins.sh foo Creating initial locks...
> Analyzing war...
> Registering preinstalled plugins...
> Downloading plugins...
> Downloading plugin: foo from
> https://updates.jenkins.io/download/plugins/foo/latest/foo.hpi
> curl: (60) SSL certificate problem: certificate has expired More details here:
> https://protect2.fireeye.com/v1/url?k=9e437f5d-c1d84794-9e42f412-
> 0cc47a336fae-52a4eafdb6f541c5&q=1&e=9a036cb4-fc47-47cb-a812-
> 14354795baa0&u=https%3A%2F%2Fcurl.haxx.se%2Fdocs%2Fsslcerts.html
> 
> curl performs SSL certificate verification by default, using a "bundle"
>  of Certificate Authority (CA) public keys (CA certs). If the default  bundle file
> isn't adequate, you can specify an alternate file  using the --cacert option.
> If this HTTPS server uses a certificate signed by a CA represented in  the
> bundle, the certificate verification probably failed due to a  problem with the
> certificate (it might be expired, or the name might  not match the domain
> name in the URL).
> If you'd like to turn off curl's verification of the certificate, use  the -k (or --
> insecure) option.
> 23:57:40 Failure (60) Retrying in 1 seconds...
> curl: (60) SSL certificate problem: certificate has expired More details here:
> https://protect2.fireeye.com/v1/url?k=c5b9e4dd-9a22dc14-c5b86f92-
> 0cc47a336fae-d00fe4ef3dd99b9f&q=1&e=9a036cb4-fc47-47cb-a812-
> 14354795baa0&u=https%3A%2F%2Fcurl.haxx.se%2Fdocs%2Fsslcerts.html
> 
> curl performs SSL certificate verification by default, using a "bundle"
>  of Certificate Authority (CA) public keys (CA certs). If the default  bundle file
> isn't adequate, you can specify an alternate file  using the --cacert option.
> If this HTTPS server uses a certificate signed by a CA represented in  the
> bundle, the certificate verification probably failed due to a  problem with the
> certificate (it might be expired, or the name might  not match the domain
> name in the URL).
> If you'd like to turn off curl's verification of the certificate, use  the -k (or --
> insecure) option.
> 23:57:42 Failure (60) Retrying in 1 seconds...
> curl: (60) SSL certificate problem: certificate has expired More details here:
> https://protect2.fireeye.com/v1/url?k=bbfbff80-e460c749-bbfa74cf-
> 0cc47a336fae-4376695a932d0415&q=1&e=9a036cb4-fc47-47cb-a812-
> 14354795baa0&u=https%3A%2F%2Fcurl.haxx.se%2Fdocs%2Fsslcerts.html
> 
> curl performs SSL certificate verification by default, using a "bundle"
>  of Certificate Authority (CA) public keys (CA certs). If the default  bundle file
> isn't adequate, you can specify an alternate file  using the --cacert option.
> If this HTTPS server uses a certificate signed by a CA represented in  the
> bundle, the certificate verification probably failed due to a  problem with the
> certificate (it might be expired, or the name might  not match the domain
> name in the URL).
> If you'd like to turn off curl's verification of the certificate, use  the -k (or --
> insecure) option.
> 23:57:43 Failure (60) Retrying in 1 seconds...
> 23:57:44 Failed in the last attempt (curl -sSfL --connect-timeout 20 --retry 3 --
> retry-delay 0 --retry-max-time 60
> https://updates.jenkins.io/download/plugins/foo/latest/foo.hpi -o
> /var/lib/jenkins/plugins/foo.jpi)
> ./install-plugins.sh: line 63: $3: unbound variable
> 
> WAR bundled plugins:
> 
> 
> Installed plugins:
> ant:1.11
> antisamy-markup-formatter:2.1
> bootstrap4-api:4.5.3-1
> bouncycastle-api:2.18
> checks-api:1.1.1
> command-launcher:1.5
> description-setter:1.10
> display-url-api:2.3.4
> echarts-api:4.9.0-2
> external-monitor-job:1.7
> flot:1.0-SNAPSHOT (private-07/21/2017 10:45-dsl)
> font-awesome-api:5.15.1-1
> greenballs:1.15
> icon-shim:2.0.3
> jackson2-api:2.12.0
> javadoc:1.6
> jdk-tool:1.4
> jquery3-api:3.5.1-2
> junit:1.45
> ldap:1.11
> mailer:1.32.1
> matrix-auth:2.6.4
> matrix-project:1.18
> pam-auth:1.6
> pegdown-formatter:1.3
> plugin-util-api:1.5.0
> popper-api:1.16.0-7
> scm-api:2.6.4
> script-security:1.75
> snakeyaml-api:1.27.0
> structs:1.20
> trilead-api:1.0.4
> windows-slaves:1.7
> workflow-api:2.40
> workflow-step-api:2.23
> Cleaning up locks
> 
> -----------------
> 
> Please try either option 1 or 2 and let me know what happens.
> 
> By the way, you can shutdown Jenkins inside the docker container, and
> restart it, by doing this, inside the container, as root.
> $ service jenkins stop
> $ service jenkins start
> 
> Doing this might clear up the issue with plugins being present in the
> installation directory but not registered with the system.  You probably want
> to do this after installing plugins from the docker container command line.
> 
> You might also try to reset Jenkins from inside the web interface by going to
> "manage Jenkins", "Reload Configuration from Disk".
> 
> I hope this helps.  Let me know what you try, and what the eventual
> outcome is.
> 
> Best of luck!
>  -- Tim
> 
> P.S. If you decide to upgrade the version of Jenkins, make sure you check the
> Jenkins config.xml for items that are needed by Fuego for proper Jenkins
> operations.
> Sometimes, newer Jenkins versions will change the items in the config.xml
> file in a way that is not backwards compatible.  The config.xml that Fuego
> uses when it installs Jenkins into the docker container originally is in:
> fuego/frontend-install/config.xml
> 
> 
> > -----Original Message-----
> > From: Dhinakar Kalyanasundaram/FDS SW /SSIR/Staff Engineer/삼성전자
> > <dhinakar.k@samsung.com>
> >
> > Dear Fuego users,
> >
> >
> >
> > I am using Fuego VERSION=1.5.0 and Jenkins ver. 2.164.2
> >
> >
> >
> > I was trying to install a few Jira plugins to interface from Jenkins.
> >
> > After a while I noticed the below warning message (in many of my
> > plugins) and many of my already installed & setup plugins like ‘Ant’,
> > ‘Structs’, ‘Sidebar Link’, ‘Gerrit Trigger’ etc. were missing even though their
> folders and *.jpi files were still available under ‘/var/lib/jenkins/plugins’
> directory inside docker container.
> >
> >
> >
> > Warning: This plugin requires dependent plugins that require Jenkins
> > 2.249.1 or newer. Jenkins will refuse to load the dependent plugins
> requiring a newer version of Jenkins, and in turn loading this plugin will fail.
> >
> >
> >
> > Now, I see many of my above plugin’s next version listed under ‘Plugin
> Manager’ -> ‘Available’ with the above warning message.
> >
> > For e.g. Structs 1.20 version is already installed but not listed
> > under ‘Plugin Manager’ -> ‘Installed’ page but instead ‘Plugin Manager’ ->
> ‘Available’ is showing the next version of ‘Structs’ with the warning shown
> above (in red italics).
> >
> >
> >
> > I tried removing the newly installed plugins and restart Jenkins & docker
> container multiple times but still the issue was not solved.
> >
> > Any suggestions to fix this?
> >
> > Since I have lot of jobs configured with plugins like ‘Sidebar Link’, ‘Post
> Build Task’ etc. I cannot reinstall or upgrade fuego.
> >
> > Thanks in advance.
> >
> >
> >
> > Regards,
> >
> > Dhinakar
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> <http://ext.samsung.net/mail/ext/v1/external/status/update?userid=dhin
> > akar.k&do=bWFpbElEPTIwMjIwMjE3MTA1NjI3ZXBjYXM1cDFlMjR
> >
> hZDlmZGRjNTA1ZDAyNmRiZmU4NjQ4ZmU4YTVhYSZyZWNpcGllbnRBZGRyZX
> NzPVRpbS5CaXJkQHNvbnkuY29t>

Re: [Fuego] Installed plugins not listed under ‘Plugin Manager’ -> ‘Installed’ page

[Dhinakar Kalyanasundaram/FDS SW /SSIR/Staff Engineer/삼성전자]

Tim Bird,

One issue I noticed when I took a running container and save its current state as an image (docker commit command).
If I create a container from that image I see the Jenkins is still showing the old version (2.164.2 rather than 2.263.1) and the plugin manager page loads with errors. 
I actually wanted to take backup of the current container with upgraded Jenkins & plugins, any suggestions?

Regards,
Dhinakar

> -----Original Message-----
> From: Bird, Tim <Tim.Bird@sony.com>
> Sent: Saturday, February 19, 2022 6:09 AM
> To: Dhinakar Kalyanasundaram/FDS SW /SSIR/Staff Engineer/삼성전자
> <dhinakar.k@samsung.com>; fuego@lists.linuxfoundation.org
> Subject: RE: Installed plugins not listed under ‘Plugin Manager’ -> ‘Installed’
> page
> 
> Dhinakar,
> 
> I'm sorry that you are having problems with the Jenkins plugins.
> This has been a perennial problem for Fuego, trying to keep up with the
> constant churn as the versions of Jenkins and its plugins keeps changing.
> 
> Here is some information and some tips, in the hopes that it will be useful for
> you.
> 
> When Fuego installs, it uses a hardcoded Jenkins version.
> In previous versions of Fuego, we hardcoded frozen versions of the Jenkins
> plugins, so that when the docker container was created, it didn't pick up
> arbitrary plugin versions, that might not be compatible with the version of
> Jenkins used in the Fuego docker image.
> 
> However, the last time we did a Jenkins version upgrade was in Dec 1, 2020.
> At that time, for reasons unknown, we changed the Dockerfile so that the
> plugin versions could float (that is, the latest version of each Jenkins plugin
> would be used).  This code has since been refactored to make native installs
> easier, but the use of non-frozen versions of plugins still remains.
> 
> In any event, I have an old docker container from December of 2020, that has
> the original versions of plugins that were compatible with Jenkins 2.249.3
> (which was the version of Jenkins used in the 1.5.0 release of Fuego).
> 
> Here are the version of plugins  in that container:
> ant:1.11
> antisamy-markup-formatter:2.1
> bootstrap4-api:4.5.3-1
> bouncycastle-api:2.18
> checks-api:1.1.1
> command-launcher:1.5
> description-setter:1.10
> display-url-api:2.3.4
> echarts-api:4.9.0-2
> external-monitor-job:1.7
> flot:1.0-SNAPSHOT (private-07/21/2017 10:45-dsl)
> font-awesome-api:5.15.1-1
> greenballs:1.15
> icon-shim:2.0.3
> jackson2-api:2.12.0
> javadoc:1.6
> jdk-tool:1.4
> jquery3-api:3.5.1-2
> junit:1.45
> ldap:1.11
> mailer:1.32.1
> matrix-auth:2.6.4
> matrix-project:1.18
> pam-auth:1.6
> pegdown-formatter:1.3
> plugin-util-api:1.5.0
> popper-api:1.16.0-7
> scm-api:2.6.4
> script-security:1.75
> snakeyaml-api:1.27.0
> structs:1.20
> trilead-api:1.0.4
> windows-slaves:1.7
> workflow-api:2.40
> workflow-step-api:2.23
> 
> the Fuego install system uses an external script to install plugins (rather than
> doing so inside Jenkins itself).  This script is found inside the fuego docker
> container at: /usr/local/bin/install-plugins.sh
> 
> To use it, you specify a list of plugins to install, on the command line.  You can
> include a version number for a package by including the version number
> following the package name and a colon (e.g. structs:1.20)
> 
> It sounds like some of your plugin operations have upgraded your existing
> plugins, so that now there are dependency problems with the collection of
> plugins on your system.
> 
> There are 2 ways to proceed:  1) Stay with version 2.249.3 of Jenkins, and try
> to revert your plugins to ones that will work with that version of Jenkins, or 2)
> migrate to a newer version of Jenkins.
> 
> Option 2 is, IMHO, fraught with peril. But, depending on the extra modules
> you want to install and your sensitivity to security issues, it may be the best
> route forward.  If the jira plugins you want to install rely on newer modules
> which themselves rely on a newer Jenkins version, then in order to install
> those you may have no choice but to update the version of Jenkins.
> 
> Option 1 also entails some danger (as I have not tried the instructions I am
> about to provide), but it *should* work.  Try uninstalling the plugins that
> have versions that don't match the ones in the above list (that are known to
> be compatible with Jenkins 2.249.3).  Then use install-plugins.sh to re-install
> specific versions of the modules that match the list above.
> 
> In order to run install-plugins.sh, you need to define two environment
> variables, to indicate the Jenkins upload center and the Jenkins plugin
> directory.  These are names JENKINS_UC and REF, respectively.
> 
> $ export JENKINS_UC=https://updates.jenkins.io
> $ export REF=/var/lib/jenkins/plugins
> $ ./install-plugins.sh <plugin1> <plugin2> ...
> 
> To test the script, and get a list of currently installed plugins, you can specify
> to install a non-existent plugin.  Here's what I did, and the output I got back
> from it:
> Note that I get some curl certificate errors, but I think those can be ignored
> for the purposes of this operation.
> 
> --------
> 
> root@timdesk:/usr/local/bin# export
> JENKINS_UC=https://updates.jenkins.io
> root@timdesk:/usr/local/bin# export REF=/var/lib/jenkins/plugins
> root@timdesk:/usr/local/bin# ./install-plugins.sh foo Creating initial locks...
> Analyzing war...
> Registering preinstalled plugins...
> Downloading plugins...
> Downloading plugin: foo from
> https://updates.jenkins.io/download/plugins/foo/latest/foo.hpi
> curl: (60) SSL certificate problem: certificate has expired More details here:
> https://protect2.fireeye.com/v1/url?k=9e437f5d-c1d84794-9e42f412-
> 0cc47a336fae-52a4eafdb6f541c5&q=1&e=9a036cb4-fc47-47cb-a812-
> 14354795baa0&u=https%3A%2F%2Fcurl.haxx.se%2Fdocs%2Fsslcerts.html
> 
> curl performs SSL certificate verification by default, using a "bundle"
>  of Certificate Authority (CA) public keys (CA certs). If the default  bundle file
> isn't adequate, you can specify an alternate file  using the --cacert option.
> If this HTTPS server uses a certificate signed by a CA represented in  the
> bundle, the certificate verification probably failed due to a  problem with the
> certificate (it might be expired, or the name might  not match the domain
> name in the URL).
> If you'd like to turn off curl's verification of the certificate, use  the -k (or --
> insecure) option.
> 23:57:40 Failure (60) Retrying in 1 seconds...
> curl: (60) SSL certificate problem: certificate has expired More details here:
> https://protect2.fireeye.com/v1/url?k=c5b9e4dd-9a22dc14-c5b86f92-
> 0cc47a336fae-d00fe4ef3dd99b9f&q=1&e=9a036cb4-fc47-47cb-a812-
> 14354795baa0&u=https%3A%2F%2Fcurl.haxx.se%2Fdocs%2Fsslcerts.html
> 
> curl performs SSL certificate verification by default, using a "bundle"
>  of Certificate Authority (CA) public keys (CA certs). If the default  bundle file
> isn't adequate, you can specify an alternate file  using the --cacert option.
> If this HTTPS server uses a certificate signed by a CA represented in  the
> bundle, the certificate verification probably failed due to a  problem with the
> certificate (it might be expired, or the name might  not match the domain
> name in the URL).
> If you'd like to turn off curl's verification of the certificate, use  the -k (or --
> insecure) option.
> 23:57:42 Failure (60) Retrying in 1 seconds...
> curl: (60) SSL certificate problem: certificate has expired More details here:
> https://protect2.fireeye.com/v1/url?k=bbfbff80-e460c749-bbfa74cf-
> 0cc47a336fae-4376695a932d0415&q=1&e=9a036cb4-fc47-47cb-a812-
> 14354795baa0&u=https%3A%2F%2Fcurl.haxx.se%2Fdocs%2Fsslcerts.html
> 
> curl performs SSL certificate verification by default, using a "bundle"
>  of Certificate Authority (CA) public keys (CA certs). If the default  bundle file
> isn't adequate, you can specify an alternate file  using the --cacert option.
> If this HTTPS server uses a certificate signed by a CA represented in  the
> bundle, the certificate verification probably failed due to a  problem with the
> certificate (it might be expired, or the name might  not match the domain
> name in the URL).
> If you'd like to turn off curl's verification of the certificate, use  the -k (or --
> insecure) option.
> 23:57:43 Failure (60) Retrying in 1 seconds...
> 23:57:44 Failed in the last attempt (curl -sSfL --connect-timeout 20 --retry 3 --
> retry-delay 0 --retry-max-time 60
> https://updates.jenkins.io/download/plugins/foo/latest/foo.hpi -o
> /var/lib/jenkins/plugins/foo.jpi)
> ./install-plugins.sh: line 63: $3: unbound variable
> 
> WAR bundled plugins:
> 
> 
> Installed plugins:
> ant:1.11
> antisamy-markup-formatter:2.1
> bootstrap4-api:4.5.3-1
> bouncycastle-api:2.18
> checks-api:1.1.1
> command-launcher:1.5
> description-setter:1.10
> display-url-api:2.3.4
> echarts-api:4.9.0-2
> external-monitor-job:1.7
> flot:1.0-SNAPSHOT (private-07/21/2017 10:45-dsl)
> font-awesome-api:5.15.1-1
> greenballs:1.15
> icon-shim:2.0.3
> jackson2-api:2.12.0
> javadoc:1.6
> jdk-tool:1.4
> jquery3-api:3.5.1-2
> junit:1.45
> ldap:1.11
> mailer:1.32.1
> matrix-auth:2.6.4
> matrix-project:1.18
> pam-auth:1.6
> pegdown-formatter:1.3
> plugin-util-api:1.5.0
> popper-api:1.16.0-7
> scm-api:2.6.4
> script-security:1.75
> snakeyaml-api:1.27.0
> structs:1.20
> trilead-api:1.0.4
> windows-slaves:1.7
> workflow-api:2.40
> workflow-step-api:2.23
> Cleaning up locks
> 
> -----------------
> 
> Please try either option 1 or 2 and let me know what happens.
> 
> By the way, you can shutdown Jenkins inside the docker container, and
> restart it, by doing this, inside the container, as root.
> $ service jenkins stop
> $ service jenkins start
> 
> Doing this might clear up the issue with plugins being present in the
> installation directory but not registered with the system.  You probably want
> to do this after installing plugins from the docker container command line.
> 
> You might also try to reset Jenkins from inside the web interface by going to
> "manage Jenkins", "Reload Configuration from Disk".
> 
> I hope this helps.  Let me know what you try, and what the eventual
> outcome is.
> 
> Best of luck!
>  -- Tim
> 
> P.S. If you decide to upgrade the version of Jenkins, make sure you check the
> Jenkins config.xml for items that are needed by Fuego for proper Jenkins
> operations.
> Sometimes, newer Jenkins versions will change the items in the config.xml
> file in a way that is not backwards compatible.  The config.xml that Fuego
> uses when it installs Jenkins into the docker container originally is in:
> fuego/frontend-install/config.xml
> 
> 
> > -----Original Message-----
> > From: Dhinakar Kalyanasundaram/FDS SW /SSIR/Staff Engineer/삼성전자
> > <dhinakar.k@samsung.com>
> >
> > Dear Fuego users,
> >
> >
> >
> > I am using Fuego VERSION=1.5.0 and Jenkins ver. 2.164.2
> >
> >
> >
> > I was trying to install a few Jira plugins to interface from Jenkins.
> >
> > After a while I noticed the below warning message (in many of my
> > plugins) and many of my already installed & setup plugins like ‘Ant’,
> > ‘Structs’, ‘Sidebar Link’, ‘Gerrit Trigger’ etc. were missing even though their
> folders and *.jpi files were still available under ‘/var/lib/jenkins/plugins’
> directory inside docker container.
> >
> >
> >
> > Warning: This plugin requires dependent plugins that require Jenkins
> > 2.249.1 or newer. Jenkins will refuse to load the dependent plugins
> requiring a newer version of Jenkins, and in turn loading this plugin will fail.
> >
> >
> >
> > Now, I see many of my above plugin’s next version listed under ‘Plugin
> Manager’ -> ‘Available’ with the above warning message.
> >
> > For e.g. Structs 1.20 version is already installed but not listed
> > under ‘Plugin Manager’ -> ‘Installed’ page but instead ‘Plugin Manager’ ->
> ‘Available’ is showing the next version of ‘Structs’ with the warning shown
> above (in red italics).
> >
> >
> >
> > I tried removing the newly installed plugins and restart Jenkins & docker
> container multiple times but still the issue was not solved.
> >
> > Any suggestions to fix this?
> >
> > Since I have lot of jobs configured with plugins like ‘Sidebar Link’, ‘Post
> Build Task’ etc. I cannot reinstall or upgrade fuego.
> >
> > Thanks in advance.
> >
> >
> >
> > Regards,
> >
> > Dhinakar
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> <http://ext.samsung.net/mail/ext/v1/external/status/update?userid=dhin
> > akar.k&do=bWFpbElEPTIwMjIwMjE3MTA1NjI3ZXBjYXM1cDFlMjR
> >
> hZDlmZGRjNTA1ZDAyNmRiZmU4NjQ4ZmU4YTVhYSZyZWNpcGllbnRBZGRyZX
> NzPVRpbS5CaXJkQHNvbnkuY29t>

Re: [Fuego] Installed plugins not listed under ‘Plugin Manager’ -> ‘Installed’ page

[Bird, Tim]

Hmmm.  I did the following, without any problems.

I created a new Fuego docker image from scratch (which has 2.249.3 jenkins, and a bunch of plugins with
free-floating version numbers).  [As an aside, this is a bug. The Fuego install really should have 
the plugin versions frozen in the Fuego Jenkins install script, since the Jenkins version is hardcoded.]

I then upgrade the Jenkins core (Jenkins.war) file manually, and addressed plugin issues by
upgrading, removing or downgrading plugins so that they were compatible with Jenkins version 2.319.3.
Note: I do not have a large number of plugins installed.

Then I stopped the container, and did a 'docker commit' into a new image.
Then I ran fuego-host-scripts/docker-create-priviledged-usb-container.sh using that new image,
and ran start.sh with the resulting container.

The new container had the same version of Jenkins, and set of installed plugins (and absence of plugin
errors), as the original Fuego image that I made and upgraded.

I did some testing of  Fuego with Jenkins version 2.319.3, and did not find anything that failed.

However, I did make a quick change to 'ftc' to properly handle the new 'Built-In Node' that 
more recent Jenkins versions use in place of the 'master' node.  This change to ftc is available in the
latest bitbucket repo for fuego-core, and should be completely backwards-compatible with
all prior releases of Fuego and Jenkins.

Based on my (admittedly limited) testing, it appears to be fairly safe to upgrade
the version of Jenkins to a recent one.  However, there are some non-fatal issues
come up.

The Junit plugin was originally installed as version 1.55, but that requires Jenkins 2.321,
which doesn't even show as available in my version of Jenkins.  I downgraded the
Junit plugin to version 1.54.  I also deleted the icon-shim and pegdown-formatter plugins.

I did see an issue with  Jenkins reporting "unreadable old data" for certain jobs.
But I just followed the UI instructions for removing it, and I don't see any issues so far.
Also, the links in the description text for jobs is not displaying as HTML. Rather it
is escaped so that it shows up as quoted text in the job description.  I haven't had
time to investigate this issue yet.

Finally, Jenkins is suggesting that it should be run with Java 11.  I have not
upgraded the JDK for this.

I hope this information helps. 

Let me know if you are able to upgrade your version of Jenkins without
creating a new Fuego docker container from scratch (and salvage your test data.)
There is a way to manually add Jenkins job data for Fuego test runs that were
produced under a previous version of Jenkins, but it is a bit tricky. It was
successful at upgrading data from a previous version of Jenkins to 2.249.3. 
But I haven't tested it with the latest version of Jenkins, so there may be
issues (especially if you are using additional plugins that affect the build
data for a job.)

It involves using a script called 'deorphan-runs.py' in fuego-core/scripts.
Let me know if you are interested in trying this out or learning more about it,
and I can write up some instructions for it.

Good luck.
 -- Tim

> -----Original Message-----
> From: Dhinakar Kalyanasundaram/FDS SW /SSIR/Staff Engineer/삼성전자 <dhinakar.k@samsung.com>
> 
> Tim Bird,
> 
> One issue I noticed when I took a running container and save its current state as an image (docker commit command).
> If I create a container from that image I see the Jenkins is still showing the old version (2.164.2 rather than 2.263.1) and the plugin manager
> page loads with errors.
> I actually wanted to take backup of the current container with upgraded Jenkins & plugins, any suggestions?
> 
> Regards,
> Dhinakar
> 
> > -----Original Message-----
> > From: Bird, Tim <Tim.Bird@sony.com>
> > Sent: Saturday, February 19, 2022 6:09 AM
> > To: Dhinakar Kalyanasundaram/FDS SW /SSIR/Staff Engineer/삼성전자
> > <dhinakar.k@samsung.com>; fuego@lists.linuxfoundation.org
> > Subject: RE: Installed plugins not listed under ‘Plugin Manager’ -> ‘Installed’
> > page
> >
> > Dhinakar,
> >
> > I'm sorry that you are having problems with the Jenkins plugins.
> > This has been a perennial problem for Fuego, trying to keep up with the
> > constant churn as the versions of Jenkins and its plugins keeps changing.
> >
> > Here is some information and some tips, in the hopes that it will be useful for
> > you.
> >
> > When Fuego installs, it uses a hardcoded Jenkins version.
> > In previous versions of Fuego, we hardcoded frozen versions of the Jenkins
> > plugins, so that when the docker container was created, it didn't pick up
> > arbitrary plugin versions, that might not be compatible with the version of
> > Jenkins used in the Fuego docker image.
> >
> > However, the last time we did a Jenkins version upgrade was in Dec 1, 2020.
> > At that time, for reasons unknown, we changed the Dockerfile so that the
> > plugin versions could float (that is, the latest version of each Jenkins plugin
> > would be used).  This code has since been refactored to make native installs
> > easier, but the use of non-frozen versions of plugins still remains.
> >
> > In any event, I have an old docker container from December of 2020, that has
> > the original versions of plugins that were compatible with Jenkins 2.249.3
> > (which was the version of Jenkins used in the 1.5.0 release of Fuego).
> >
> > Here are the version of plugins  in that container:
> > ant:1.11
> > antisamy-markup-formatter:2.1
> > bootstrap4-api:4.5.3-1
> > bouncycastle-api:2.18
> > checks-api:1.1.1
> > command-launcher:1.5
> > description-setter:1.10
> > display-url-api:2.3.4
> > echarts-api:4.9.0-2
> > external-monitor-job:1.7
> > flot:1.0-SNAPSHOT (private-07/21/2017 10:45-dsl)
> > font-awesome-api:5.15.1-1
> > greenballs:1.15
> > icon-shim:2.0.3
> > jackson2-api:2.12.0
> > javadoc:1.6
> > jdk-tool:1.4
> > jquery3-api:3.5.1-2
> > junit:1.45
> > ldap:1.11
> > mailer:1.32.1
> > matrix-auth:2.6.4
> > matrix-project:1.18
> > pam-auth:1.6
> > pegdown-formatter:1.3
> > plugin-util-api:1.5.0
> > popper-api:1.16.0-7
> > scm-api:2.6.4
> > script-security:1.75
> > snakeyaml-api:1.27.0
> > structs:1.20
> > trilead-api:1.0.4
> > windows-slaves:1.7
> > workflow-api:2.40
> > workflow-step-api:2.23
> >
> > the Fuego install system uses an external script to install plugins (rather than
> > doing so inside Jenkins itself).  This script is found inside the fuego docker
> > container at: /usr/local/bin/install-plugins.sh
> >
> > To use it, you specify a list of plugins to install, on the command line.  You can
> > include a version number for a package by including the version number
> > following the package name and a colon (e.g. structs:1.20)
> >
> > It sounds like some of your plugin operations have upgraded your existing
> > plugins, so that now there are dependency problems with the collection of
> > plugins on your system.
> >
> > There are 2 ways to proceed:  1) Stay with version 2.249.3 of Jenkins, and try
> > to revert your plugins to ones that will work with that version of Jenkins, or 2)
> > migrate to a newer version of Jenkins.
> >
> > Option 2 is, IMHO, fraught with peril. But, depending on the extra modules
> > you want to install and your sensitivity to security issues, it may be the best
> > route forward.  If the jira plugins you want to install rely on newer modules
> > which themselves rely on a newer Jenkins version, then in order to install
> > those you may have no choice but to update the version of Jenkins.
> >
> > Option 1 also entails some danger (as I have not tried the instructions I am
> > about to provide), but it *should* work.  Try uninstalling the plugins that
> > have versions that don't match the ones in the above list (that are known to
> > be compatible with Jenkins 2.249.3).  Then use install-plugins.sh to re-install
> > specific versions of the modules that match the list above.
> >
> > In order to run install-plugins.sh, you need to define two environment
> > variables, to indicate the Jenkins upload center and the Jenkins plugin
> > directory.  These are names JENKINS_UC and REF, respectively.
> >
> > $ export JENKINS_UC=https://updates.jenkins.io
> > $ export REF=/var/lib/jenkins/plugins
> > $ ./install-plugins.sh <plugin1> <plugin2> ...
> >
> > To test the script, and get a list of currently installed plugins, you can specify
> > to install a non-existent plugin.  Here's what I did, and the output I got back
> > from it:
> > Note that I get some curl certificate errors, but I think those can be ignored
> > for the purposes of this operation.
> >
> > --------
> >
> > root@timdesk:/usr/local/bin# export
> > JENKINS_UC=https://updates.jenkins.io
> > root@timdesk:/usr/local/bin# export REF=/var/lib/jenkins/plugins
> > root@timdesk:/usr/local/bin# ./install-plugins.sh foo Creating initial locks...
> > Analyzing war...
> > Registering preinstalled plugins...
> > Downloading plugins...
> > Downloading plugin: foo from
> > https://updates.jenkins.io/download/plugins/foo/latest/foo.hpi
> > curl: (60) SSL certificate problem: certificate has expired More details here:
> > https://protect2.fireeye.com/v1/url?k=9e437f5d-c1d84794-9e42f412-
> > 0cc47a336fae-52a4eafdb6f541c5&q=1&e=9a036cb4-fc47-47cb-a812-
> > 14354795baa0&u=https%3A%2F%2Fcurl.haxx.se%2Fdocs%2Fsslcerts.html
> >
> > curl performs SSL certificate verification by default, using a "bundle"
> >  of Certificate Authority (CA) public keys (CA certs). If the default  bundle file
> > isn't adequate, you can specify an alternate file  using the --cacert option.
> > If this HTTPS server uses a certificate signed by a CA represented in  the
> > bundle, the certificate verification probably failed due to a  problem with the
> > certificate (it might be expired, or the name might  not match the domain
> > name in the URL).
> > If you'd like to turn off curl's verification of the certificate, use  the -k (or --
> > insecure) option.
> > 23:57:40 Failure (60) Retrying in 1 seconds...
> > curl: (60) SSL certificate problem: certificate has expired More details here:
> > https://protect2.fireeye.com/v1/url?k=c5b9e4dd-9a22dc14-c5b86f92-
> > 0cc47a336fae-d00fe4ef3dd99b9f&q=1&e=9a036cb4-fc47-47cb-a812-
> > 14354795baa0&u=https%3A%2F%2Fcurl.haxx.se%2Fdocs%2Fsslcerts.html
> >
> > curl performs SSL certificate verification by default, using a "bundle"
> >  of Certificate Authority (CA) public keys (CA certs). If the default  bundle file
> > isn't adequate, you can specify an alternate file  using the --cacert option.
> > If this HTTPS server uses a certificate signed by a CA represented in  the
> > bundle, the certificate verification probably failed due to a  problem with the
> > certificate (it might be expired, or the name might  not match the domain
> > name in the URL).
> > If you'd like to turn off curl's verification of the certificate, use  the -k (or --
> > insecure) option.
> > 23:57:42 Failure (60) Retrying in 1 seconds...
> > curl: (60) SSL certificate problem: certificate has expired More details here:
> > https://protect2.fireeye.com/v1/url?k=bbfbff80-e460c749-bbfa74cf-
> > 0cc47a336fae-4376695a932d0415&q=1&e=9a036cb4-fc47-47cb-a812-
> > 14354795baa0&u=https%3A%2F%2Fcurl.haxx.se%2Fdocs%2Fsslcerts.html
> >
> > curl performs SSL certificate verification by default, using a "bundle"
> >  of Certificate Authority (CA) public keys (CA certs). If the default  bundle file
> > isn't adequate, you can specify an alternate file  using the --cacert option.
> > If this HTTPS server uses a certificate signed by a CA represented in  the
> > bundle, the certificate verification probably failed due to a  problem with the
> > certificate (it might be expired, or the name might  not match the domain
> > name in the URL).
> > If you'd like to turn off curl's verification of the certificate, use  the -k (or --
> > insecure) option.
> > 23:57:43 Failure (60) Retrying in 1 seconds...
> > 23:57:44 Failed in the last attempt (curl -sSfL --connect-timeout 20 --retry 3 --
> > retry-delay 0 --retry-max-time 60
> > https://updates.jenkins.io/download/plugins/foo/latest/foo.hpi -o
> > /var/lib/jenkins/plugins/foo.jpi)
> > ./install-plugins.sh: line 63: $3: unbound variable
> >
> > WAR bundled plugins:
> >
> >
> > Installed plugins:
> > ant:1.11
> > antisamy-markup-formatter:2.1
> > bootstrap4-api:4.5.3-1
> > bouncycastle-api:2.18
> > checks-api:1.1.1
> > command-launcher:1.5
> > description-setter:1.10
> > display-url-api:2.3.4
> > echarts-api:4.9.0-2
> > external-monitor-job:1.7
> > flot:1.0-SNAPSHOT (private-07/21/2017 10:45-dsl)
> > font-awesome-api:5.15.1-1
> > greenballs:1.15
> > icon-shim:2.0.3
> > jackson2-api:2.12.0
> > javadoc:1.6
> > jdk-tool:1.4
> > jquery3-api:3.5.1-2
> > junit:1.45
> > ldap:1.11
> > mailer:1.32.1
> > matrix-auth:2.6.4
> > matrix-project:1.18
> > pam-auth:1.6
> > pegdown-formatter:1.3
> > plugin-util-api:1.5.0
> > popper-api:1.16.0-7
> > scm-api:2.6.4
> > script-security:1.75
> > snakeyaml-api:1.27.0
> > structs:1.20
> > trilead-api:1.0.4
> > windows-slaves:1.7
> > workflow-api:2.40
> > workflow-step-api:2.23
> > Cleaning up locks
> >
> > -----------------
> >
> > Please try either option 1 or 2 and let me know what happens.
> >
> > By the way, you can shutdown Jenkins inside the docker container, and
> > restart it, by doing this, inside the container, as root.
> > $ service jenkins stop
> > $ service jenkins start
> >
> > Doing this might clear up the issue with plugins being present in the
> > installation directory but not registered with the system.  You probably want
> > to do this after installing plugins from the docker container command line.
> >
> > You might also try to reset Jenkins from inside the web interface by going to
> > "manage Jenkins", "Reload Configuration from Disk".
> >
> > I hope this helps.  Let me know what you try, and what the eventual
> > outcome is.
> >
> > Best of luck!
> >  -- Tim
> >
> > P.S. If you decide to upgrade the version of Jenkins, make sure you check the
> > Jenkins config.xml for items that are needed by Fuego for proper Jenkins
> > operations.
> > Sometimes, newer Jenkins versions will change the items in the config.xml
> > file in a way that is not backwards compatible.  The config.xml that Fuego
> > uses when it installs Jenkins into the docker container originally is in:
> > fuego/frontend-install/config.xml
> >
> >
> > > -----Original Message-----
> > > From: Dhinakar Kalyanasundaram/FDS SW /SSIR/Staff Engineer/삼성전자
> > > <dhinakar.k@samsung.com>
> > >
> > > Dear Fuego users,
> > >
> > >
> > >
> > > I am using Fuego VERSION=1.5.0 and Jenkins ver. 2.164.2
> > >
> > >
> > >
> > > I was trying to install a few Jira plugins to interface from Jenkins.
> > >
> > > After a while I noticed the below warning message (in many of my
> > > plugins) and many of my already installed & setup plugins like ‘Ant’,
> > > ‘Structs’, ‘Sidebar Link’, ‘Gerrit Trigger’ etc. were missing even though their
> > folders and *.jpi files were still available under ‘/var/lib/jenkins/plugins’
> > directory inside docker container.
> > >
> > >
> > >
> > > Warning: This plugin requires dependent plugins that require Jenkins
> > > 2.249.1 or newer. Jenkins will refuse to load the dependent plugins
> > requiring a newer version of Jenkins, and in turn loading this plugin will fail.
> > >
> > >
> > >
> > > Now, I see many of my above plugin’s next version listed under ‘Plugin
> > Manager’ -> ‘Available’ with the above warning message.
> > >
> > > For e.g. Structs 1.20 version is already installed but not listed
> > > under ‘Plugin Manager’ -> ‘Installed’ page but instead ‘Plugin Manager’ ->
> > ‘Available’ is showing the next version of ‘Structs’ with the warning shown
> > above (in red italics).
> > >
> > >
> > >
> > > I tried removing the newly installed plugins and restart Jenkins & docker
> > container multiple times but still the issue was not solved.
> > >
> > > Any suggestions to fix this?
> > >
> > > Since I have lot of jobs configured with plugins like ‘Sidebar Link’, ‘Post
> > Build Task’ etc. I cannot reinstall or upgrade fuego.
> > >
> > > Thanks in advance.
> > >
> > >
> > >
> > > Regards,
> > >
> > > Dhinakar
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > <http://ext.samsung.net/mail/ext/v1/external/status/update?userid=dhin
> > > akar.k&do=bWFpbElEPTIwMjIwMjE3MTA1NjI3ZXBjYXM1cDFlMjR
> > >
> > hZDlmZGRjNTA1ZDAyNmRiZmU4NjQ4ZmU4YTVhYSZyZWNpcGllbnRBZGRyZX
> > NzPVRpbS5CaXJkQHNvbnkuY29t>
> 

Re: [Fuego] Installed plugins not listed under ‘Plugin Manager’ -> ‘Installed’ page

[Dhinakar Kalyanasundaram/FDS SW /SSIR/Staff Engineer/삼성전자]

Hi Tim,

Thanks a lot for your reply.
Sorry for the delay in my reply as I was on vacation.
 
I exactly did the same steps like you until the below one.

....
....
> Then I ran fuego-host-scripts/docker-create-priviledged-usb-container.sh
> using that new image, and ran start.sh with the resulting container.

Then when I started the container it showed me the older Jenkins version only.
My docker container is under default /var/lib/docker path and 'fuego' folder is under '/home/dhinakar/fuego' path.
So all my project data are under '/home/dhinakar/fuego' and I started the newly created container from this folder.
I created a new container but I am using the same 'fuego' home folder only.
Does it really matter, how do you do it usually?

Regards,
Dhinakar

One thing I want to confirm is I am using the
> -----Original Message-----
> From: Bird, Tim <Tim.Bird@sony.com>
> Sent: Thursday, February 24, 2022 5:59 AM
> To: Dhinakar Kalyanasundaram/FDS SW /SSIR/Staff Engineer/삼성전자
> <dhinakar.k@samsung.com>; fuego@lists.linuxfoundation.org
> Subject: RE: Installed plugins not listed under ‘Plugin Manager’ -> ‘Installed’
> page
> 
> Hmmm.  I did the following, without any problems.
> 
> I created a new Fuego docker image from scratch (which has 2.249.3 jenkins,
> and a bunch of plugins with free-floating version numbers).  [As an aside, this
> is a bug. The Fuego install really should have the plugin versions frozen in the
> Fuego Jenkins install script, since the Jenkins version is hardcoded.]
> 
> I then upgrade the Jenkins core (Jenkins.war) file manually, and addressed
> plugin issues by upgrading, removing or downgrading plugins so that they
> were compatible with Jenkins version 2.319.3.
> Note: I do not have a large number of plugins installed.
> 
> Then I stopped the container, and did a 'docker commit' into a new image.
> Then I ran fuego-host-scripts/docker-create-priviledged-usb-container.sh
> using that new image, and ran start.sh with the resulting container.
> 
> The new container had the same version of Jenkins, and set of installed
> plugins (and absence of plugin errors), as the original Fuego image that I
> made and upgraded.
> 
> I did some testing of  Fuego with Jenkins version 2.319.3, and did not find
> anything that failed.
> 
> However, I did make a quick change to 'ftc' to properly handle the new 'Built-
> In Node' that more recent Jenkins versions use in place of the 'master' node.
> This change to ftc is available in the latest bitbucket repo for fuego-core, and
> should be completely backwards-compatible with all prior releases of Fuego
> and Jenkins.
> 
> Based on my (admittedly limited) testing, it appears to be fairly safe to
> upgrade the version of Jenkins to a recent one.  However, there are some
> non-fatal issues come up.
> 
> The Junit plugin was originally installed as version 1.55, but that requires
> Jenkins 2.321, which doesn't even show as available in my version of Jenkins.
> I downgraded the Junit plugin to version 1.54.  I also deleted the icon-shim
> and pegdown-formatter plugins.
> 
> I did see an issue with  Jenkins reporting "unreadable old data" for certain
> jobs.
> But I just followed the UI instructions for removing it, and I don't see any
> issues so far.
> Also, the links in the description text for jobs is not displaying as HTML.
> Rather it is escaped so that it shows up as quoted text in the job description.
> I haven't had time to investigate this issue yet.
> 
> Finally, Jenkins is suggesting that it should be run with Java 11.  I have not
> upgraded the JDK for this.
> 
> I hope this information helps.
> 
> Let me know if you are able to upgrade your version of Jenkins without
> creating a new Fuego docker container from scratch (and salvage your test
> data.) There is a way to manually add Jenkins job data for Fuego test runs
> that were produced under a previous version of Jenkins, but it is a bit tricky.
> It was successful at upgrading data from a previous version of Jenkins to
> 2.249.3.
> But I haven't tested it with the latest version of Jenkins, so there may be
> issues (especially if you are using additional plugins that affect the build data
> for a job.)
> 
> It involves using a script called 'deorphan-runs.py' in fuego-core/scripts.
> Let me know if you are interested in trying this out or learning more about it,
> and I can write up some instructions for it.
> 
> Good luck.
>  -- Tim
> 
> > -----Original Message-----
> > From: Dhinakar Kalyanasundaram/FDS SW /SSIR/Staff Engineer/삼성전자
> > <dhinakar.k@samsung.com>
> >
> > Tim Bird,
> >
> > One issue I noticed when I took a running container and save its current
> state as an image (docker commit command).
> > If I create a container from that image I see the Jenkins is still
> > showing the old version (2.164.2 rather than 2.263.1) and the plugin
> manager page loads with errors.
> > I actually wanted to take backup of the current container with upgraded
> Jenkins & plugins, any suggestions?
> >
> > Regards,
> > Dhinakar
> >
> > > -----Original Message-----
> > > From: Bird, Tim <Tim.Bird@sony.com>
> > > Sent: Saturday, February 19, 2022 6:09 AM
> > > To: Dhinakar Kalyanasundaram/FDS SW /SSIR/Staff Engineer/삼성전자
> > > <dhinakar.k@samsung.com>; fuego@lists.linuxfoundation.org
> > > Subject: RE: Installed plugins not listed under ‘Plugin Manager’ ->
> ‘Installed’
> > > page
> > >
> > > Dhinakar,
> > >
> > > I'm sorry that you are having problems with the Jenkins plugins.
> > > This has been a perennial problem for Fuego, trying to keep up with
> > > the constant churn as the versions of Jenkins and its plugins keeps
> changing.
> > >
> > > Here is some information and some tips, in the hopes that it will be
> > > useful for you.
> > >
> > > When Fuego installs, it uses a hardcoded Jenkins version.
> > > In previous versions of Fuego, we hardcoded frozen versions of the
> > > Jenkins plugins, so that when the docker container was created, it
> > > didn't pick up arbitrary plugin versions, that might not be
> > > compatible with the version of Jenkins used in the Fuego docker image.
> > >
> > > However, the last time we did a Jenkins version upgrade was in Dec 1,
> 2020.
> > > At that time, for reasons unknown, we changed the Dockerfile so that
> > > the plugin versions could float (that is, the latest version of each
> > > Jenkins plugin would be used).  This code has since been refactored
> > > to make native installs easier, but the use of non-frozen versions of
> plugins still remains.
> > >
> > > In any event, I have an old docker container from December of 2020,
> > > that has the original versions of plugins that were compatible with
> > > Jenkins 2.249.3 (which was the version of Jenkins used in the 1.5.0
> release of Fuego).
> > >
> > > Here are the version of plugins  in that container:
> > > ant:1.11
> > > antisamy-markup-formatter:2.1
> > > bootstrap4-api:4.5.3-1
> > > bouncycastle-api:2.18
> > > checks-api:1.1.1
> > > command-launcher:1.5
> > > description-setter:1.10
> > > display-url-api:2.3.4
> > > echarts-api:4.9.0-2
> > > external-monitor-job:1.7
> > > flot:1.0-SNAPSHOT (private-07/21/2017 10:45-dsl)
> > > font-awesome-api:5.15.1-1
> > > greenballs:1.15
> > > icon-shim:2.0.3
> > > jackson2-api:2.12.0
> > > javadoc:1.6
> > > jdk-tool:1.4
> > > jquery3-api:3.5.1-2
> > > junit:1.45
> > > ldap:1.11
> > > mailer:1.32.1
> > > matrix-auth:2.6.4
> > > matrix-project:1.18
> > > pam-auth:1.6
> > > pegdown-formatter:1.3
> > > plugin-util-api:1.5.0
> > > popper-api:1.16.0-7
> > > scm-api:2.6.4
> > > script-security:1.75
> > > snakeyaml-api:1.27.0
> > > structs:1.20
> > > trilead-api:1.0.4
> > > windows-slaves:1.7
> > > workflow-api:2.40
> > > workflow-step-api:2.23
> > >
> > > the Fuego install system uses an external script to install plugins
> > > (rather than doing so inside Jenkins itself).  This script is found
> > > inside the fuego docker container at:
> > > /usr/local/bin/install-plugins.sh
> > >
> > > To use it, you specify a list of plugins to install, on the command
> > > line.  You can include a version number for a package by including
> > > the version number following the package name and a colon (e.g.
> > > structs:1.20)
> > >
> > > It sounds like some of your plugin operations have upgraded your
> > > existing plugins, so that now there are dependency problems with the
> > > collection of plugins on your system.
> > >
> > > There are 2 ways to proceed:  1) Stay with version 2.249.3 of
> > > Jenkins, and try to revert your plugins to ones that will work with
> > > that version of Jenkins, or 2) migrate to a newer version of Jenkins.
> > >
> > > Option 2 is, IMHO, fraught with peril. But, depending on the extra
> > > modules you want to install and your sensitivity to security issues,
> > > it may be the best route forward.  If the jira plugins you want to
> > > install rely on newer modules which themselves rely on a newer
> > > Jenkins version, then in order to install those you may have no choice but
> to update the version of Jenkins.
> > >
> > > Option 1 also entails some danger (as I have not tried the
> > > instructions I am about to provide), but it *should* work.  Try
> > > uninstalling the plugins that have versions that don't match the
> > > ones in the above list (that are known to be compatible with Jenkins
> > > 2.249.3).  Then use install-plugins.sh to re-install specific versions of the
> modules that match the list above.
> > >
> > > In order to run install-plugins.sh, you need to define two
> > > environment variables, to indicate the Jenkins upload center and the
> > > Jenkins plugin directory.  These are names JENKINS_UC and REF,
> respectively.
> > >
> > > $ export JENKINS_UC=https://updates.jenkins.io
> > > $ export REF=/var/lib/jenkins/plugins $ ./install-plugins.sh
> > > <plugin1> <plugin2> ...
> > >
> > > To test the script, and get a list of currently installed plugins,
> > > you can specify to install a non-existent plugin.  Here's what I
> > > did, and the output I got back from it:
> > > Note that I get some curl certificate errors, but I think those can
> > > be ignored for the purposes of this operation.
> > >
> > > --------
> > >
> > > root@timdesk:/usr/local/bin# export
> > > JENKINS_UC=https://updates.jenkins.io
> > > root@timdesk:/usr/local/bin# export REF=/var/lib/jenkins/plugins
> > > root@timdesk:/usr/local/bin# ./install-plugins.sh foo Creating initial
> locks...
> > > Analyzing war...
> > > Registering preinstalled plugins...
> > > Downloading plugins...
> > > Downloading plugin: foo from
> > > https://updates.jenkins.io/download/plugins/foo/latest/foo.hpi
> > > curl: (60) SSL certificate problem: certificate has expired More details
> here:
> > > https://protect2.fireeye.com/v1/url?k=9e437f5d-c1d84794-9e42f412-
> > > 0cc47a336fae-52a4eafdb6f541c5&q=1&e=9a036cb4-fc47-47cb-a812-
> > > 14354795baa0&u=https%3A%2F%2Fcurl.haxx.se%2Fdocs%2Fsslcerts.html
> > >
> > > curl performs SSL certificate verification by default, using a "bundle"
> > >  of Certificate Authority (CA) public keys (CA certs). If the
> > > default  bundle file isn't adequate, you can specify an alternate file  using
> the --cacert option.
> > > If this HTTPS server uses a certificate signed by a CA represented
> > > in  the bundle, the certificate verification probably failed due to
> > > a  problem with the certificate (it might be expired, or the name
> > > might  not match the domain name in the URL).
> > > If you'd like to turn off curl's verification of the certificate,
> > > use  the -k (or --
> > > insecure) option.
> > > 23:57:40 Failure (60) Retrying in 1 seconds...
> > > curl: (60) SSL certificate problem: certificate has expired More details
> here:
> > > https://protect2.fireeye.com/v1/url?k=c5b9e4dd-9a22dc14-c5b86f92-
> > > 0cc47a336fae-d00fe4ef3dd99b9f&q=1&e=9a036cb4-fc47-47cb-a812-
> > > 14354795baa0&u=https%3A%2F%2Fcurl.haxx.se%2Fdocs%2Fsslcerts.html
> > >
> > > curl performs SSL certificate verification by default, using a "bundle"
> > >  of Certificate Authority (CA) public keys (CA certs). If the
> > > default  bundle file isn't adequate, you can specify an alternate file  using
> the --cacert option.
> > > If this HTTPS server uses a certificate signed by a CA represented
> > > in  the bundle, the certificate verification probably failed due to
> > > a  problem with the certificate (it might be expired, or the name
> > > might  not match the domain name in the URL).
> > > If you'd like to turn off curl's verification of the certificate,
> > > use  the -k (or --
> > > insecure) option.
> > > 23:57:42 Failure (60) Retrying in 1 seconds...
> > > curl: (60) SSL certificate problem: certificate has expired More details
> here:
> > > https://protect2.fireeye.com/v1/url?k=bbfbff80-e460c749-bbfa74cf-
> > > 0cc47a336fae-4376695a932d0415&q=1&e=9a036cb4-fc47-47cb-a812-
> > > 14354795baa0&u=https%3A%2F%2Fcurl.haxx.se%2Fdocs%2Fsslcerts.html
> > >
> > > curl performs SSL certificate verification by default, using a "bundle"
> > >  of Certificate Authority (CA) public keys (CA certs). If the
> > > default  bundle file isn't adequate, you can specify an alternate file  using
> the --cacert option.
> > > If this HTTPS server uses a certificate signed by a CA represented
> > > in  the bundle, the certificate verification probably failed due to
> > > a  problem with the certificate (it might be expired, or the name
> > > might  not match the domain name in the URL).
> > > If you'd like to turn off curl's verification of the certificate,
> > > use  the -k (or --
> > > insecure) option.
> > > 23:57:43 Failure (60) Retrying in 1 seconds...
> > > 23:57:44 Failed in the last attempt (curl -sSfL --connect-timeout 20
> > > --retry 3 -- retry-delay 0 --retry-max-time 60
> > > https://updates.jenkins.io/download/plugins/foo/latest/foo.hpi -o
> > > /var/lib/jenkins/plugins/foo.jpi)
> > > ./install-plugins.sh: line 63: $3: unbound variable
> > >
> > > WAR bundled plugins:
> > >
> > >
> > > Installed plugins:
> > > ant:1.11
> > > antisamy-markup-formatter:2.1
> > > bootstrap4-api:4.5.3-1
> > > bouncycastle-api:2.18
> > > checks-api:1.1.1
> > > command-launcher:1.5
> > > description-setter:1.10
> > > display-url-api:2.3.4
> > > echarts-api:4.9.0-2
> > > external-monitor-job:1.7
> > > flot:1.0-SNAPSHOT (private-07/21/2017 10:45-dsl)
> > > font-awesome-api:5.15.1-1
> > > greenballs:1.15
> > > icon-shim:2.0.3
> > > jackson2-api:2.12.0
> > > javadoc:1.6
> > > jdk-tool:1.4
> > > jquery3-api:3.5.1-2
> > > junit:1.45
> > > ldap:1.11
> > > mailer:1.32.1
> > > matrix-auth:2.6.4
> > > matrix-project:1.18
> > > pam-auth:1.6
> > > pegdown-formatter:1.3
> > > plugin-util-api:1.5.0
> > > popper-api:1.16.0-7
> > > scm-api:2.6.4
> > > script-security:1.75
> > > snakeyaml-api:1.27.0
> > > structs:1.20
> > > trilead-api:1.0.4
> > > windows-slaves:1.7
> > > workflow-api:2.40
> > > workflow-step-api:2.23
> > > Cleaning up locks
> > >
> > > -----------------
> > >
> > > Please try either option 1 or 2 and let me know what happens.
> > >
> > > By the way, you can shutdown Jenkins inside the docker container,
> > > and restart it, by doing this, inside the container, as root.
> > > $ service jenkins stop
> > > $ service jenkins start
> > >
> > > Doing this might clear up the issue with plugins being present in
> > > the installation directory but not registered with the system.  You
> > > probably want to do this after installing plugins from the docker container
> command line.
> > >
> > > You might also try to reset Jenkins from inside the web interface by
> > > going to "manage Jenkins", "Reload Configuration from Disk".
> > >
> > > I hope this helps.  Let me know what you try, and what the eventual
> > > outcome is.
> > >
> > > Best of luck!
> > >  -- Tim
> > >
> > > P.S. If you decide to upgrade the version of Jenkins, make sure you
> > > check the Jenkins config.xml for items that are needed by Fuego for
> > > proper Jenkins operations.
> > > Sometimes, newer Jenkins versions will change the items in the
> > > config.xml file in a way that is not backwards compatible.  The
> > > config.xml that Fuego uses when it installs Jenkins into the docker
> container originally is in:
> > > fuego/frontend-install/config.xml
> > >
> > >
> > > > -----Original Message-----
> > > > From: Dhinakar Kalyanasundaram/FDS SW /SSIR/Staff
> Engineer/삼성전자
> > > > <dhinakar.k@samsung.com>
> > > >
> > > > Dear Fuego users,
> > > >
> > > >
> > > >
> > > > I am using Fuego VERSION=1.5.0 and Jenkins ver. 2.164.2
> > > >
> > > >
> > > >
> > > > I was trying to install a few Jira plugins to interface from Jenkins.
> > > >
> > > > After a while I noticed the below warning message (in many of my
> > > > plugins) and many of my already installed & setup plugins like
> > > > ‘Ant’, ‘Structs’, ‘Sidebar Link’, ‘Gerrit Trigger’ etc. were
> > > > missing even though their
> > > folders and *.jpi files were still available under ‘/var/lib/jenkins/plugins’
> > > directory inside docker container.
> > > >
> > > >
> > > >
> > > > Warning: This plugin requires dependent plugins that require
> > > > Jenkins
> > > > 2.249.1 or newer. Jenkins will refuse to load the dependent
> > > > plugins
> > > requiring a newer version of Jenkins, and in turn loading this plugin will
> fail.
> > > >
> > > >
> > > >
> > > > Now, I see many of my above plugin’s next version listed under
> > > > ‘Plugin
> > > Manager’ -> ‘Available’ with the above warning message.
> > > >
> > > > For e.g. Structs 1.20 version is already installed but not listed
> > > > under ‘Plugin Manager’ -> ‘Installed’ page but instead ‘Plugin
> > > > Manager’ ->
> > > ‘Available’ is showing the next version of ‘Structs’ with the
> > > warning shown above (in red italics).
> > > >
> > > >
> > > >
> > > > I tried removing the newly installed plugins and restart Jenkins &
> > > > docker
> > > container multiple times but still the issue was not solved.
> > > >
> > > > Any suggestions to fix this?
> > > >
> > > > Since I have lot of jobs configured with plugins like ‘Sidebar
> > > > Link’, ‘Post
> > > Build Task’ etc. I cannot reinstall or upgrade fuego.
> > > >
> > > > Thanks in advance.
> > > >
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Dhinakar
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> <http://ext.samsung.net/mail/ext/v1/external/status/update?userid=dh
> > > in
> > > > akar.k&do=bWFpbElEPTIwMjIwMjE3MTA1NjI3ZXBjYXM1cDFlMjR
> > > >
> > >
> hZDlmZGRjNTA1ZDAyNmRiZmU4NjQ4ZmU4YTVhYSZyZWNpcGllbnRBZGRyZX
> > > NzPVRpbS5CaXJkQHNvbnkuY29t>
> >