How Bitbucket pipeline entrypoint and workdir

[Javier Fernández Pastrana]

Hello,

I am using the following image in my pipeline nrfconnect-sdk:v2.3-branch

This image has a tool call "west" which is a Python tool installed using "pip"

The Dockerfile can be found here: https://github.com/NordicPlayground/nrf-docker/blob/saga/Dockerfile 

If you run this image locally, you can find something like this:

However, when this image is launched using Bitbucket pipeline, you will find other "WORKDIR", you do not find any of that folders described above nor "west" tool installed

I am trying to fix the problem, but I do not know how our image is started, neither what happens with our files and environment variables.

Best regards,

Javier

[Patrik S]

Hello @Javier Fernández Pastrana and thank you for reaching out to Community!

When a pipeline build starts, bitbucket will spin up a fresh container for the step and it will use the docker image you defined in the yml file. The default entry point of the image will be overwritten with /bin/sh, and this will start the container with a terminal session where the commands you defined in your step's script are going to be executed.

Also, during the build setup phase, the repository where the pipeline is running will be cloned inside the container in the folder /opt/atlassian/pipelines/agent/build/ and the scripts will be executed inside that folder. This path is exposed in the build as the environment variable BITBUCKET_CLONE_DIR.

As the step's script runs in a shell session, when executing a command, such as the west command you were trying to run, the pipeline will look for an executable with that name in the directories contained in the $PATH variable. If a program with that name does not exist in any of the directories on $PATH, you will receive the command not found error.

Checking for that image you shared, it seems the west command is located inside the folder 

/root/ncs/toolchains/v2.3.0/usr/local/bin

and that folder is not by default in $PATH for that image : 

$ echo $PATH

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

this is the reason why the west command is not being found.

You can include the following command in your pipeline script to add the directory of the west command in the $PATH variable :

export PATH=/root/ncs/toolchains/v2.3.0/usr/local/bin:$PATH

I'd also suggest debugging your pipeline locally with that image first, and once the errors are fixed you can then push the changes to your bitbucket repository.

Thank you, @Javier Fernández Pastrana !

Patrik S

[Javier Fernández Pastrana]

Hello @Patrik S 

Thank you very much for the explanation.

I was debugging the container but not all the steps that are defined there.

It is weird, because "west" command in my local container works without adding it to the PATH variable.

I think that thre is something more, I tried your recommendation but there is other error:

This pipeline was working with previous versions of nrf-docker, but not with the last changes.

They also have some issue with Github actions. Therefore, I do not know if it is happening here the same.

I am really stuck with this issue.

Best regards,

Javier

[Patrik S]

Hello Javier,

As you mentioned the previous versions of the image were working fine, the image might have been updated which introduced the changes that are causing the error you are receiving now. You might want to try using the previous version - if it's still available - or a different tag.

Since you described that running it locally the west command was found, I tried running it locally following the below sequence of commands and encountered the same issue :

$ docker pull nordicplayground/nrfconnect-sdk:v2.3-branch
$ docker run -it --entrypoint=/bin/sh nordicplayground/nrfconnect-sdk:v2.3-branch
# whereis west
 west:

Could you please try running the above commands and let us know if you have a different output? Kindly share the full output with us here. Make sure to run the docker pull first, as this will make docker download the latest version of the image with that tag, as you might have an older version cached in your local machine.

Thank you, @Javier Fernández Pastrana !

Patrik S