atlassian/trigger-pipeline:5.3.0 support for arm64

[Rommel Platilla]

Having a problem when using the pipe atlassian/trigger-pipeline:5.3.0 on self-hosted runner on arm64.





Tried use the cloud runner for the step but being forced to use the self-self hosted


What I was expecting, it shouldn't be forced to use self-hosted as I didn't declare any service on the trigger_deploy step, or at least support arm64 as well.

[Theodora Boudale]

Hi Rommel and welcome to the community!

I'm glad you found a workaround. I will use a numbered list to address the issues you reported and the issues I see based on your screenshot:

1. The pipe atlassian/trigger-pipeline supports arm64 as of version 5.8.1:

• https://hub.docker.com/r/bitbucketpipelines/trigger-pipeline/tags

The latest version of the pipe at the moment is 5.10.0. You can use the latest version, 5.10.0, and the pipe should run in an arm environment.

2. The second screenshot you shared has a warning about the platform of the Docker image atlassian/default-image:latest. Please keep in mind that the tag latest is currently using version 1, which is a very old version of this image. The reason that the tag latest is using 1 is to keep compatibility with existing Bitbucket Pipelines builds.

Support for arm has been added to atlassian/default-image:4 and atlassian/default-image:5.

3. With regards to the last screenshot in your post: a pipe starts a separate Docker container, so a step that uses a pipe will use a Docker service even if you haven't defined one explicitly for the step.

If there is a definition for a Docker service with a custom dind image in your bitbucket-pipelines.yml, then Pipelines will use that definition for a step with a pipe. You will then see the error you posted because a cloud-based pipeline cannot use a custom dind image unless you use runtime v3.

If you want to run this step on a cloud runner, you can:

• either use runtime v3 for this step: https://support.atlassian.com/bitbucket-cloud/docs/enable-and-use-runtime-v3/
• or rename the docker service in the definition and in the steps where you use it, so that the cloud step will use the default docker service

Please feel free to reach out if you have any questions!

Kind regards,
Theodora

[Rommel Platilla]

Did a workaround thru api instead of using the pipe