2.60.3-cb-1Provide support for self-signed certificates
Provide build agent template information in the build logs
Provided the ability to customize the timeouts for the various internal CJE sub-systems
Fixed an issue where extra instance storage for pertinent AWS instances were not being used
Fixed an issue where CJE upgrade might abort because it falsely detected the presence of an inactive worker machine
Fixed an issue where Support bundle logs from VMs cannot be retrieved if hostnames cannot be resolved
Fixed an issue with Palace sub-system running out of memory
Fixed an issue where the Build Analytics tab becomes default view, instead of the Masters tab.
Fixed an issue where using ! expression in node name causes pipeline to fail
Optimized log rotation policy
Fixed an issue with the cje status worker-* CLI when it is run on a CJE cluster that has been installed on an internal network
Fixed the issue where the 'cje run list-resources' failed to perform correctly the OpenStack platform
If you enter an invalid Managed Master image location under the Manage Jenkins page on Operations Center, when deploying the new instance, the log window will only show that it's attempting to deploy and will not give any further feedback. Correct the image location to resolve this.
CJE allows you to enable using one-shot executors. These provide slightly faster provisioning of the executors. However, the current implementation of one-shot executors doesn't support pipeline resumption.
CJE doesn't support installing the Palace Cloud Plugin into masters that are not managed by CloudBees Jenkins Enterprise.
The alert There was an error reporting analytics data links to an invalid URL within the cluster. You can access this by selecting the Manage Jenkins link on the left side of the page.
Managed Masters may appear to be not accessible when Operations Center is being upgraded. This issue occurs when the internal application router is being updated and is a temporary condition.
When deleting a Managed Master, the data associated with the master is retained in a backup snapshot used for recovery purposes. If you add a new master with the same name, it will recover the data from the snapshot and re-create it.
A CJE cluster-recover fails if its subnet is created in another availability zone.
When using the operation cluster-recover, it is simpler to keep the cluster in the same AWS availability zone (AZ).
To workaround, and recover in a different availability zone, you will need manually edit the .dna/project.config file and update the availability_zone property for each machine instance prior to starting the recovery operation.
A CJE Admin can change the JNLP port on the Operations Center UI, however, this is not a best practice as this is set dynamically by CJE on startup.
CJE can fail to upgrade when a worker was incompletely set up.
Under some circumstances, a cje prepare worker-add operation can fail. The typical case (on Amazon) is when the user's MFA code is incorrectly entered when prompted after the "apply" step. This results in a worker that is incompletely set up and the instance isn't started.
When this condition exists, an upgrade will fail.
To resolve this, use the cje prepare worker-remove on the partially created workers, and then restart the upgrade process.