chmod 777 $BUILD_DIR fails

Question

I have to an image which runs under a different user than "root" named "user" with the UID of 1000. When the pipeline's "Build setup" is run, after the cloining, the logs look like as if the chmod operation fails:

...
HEAD is now at 8bc500b fixup! project init
+ chmod 777 $BUILD_DIR
Skipping artifact upload for failed step
...

The image is run-as-user 1000. What is the issue here? The output is quite little, so I need to ask.

Here is my bitbucket-pipelines.yml:

image:
name: vicampotk/php:7.2-cli-alpine-build
run-as-user: 1000

clone:
depth: 50

pipelines:
default:
- step:
name: lint php
script:
- php --version
- composer install --no-interaction --no-suggest --no-progress
artifacts:
- vendor/**
- step:
name: unit tests, composer build, ci scripts
script:
- composer cs-check
- composer ci
artifacts:
- build/html/**

And that is the Dockerfile of that image:

FROM php:7.2-cli-alpine3.7

COPY shell /tmp/shell

RUN :     && addgroup -g 1000 user && adduser -D -G user -u 1000 user && chmod u+s /bin/su     && apk add --no-cache git     && apk add --no-cache $PHPIZE_DEPS     && /tmp/shell/install-composer.sh     && rm -rf /tmp/shell     && pecl install xdebug         && docker-php-ext-enable xdebug         && apk del $PHPIZE_DEPS     && :

USER user

T. Klingenberg · Answer

@StannousBaratheon: Thanks for your feedback. I'm not able to reproduce the error any longer. As in the example you give (and I also retried other Dockerfiles) it now works for me as well.

StannousBaratheon · Answer

Hi Tom,

It's not immediately obvious what might be causing the issue. I tested your default user configuration and found it to be working as expected. The cut down example I used is as follows:

Dockerfile:

FROM php:7.2-cli-alpine3.7

RUN addgroup -g 1000 user && adduser -D -G user -u 1000 user

USER user

bitbucket-pipelines.yml:

image: sjtannous/test
pipelines:
default:
- step:
script:
- whoami

Note that the run-as-user attribute isn't required because you've set the default user in the Dockerfile (although specifying it doesn't hurt).

Typically when you see the "chmod 777 $BUILD_DIR" command the clone has completed successfully and we start to execute your build so I suspect an error is occurring in your build script. The lack of log output is unusual but can happen if your script (or tooling used in your script) modifies or redirects stdout.

I suggest starting with a simplified example such as the one I provided above and gradually add commands to debug this issue further. If you require additional assistance please raise a support ticket so that we can access and investigate the specific issue in your repository.

T. Klingenberg · Answer

@StannousBaratheon Thanks for your reply and the suggestion you give as they allow to rule-out side effects. The user is fine, the homedirectory was checked, this is also documented in your docs, so I was able to verify that upfront. the home directory of that user is available:

$ docker run vicampotk/php:7.2-cli-alpine-build ls -al /home 
total 16
drwxr-xr-x 1 root root 4096 Feb 12 14:18 .
drwxr-xr-x 1 root root 4096 Feb 14 08:44 ..
drwxr-sr-x 2 user user 4096 Feb 12 14:18 user
drwxr-sr-x 2 www-data www-data 4096 Jan 10 01:29 www-data

However what you write about the  "chmod 777 $BUILD_DIR" command and the "build container" opens up for trouble shooting.

first of all it was my own assumption that the  "chmod 777 $BUILD_DIR" command makes the build fail only because it is the last output which looks good to me before the build on it's own report a failure:

LAST-GOOD: + chmod 777 $BUILD_DIR

FIRST-BAD: Skipping artifact upload for failed step

So it was my assumption only that chmod would have failed as the build ***does not provide any insightful information of the failure reason***.

I would love to know the exact reason, that would be especially useful to better understand and use Atlassian Bitbucket Pipelines.

Do you have any specs on the build process so that I could check against that?