Bitbucket pipeline bundle command failing

Technical Support
, , ,
1

Hardware: Verdin iMX8MP WB V1.1A
Torizon OS 6.4.0-build.5
Torizoncore-builder v3.8.1

Hi all,
I am trying to integrate our Torizon easy installer package creation with our existing bitbucket pipelines workflow and am getting the following error:

2024-03-29 13:17:28,662 - torizon.tcbuilder.cli.build - DEBUG - Removing temporary bundle directory bundle_20240329131728_641433.tmp
2024-03-29 13:17:28,663 - torizon.tcbuilder.cli.build - INFO - Removing output directory 'output_directory' due to build errors
2024-03-29 13:17:28,716 - root - ERROR - Error: Can't determine current container ID.
2024-03-29 13:17:28,717 - root - DEBUG - Traceback (most recent call last):
  File "/builder/torizoncore-builder", line 221, in <module>
    mainargs.func(mainargs)
  File "/builder/tcbuilder/cli/build.py", line 506, in do_build
    raise exc
  File "/builder/tcbuilder/cli/build.py", line 479, in do_build
    build(args.config_fname, args.storage_directory,
  File "/builder/tcbuilder/cli/build.py", line 465, in build
    raise exc
  File "/builder/tcbuilder/cli/build.py", line 454, in build
    handle_output_section(
  File "/builder/tcbuilder/cli/build.py", line 303, in handle_output_section
    handle_bundle_output(
  File "/builder/tcbuilder/cli/build.py", line 359, in handle_bundle_output
    "host_workdir": common.get_host_workdir()[0],
  File "/builder/tcbuilder/backend/common.py", line 409, in get_host_workdir
    container_id = get_own_container_id(docker_client)
  File "/builder/tcbuilder/backend/common.py", line 402, in get_own_container_id
    raise OperationFailureError("Can't determine current container ID.")
tcbuilder.errors.OperationFailureError: Can't determine current container ID.

The bitbucket pipeline step is similar to this:

- step:
        name: Build EasyInstaller Image
        image: torizon/torizoncore-builder:3.8.1
        services:
          - docker
        script:
          - mkdir /deploy
          - apt update
          - apt install -y zip
          - export $(grep -v '^#' tmp.env | xargs)
          - torizoncore-builder --log-level debug build --file ./Scripts/tcbuild.yaml

The tcbuild.yaml is similar to this:

# >> The input section specifies the image to be taken as the base for the
# >> customization.
input:
  easy-installer:
    remote: "https://artifacts.toradex.com/artifactory/torizoncore-oe-prod-frankfurt/kirkstone-6.x.y/release/5/verdin-imx8mp/torizon/torizon-core-docker/oedeploy/torizon-core-docker-verdin-imx8mp-Tezi_6.4.0+build.5.tar"

# >> The customization section defines the modifications to be applied to get
# >> the desired output image.
customization:
  device-tree:
    overlays:
      remove:
        - verdin-imx8mp_dsi-to-hdmi_overlay.dtbo
  kernel:
    arguments:
      - ipv6.disable=1
  filesystem:
    - Scripts/FileSystemChanges/

# >> The output section defines properties of the output image.
output:
  # >> Parameters for deploying to an Easy Installer image.
  easy-installer:
    # >> Output directory of the customized image (REQUIRED):
    local: output_directory
    # >> Information used by Toradex Easy Installer:
    name: "Build ${VERSION_TAG}"
    description: "Easy Installer Image Build for device"
    # licence: files/custom-licence.html
    # release-notes: files/custom-release-notes.html
    # accept-licence: true
    # autoinstall: true
    # autoreboot: true
    bundle:
      compose-file: docker-compose-production.yml
      platform: linux/arm/v8
      username: "${USERNAME}"
      password: "${PASSWORD}"
      registry: <ACR registry>

The issue seems to surround the bundle step of the build command and possibly with the docker in docker requirement. Has anyone gotten the bundle step working in bitbucket pipelines? And am I right on this being an issue with running a docker in docker container? I also found a list of restricted docker commands in pipelines, will these be an issue during the bundle and downstream processes?
Thank you so much!
-Adam

2

Greetings @akogutrnd,

How exactly did you setup the torizoncore-builder command and container in your pipeline?

For context, your error is coming from this function here: torizoncore-builder/tcbuilder/backend/common.py at bullseye · toradex/torizoncore-builder · GitHub

For some processes TorizonCore Builder needs to be able to determine it’s own container ID from within itself. If it can’t do this then this results in the error you’re seeing:

tcbuilder.errors.OperationFailureError: Can't determine current container ID.

Now there are a couple of ways the tool uses to determine this. The first and preferred way is to read an environment variable containing the name of the container that TorizonCore Builder is running in. With this it’s able to determine it’s own container ID.

When using TorizonCore Builder normally you would use the tcb-env-setup.sh script to create the alias for the torizoncore-builder command. In this script the container is given a name and this name is then passed as an environment variable into the container as seen here: tcb-env-setup/tcb-env-setup.sh at master · toradex/tcb-env-setup · GitHub

If you did not setup the TorizonCore Builder container properly in your pipeline then this information would not be present and thus the tool would not be able to determine it’s container ID resulting in this error you see.

At least this is my best guess for what might be wrong here. I’m not too familiar with bitbucket pipelines. For our testing with TorizonCore Builder we use gitlab CI pipelines. You can actually see the CI yaml file we use for this here: torizoncore-builder/.gitlab-ci.yml at bullseye · toradex/torizoncore-builder · GitHub

Best Regards,
Jeremias

3

Thank you for your quick reply Jeremias!
Unfortunately every time I tried to source the tcb-env-setup in the pipeline, it would crash after a few seconds of running with no error output which I believe is because of the restricted docker commands in my original post. So instead I used the torizoncore builder docker image as a base image and ran the commands directly in the torizoncore-builder image which would not have all of the setup scripting done prior to running the container. Here is the bash script I tried to use with tcb-env-setup:

wget https://raw.githubusercontent.com/toradex/tcb-env-setup/master/tcb-env-setup.sh
echo Done Getting
. ./tcb-env-setup.sh -t 3.8.1
echo Done Running
mv .env tmp.env
export $(grep -v '^#' tmp.env | xargs)
cat tmp.env | envsubst > .env
rm tmp.env
echo Done env
torizoncore-builder build --file ./Scripts/tcbuild.yaml

But we did not get any echo printouts after “Done Getting”
Thanks,
Adam

4

So instead I used the torizoncore builder docker image as a base image and ran the commands directly in the torizoncore-builder image which would not have all of the setup scripting done prior to running the container.

I see, honestly I would expect some issues then since this is not at all how we intended this tool to be used. I can’t guarantee every feature and function of this tool will work in such conditions. Does bitbucket not allow the tool to be executed as we intended?

Unfortunately every time I tried to source the tcb-env-setup in the pipeline, it would crash after a few seconds of running with no error output which I believe is because of the restricted docker commands in my original post.

If that is the case can’t you just mimic the end result of the script manually? If you look at the setup script all it’s really doing is setting up an alias for the docker run command that invokes TorizonCore Builder. Looking at the list of restricted docker commands the only problematic one I see is that we use a bind-mount -v "$(pwd)":/workdir. But this isn’t related to your error.

As I said before what the container needs in this situation is the TorizonCore Builder container needs a name. The same name the needs to be made available in the container as an environment variable under TCB_CONTAINER_NAME as seen in the setup script. Just try and mimic as many docker run options as you can in your pipeline so that the result is the same as if you ran the setup script.

Now after this for the bundle command TorizonCore Builder needs to invoke a docker-in-docker container in parallel. Whether bitbucket allows that or not I’m not sure.

Best Regards,
Jeremias

5

As an update, we were unable to get the custom OS built on the bitbucket pipeline. We believe it would require using a self-hosted runner because of the privileged flag requirement. Instead of using bitbucket pipelines we set up a runner for a self-hosted service that we already had the infrastructure laid out for.

6

I see, well I’m glad to hear you were able to work something out. As for bitbucket I’ll give this as feedback to our developer team to see if improvements may be possible in the future.

Best Regards,
Jeremias