2.176.4-cb-3Upgraded Credentials Plugin from 2.2.0 to 2.3.0. Global and folder credentials were too broadly accessible for certain pipeline use cases, and user credentials were not well supported by pipelines. User-scoped credentials associate credentials to users with manual unlocking of these credentials so that sensitive credentials can be isolated to trusted phases of pipelines and to trusted users.
The Pipeline Input Step plugin has been updated to support the new Credentials API for binding credentials parameters to builds and supports user credentials as well as credential parameter name shadowing.
The Pipeline Stage View plugin now supports Internet Explorer 11.
Upgraded CloudBees Backup Plugin from 3.38.13 to 3.38.14. The Backup plugin included extraneous libraries that increased the artifact size unnecessarily. With this fix, we now exclude unnecessary dependencies from the httpclient artifact maven dependency.
The Backup plugin had an old version of common-compress as a dependency. With this fix, the Backup plugin has upgraded this out of date dependency.
Users using plugin catalogs with external Maven2 repository layout for plugin resolution were not able to push the plugin catalog to a client master, and were receiving class not found errors. With this fix, we now use the proper classloader to load the involved classes.
Configuration snippets from Operations Center could be applied before Jenkins was fully loaded, leading to loss of configuration. With this fix, configuration snippets are no longer applied until we are sure that the Jenkins configuration has been deserialized
When a master is disconnected from Operations Center, some but not all configuration snippets would be removed. With this fix, configuration snippets are no longer removed when a master is removed from an Operations Center cluster, so that the existing configuration can be tweaked or removed as desired.
When the Operations Center authorization strategy was changed from the CloudBees Role Based Authorization strategy to something else, Team masters would still have a copy of the outdated configuration. This situation would allow users who had previously been granted Administrator permissions via the RBAC configuration to still have the Administrator permission even though they should no longer have this level of access. With this fix, if the authorization strategy in Operations Center is not CloudBees Role Based Authorization strategy, then the obsolete configuration will be removed from masters.
In Operation Center, the Managed Master contextual menu showed actions that the user was not allowed to execute, so when they would try, they would get an error message. With this fix, the Managed Master contextual menu no shows only the actions that the user is allowed to execute.
Client Master instances could not start if users used a configuration bundle without plugins and/or plugin catalogs. With this fix, the plugins list and plugin catalog fields are optional.
Using the Move/Copy/Promote option to move or delete a managed master for the second time was failing because the log file in the managed master's old location was not properly closed before moving or deleting the files. With this fix, the log file in the managed master's old location is closed before the master is moved or deleted and using Move/Copy/Promote works as expected.
The administrative monitor always warned about new versions of the configuration bundle if the client master had a link file. With this fix, the HttpLoader now has its own implementation of getUpstreamVersion, so the configuration is updated correctly.
We fixed a regression in RSS and Atom feeds where an uninitialized variable resulted in partial entries.
Concurrent executions of the Pipeline Template Catalog CLI commands could cause erroneous behavior. With this fix, the Pipeline Template Catalog CLI commands are now synchronized with respect to other operations that modify Pipeline Template Catalogs so that catalogs are not modified concurrently.
The updateInterval value for Pipeline Template Catalogs could take on values not supported by the UI when using the Pipeline Template Catalog CLI commands. With this fix, the updateInterval value for Pipeline Template Catalogs is now normalized to the next largest (or equal) value that is supported by the UI when using the pipeline-template-catalogs CLI command.
In some cases (as in abruptly disconnected browsers) the Pub-Sub “light” plugin was not informed and was unable to store/send messages to some destinations, so some queues kept growing because of retries. With this fix, we have added some TTL (time to live) for the messages queue to discard them after a certain time if not successfully sent.
Modifications to the JIRA configuration completed in the UI were not persisted on disk, only kept in memory. Therefore, after jenkins was restarted, the settings were lost. With this fix, the JIRA configuration are correctly saved on disk.
Pipelines could not be restarted from checkpoints in version 2.2 of CloudBees Pipeline Stage View Extensions. With this fix, pipelines are now able to be restarted from checkpoints.
When configuring new multibranch pipeline projects to build projects hosted on GitHub Enterprise servers, there was a bug that caused the apiUri field in that job's config.xml file to be incorrectly set to point to github.com. With this fix, we no longer reset the apiUri field if it is already set. Instead, it retains its correctly calculated value of github-enterprise-server/api/v3.
Using the dir step inside of the withContainer step did not work correctly when running Docker 17.12 or older. With this fix, the dir step should now work correctly with older versions of Docker.
The dockerfile.build and image.inside utilities in Docker Pipeline Plugin were very sensitive to the syntax used in the Dockerfile. For example, Dockerfile features such as multi-stage builds were not supported, and changing the case of keywords in the Dockerfile could cause the utilities to fail. With this fix, the Pipeline steps that attempted to parse Dockerfiles to track fingerprints of the images that were being used (dockerFingerprintFrom and dockerFingerprintRun) have been deprecated, and are no longer called as part of docker.build or image.inside.
If you are using the CloudBees Docker Traceability Plugin, which is the only known consumer of these fingerprints, you will need to explicitly call dockerFingerprintFrom and dockerFingerprintRun if you want to maintain the previous behavior.