Continuous Delivery for PE known issues

Sections

These are the known issues for the Continuous Delivery for PE 3.x release series.

Because of a change to the location of reports in PE 2019.7 and 2019.8, clicking View Report from the Nodes page does not correctly direct you to the appropriate report in the PE console.

Nodes page unavailable if SSL is enabled

If SSL is enabled on your Continuous Delivery for PE installation, the Nodes page is currently unavailable.

If any integrated PE instance is unresponsive, no data is shown on the Nodes page

If a PE server is unresponsive when queried by the service that displays node data on the Nodes page, the query times out and no data is returned, even if other integrated PE instances are present and responsive.

The puppet_agent module cannot be used to upgrade Puppet agents on job hardware

Due to the fact that Continuous Delivery for PE job hardware nodes are classified as PE infrastructure nodes, the puppet_agent module cannot be used to successfully upgrade Puppet agents running on job hardware. To upgrade the Puppet agent on a job hardware node, use the agent upgrade script.

A PE instance cannot be integrated if dns_alt_names is not set on the master certificate

If the Puppet master certificate for your PE instance does not have dns_alt_names configured, attempting to integrate the instance with Continuous Delivery for PE fails with a We could not successfully validate the provided credentials against the Code Manager Service error. The master certificate must be regenerated before PE is integrated with Continuous Delivery for PE. For instructions, see Regenerate master certificates in the PE documentation.

Duplicate custom deployment policies are shown in the web UI

When editing a deployment in the web UI after updating a custom deployment policy, the names of custom deployment policies are shown twice.

Impact analysis for Hiera data is unavailable when using PE 2019.7

If you are using PE version 2019.7 with Continuous Delivery for PE version 3.7.1 or earlier, impact analysis of Hiera data changes is unavailable. To resolve this issue, upgrade your Continuous Delivery for PE installation to version 3.8.0 or later.

Impact analysis report inaccuracies when using PE 2019.2 and earlier versions

Due to an r10k issue, impact analysis reports generated using PE 2019.2 and earlier versions might include nonexistent module changes and calculations of the impact of those nonexistent changes. The underlying issue was resolved in r10k version 3.4.0 and included in PE 2019.3 and all newer versions.

Unable to add Amazon S3 credentials when disk storage is configured

If you install Continuous Delivery for PE from the PE console (which automatically sets up disk storage), you might see an error if you attempt to add Amazon S3 credentials in the web UI. To work around this issue, sign into the root console and add your Amazon S3 credentials on the Storage tab of the Settings page.

Jobs fail when using chained SSL certificates on Windows

If you are using Continuous Delivery for PE with SSL configured to use chained certificates, attempts to run jobs on Puppet agent-based Windows job hardware will fail.

Rerun job control is unresponsive after two hours for Bitbucket Cloud users

This known issue applies only to Bitbucket Cloud users. When a pipeline run for a control repo or module was completed more than two hours ago, clicking the Rerun Job button results in an Authentication failed error.

Purging unmanaged firewall rules with the puppetlabs-firewall module deletes required firewall settings

If your Continuous Delivery for PE node uses the puppetlabs-firewall module to manage its firewall settings, and if a resources { 'firewall': purge => true } metaparameter is set on the node or at a higher level, Puppet will remove the unmanaged Docker firewall rules Continuous Delivery for PE requires to run successfully. To work around this issue, disable unmanaged firewall rule purging for your Continuous Delivery for PE node by changing the metaparameter to resources { 'firewall': purge => false }.

Deployments for module regex branches are not supported when managing pipelines as code in versions 3.0 and 3.1

In Continuous Delivery for PE versions prior to 3.2.0, deployments using the feature branch deployment policy cannot be included in a module regex branch pipeline that is managed with a .cd4pe.yaml file. To work around this issue, upgrade to version 3.2.0 or newer, or click Manage pipelines and select Manage in the web UI, then delete and recreate all deployments in the pipeline.

Module impact analysis tasks cannot be added to a pipeline after upgrading to version 3.0.0

If you added the credentials for the PE instance associated with a module pipeline's deployment tasks to Continuous Delivery for PE before you upgraded to version 3.0.0, you are unable to add impact analysis tasks to the pipeline. To work around this issue, delete and re-add the PE instance's credentials, giving the PE instance the same friendly name it had previously.

Modules page does not display latest deployment summaries

On the Modules page, information about the most recent deployment is not shown.

Custom deployment policies aren't initially shown for new control repos

When your first action in a newly created control repo is to add a deployment to a pipeline, any custom deployment policies stored in the control repo aren't shown as deployment policy options. To work around this issue, click Built-in deployment policies, then Custom deployment policies to refresh the list of available policies.

Regex branch module deployments fail if the :control_branch pattern is used for multiple modules

Deploying a module from a regex branch pipeline fails if more than one module in your Puppetfile uses the :branch => :control_branch pattern. To work around this issue, make sure that the default_branch parameter is set in the Puppetfile for every Git-sourced module that uses the :branch => :control_branch pattern.

Docker configuration changes to jobs are not immediately available

When you update the Docker configuration for a job, several minutes elapse before your changes take effect. To work around this issue, wait at least five minutes after making a Docker configuration change before attempting to run the job.

Users removed from all workspaces cannot add new workspaces

If you delete or are removed from all workspaces of which you are a member, you are directed to the Add New Workspace screen. If you log out or navigate away from this screen without creating a new workspace, you are unable to access any workspaces or get back to the Add New Workspace screen until invited to an existing workspace by another user. To work around this issue, create a new workspace when prompted, or request an invitation to an existing workspace.

How helpful was this page?

If you leave us your email, we may contact you regarding your feedback. For more information on how Puppet uses your personal information, see our privacy policy.

Puppet sites use proprietary and third-party cookies. By using our sites, you agree to our cookie policy.