This page describes known issues in Pipelines:
For issues with Cloud Platform CD, see Known issues in Cloud Platform CD.
If a new Cloud Platform environment is provisioned by a CI/CD process, such as Acquia Pipelines or Acquia Code Studio, the new environment is provisioned with the default Cloud Platform PHP version. The new environment does not inherit the PHP settings from the source environment or CI/CD build. For more information on the default PHP version, see default Cloud Platform PHP version.
Workaround: You must set your desired PHP version for the new environment. You can configure the PHP version through the Cloud Platform user interface or the command line.
acli app:task-wait "$(acli api:environments:update $TARGET_ENV_ID --lang_version=8.1)"
Note
If your Drupal application contains deprecated code, changing the PHP version after deployment might cause initial failure notices.
On Cloud Next, when Pipelines is configured to use Acquia Git, jobs are not automatically triggered. To execute your job, you must click Start Job.
As a workaround, configure Pipelines to use GitHub or Bitbucket.
Contrary to Node.js 16, you cannot use nvm
to install different
versions of Node.js 18 in the Pipelines container. Only the version that
comes preinstalled is supported.
To get the latest version of Node.js 18 that is supported, run the following command:
nvm list
If you try to install a different version, your build output displays the following error:
Executing step hello.
+ echo "Hello, Pipelines!" > docroot/index.html
+ nvm install 18.12.0
Downloading and installing node v18.12.0...
Downloading https://nodejs.org/dist/v18.12.0/node-v18.12.0-linux-x64.tar.xz...
########################################
56.3%
########################################################################
100.0%
Computing checksum with sha256sum
Checksums matched!
Now using node v18.12.0 (npm v)
Creating default alias: default -> 18.12.0 (-> v18.12.0 *)
+ node -v
node: /lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.27' not found (required by node)
node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.25' not found (required by node)
node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by node)
+ node -v
The Cloud Platform Pipelines user interface uses a user authentication system incompatible with IP address allowlisting.
Workaround: If you are using IP address allowlisting, you must use Pipelines from the command line instead of the user interface.
Users authenticated into cloud.acquia.com using custom identity provider integration receive a 403 error when attempting to authenticate into the Cloud Platform Pipelines UI feature and the Pipelines client/CLI.
If you are experiencing issues with Bitbucket connections, see the important notes at Connecting Pipelines to your Bitbucket repo.
The Bitbucket permissions model requires the current user to own the repository that exists in the personal default workspace of the user, and all of the code being deployed. Repositories cannot be part of a custom workspace.
If permissions are not configured correctly, users might be unable to add branches from external pull requests or experience other issues.
Pipelines only works with Bitbucket Cloud, and not Bitbucket infrastructure.
The API for Bitbucket does not allow you to pull in the branch from a fork inside a pull request.
You must add a user as a collaborator to your fork to see the user’s branches.
Bitbucket has an optional setting to automatically delete pull request branches after pull requests are merged. This will cause the pr-merged event in Pipelines to fail with an error:
Failed to parse the build file. The VCS path [feature/branch] was not found
in git repository.
Bitbucket uses the username and email address associated with a Git commit to associate the commit with a Bitbucket user account. If no user is associated with a commit, Pipelines will fail with an error:
webhook start failed to start pipeline for app [app]. Operation failed with
the following details: Payload do not have the following required
information.
Workaround: Ensure the username and email attached to the commit is associated with a Bitbucket user account.
OpenSSH version 7.8 now generates RSA key pairs with a default format incompatible with Pipelines. Pipelines jobs that include a SSH key generated in the default format by these versions of OpenSSH in the ssh-keys section of the build definition file will fail with the following error:
Failed to parse the build file. The SSH key named [KEY NAME] is not a valid
SSH private key or requires a password.
Workaround: Generate a key using a format compatible with Pipelines jobs:
ssh-keygen -m PEM -t rsa -b 4096
Pipelines allows you to link repositories to the service to trigger new Pipelines jobs using webhooks.
If you’ve linked Pipelines to a GitHub repository and later revoke the GitHub personal access token used by Pipelines, trying to change the linked Pipelines repository will result in an error: “Please ensure your personal access token is valid. Failed to remove webhook.”
Workaround: Use the Pipeline CLI to reconnect to GitHub, or reconnect GitHub by directly visiting the linking page at the following URL, replacing my-application-id with your application ID in:
https://cloud.acquia.com/a/applications/my-app-id/pipelines/github
Manually starting jobs only works with branches. Tags are not supported. To manually start a job, ensure that you do it from a branch instead.
When both branches and tags do not trigger your Pipelines jobs automatically, then it might indicate we need to reset your Pipelines credentials.
Contact Acquia Support to request your Pipelines credentials to be reset.
If your YAML build definition invokes RVM (Ruby Version Manager), you will run into errors. To work around the issue, you need to switch your build to using rbenv instead. Rbenv is a lightweight and more developer-friendly option to switch between Ruby versions.
To continue using different versions of Ruby, replace any instances of RVM in your YAML build definition with equivalent rbenv commands.
rvm install x.x.x
becomes rbenv install x.x.x
.rvm use x.x.x
becomes rbenv global x.x.x
or rbenv local x.x.x
depending on the desired behavior.