bitbucket pipeline produces a broken docker image
Asked by AZZ:

Hello,

the docker image created by a pipeline crashes during execution. the image created on a local box - runs fine.

Here are the details:

bitbucket-pipelines.yml

```
image: atlassian/default-image:3
definitions:
services:
docker-2048:
memory: 2048
type: docker
steps:
- step: &Clean_cache
name: Clean Cache
script:
- pipe: atlassian/bitbucket-clear-cache:3.2.0
variables:
BITBUCKET_USERNAME: $BITBUCKET_USERNAME
BITBUCKET_APP_PASSWORD: $BITBUCKET_USER_APP_TOKEN
CACHES: ["docker"]
 - step: &Build
name: Build
services:
- docker-2048
# caches:
# - docker
script:
- branch=$( echo "${BITBUCKET_BRANCH////_}" | tr '[:upper:]' '[:lower:]' )
- export TAG=$DOCKER_HUB_REPO:$branch_${BITBUCKET_BUILD_NUMBER}_${BITBUCKET_COMMIT}
- echo "export TAG=$TAG" > docker.vars
- export DOCKER_FILE="docker/Dockerfile.dev"
- echo "export DOCKER_FILE=${DOCKER_FILE}" >> docker.vars
- cat docker.vars
- docker build -t $TAG -f $DOCKER_FILE .
- docker images
- docker login -u $SERVICE_ACCOUNT -p $SERVICE_ACCOUNT_TOKEN
- docker push $TAG
pipelines:
custom:
Build:
- step: *Clean_cache
- step: *Build

```

the partial output is:
> .....
>
> Step 26/31 : COPY misc/config/*.cfg ${CONFIG_PATH}/
> ---> daa915364ce7  
> Step 27/31 : COPY misc/config/resource ${RESOURCE_PATH}  
> ---> 4eeac5338d96  
> Step 28/31 : RUN sed -i '/\[jcli\]/a bind=0.0.0.0' ${CONFIG_PATH}/jasmin.cfg  
> ---> Running in 6af8720ab465  
> Removing intermediate container 6af8720ab465  
> ---> 9edde9f21b48  
> Step 29/31 : COPY [docker/docker-entrypoint.sh](https://bitbucket.org/sailtech-sms/jasmin/src/1f156f460865d4966e865d876e43e9edd92a1064/docker/docker-entrypoint.sh) /  
> ---> 7eaab101038c  
> Step 30/31 : ENTRYPOINT ["/docker-entrypoint.sh"]  
> ---> Running in 7d3dffe7b240  
> Removing intermediate container 7d3dffe7b240  
> ---> 09dc3c59ff08  
> Step 31/31 : CMD ["[jasmind.py](http://jasmind.py)", "--enable-interceptor-client", "--enable-dlr-thrower", "--enable-dlr-lookup", "-u", "jcliadmin", "-p", "jclipwd"]  
> ---> Running in f57dfab06da0  
> Removing intermediate container f57dfab06da0  
> ---> e0d7ea1446a5  
> Successfully built e0d7ea1446a5  
> Successfully tagged xxxxxx/xxxxxx:75_1f156f460865d4966e865d876e43e9edd92a1064

if i run the build locally:

\`docker build -t local -f ./docker/Dockerfile.dev .\`

then the output is:
> ...
>
> =\> \[19/22\] COPY misc/config/\*.cfg /etc/jasmin/ 0.1s  
> =\> \[20/22\] COPY misc/config/resource /etc/jasmin/resource 0.1s  
> =\> \[21/22\] RUN sed -i '/\\\[jcli\\\]/a bind=0.0.0.0' /etc/jasmin/jasmin.cfg 0.5s  
> =\> \[22/22\] COPY docker/docker-entrypoint.sh / 0.1s  
> =\> exporting to image 6.2s  
> =\> =\> exporting layers 6.2s  
> =\> =\> writing image sha256:c4f98aa31ecd3c145d9b5fd8a9ffa0961046dc1bc8979a8799739deb2db4c512 0.0s  
> =\> =\> naming to docker.io/library/local

aside from the fact that the output style is very different ( i give it to the difference between build and buildkit ), the number of steps in the build is different. At the same the steps seemed to be identical in nature.

The sizes of the images look identical:
> \[az@dell5000 SMSMS-48\]$ docker images  
> REPOSITORY TAG IMAGE ID CREATED SIZE  
> local latest c4f98aa31ecd 2 hours ago 1.47GB  
> xxxxx/xxxx 76_c75e7ed055957032fd0dc8ed2987978336e1f97f c8e0d0e8ff90 3 hours ago 1.47GB

the build time is drastically different:

local build time is \~40 minutes, whereas BB gets job done in 6 minutes. I can theoretically attribute this different to the download time for all dependencies, but...

I'm very confused about the situation. Appreciate your insight.


Answers:
author: Theodora Boudale
body: Hi [@AZZ](/t5/user/viewprofilepage/user-id/5060131),

Could you please share some additional info so we can better understand the issue you mention below?
> the docker image created by a pipeline crashes during execution

1. Are you starting a Docker container with that image locally?
2. What is the exact command you are using to start the container?
3. Does the container not start at all? Or does it start and it's crashing later?
4. Are you executing anything on this container before it crashes?
5. Does the command **docker logs \<container_id\>** , where **\<container_id\>** is the id of the container that crashes, show any output and errors?

Kind regards,  
Theodora

comments: author: AZZ
body: [@Theodora Boudale](/t5/user/viewprofilepage/user-id/818086),

thank you for looking into this issue.

1. Are you starting a Docker container with that image locally?  
   yes.
2. What is the exact command you are using to start the container?  
   I use \` docker compose up jasmin\`  
   here is the docker-compose.yml:  

   ```
   version: "3"

   services:
   redis:
   image: redis:alpine

   rabbit-mq:
   image: rabbitmq:alpine

   jasmin:
   build:
   context: ./
   dockerfile: ./docker/Dockerfile.dev
   image: xxxxxx/xxxxx:76_c75e7ed055957032fd0dc8ed2987978336e1f97f
   volumes:
   - ./jasmin:/usr/jasmin/jasmin
   ports:
   - 2775:2775
   - 8990:8990
   - 1401:1401
   depends_on:
   - redis
   - rabbit-mq
   environment:
   REDIS_CLIENT_HOST: redis
   AMQP_BROKER_HOST: rabbit-mq
   ```

   i use this same compose file for invoking both locally compiled and "bitbucket" compiled images, by replacing the image in the "image:" tag.
3. Does the container not start at all? Or does it start and it's crashing later?  
   it starts, but then crashes with python specific error, when i access a certain api:

   ```
   smsms-48-jasmin-1 | File "/usr/local/lib/python3.11/site-packages/jasmin/protocols/cli/protocol.py", line 150, in lineReceived

   smsms-48-jasmin-1 | return self.sessionLineCallback(cmd, arg, line)

   smsms-48-jasmin-1 | File "/usr/local/lib/python3.11/site-packages/jasmin/protocols/cli/managers.py", line 14, in filter_cmd_and_call

   smsms-48-jasmin-1 | return fCallback(self, *args, **kwargs)

   smsms-48-jasmin-1 | File "/usr/local/lib/python3.11/site-packages/jasmin/protocols/cli/mtrouterm.py", line 103, in parse_args_and_call_with_instance

   smsms-48-jasmin-1 | RouteClassArgs = inspect.getargspec(self.sessBuffer['route_class'].__init__).args

   smsms-48-jasmin-1 | builtins.AttributeError: module 'inspect' has no attribute 'getargspec'

   smsms-48-jasmin-1 | 
   ```

4. Are you executing anything on this container before it crashes?  
   I make API calls to the service provided by this container. Some work, but a specific one always seemed to crash the "bitbucket" built container.
5. Does the command **docker logs \<container_id\>** , where **container_id** is the id of the container that crashes, show any output and errors?  
   please see above.  

   I can provide (privately) all config files if you think this will help to troubleshoot more efficient.  
   thank you!


author: Theodora Boudale
body: Hi [@AZZ](/t5/user/viewprofilepage/user-id/5060131),

Thank you for the info, I believe it's best to create a support ticket so you can share more details privately.

I will go ahead and create it for you using the email of your community account and I'll include all the details you have shared here. You will receive shortly an email with a link to the support ticket, the ticket will be visible only to you and Atlassian staff. After you receive the email with the link, please post in the ticket:

- The Dockerfile you are using to build the image locally  
- The URL of the Pipelines build that produces the Docker image with the issue

If you have any questions, please feel free to let me know.

Kind regards,  
Theodora


author: AZZ
body: Thank you [@Theodora Boudale](/t5/user/viewprofilepage/user-id/818086) . Will be on outlook for that email.


author: Theodora Boudale
body: Hi [@AZZ](/t5/user/viewprofilepage/user-id/5060131),

I created the support ticket for you yesterday, and I see that you created a ticket yourself as well; I'm not sure if you received an email about the ticket I created for you.

This is the ticket I created (no one other than you and Atlassian can view its content):

* <https://support.atlassian.com/requests/BBS-199063/>

Please let me know if you can access it; I let my colleagues know about the duplicate tickets.

Kind regards,  
Theodora


Tags: bitbucket-cloud

bitbucket-pipelines

cloud