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
Hi Tom,
The "Build setup" runs in a different container to your build container and so the "run-as-user" instruction has no impact on that section of the Pipeline.
I don't see how the "chmod 777 $BUILD_DIR" command has failed from the snippet you provided above so the problem may be unrelated to that command.
Note that it's important to create the user with a home directory (e.g. useradd --create-home user) as Pipelines uses the user home throughout the build process. Failing to do this can result in missing log output for example which might be masking the real issue.
If you continue to have trouble please open a support ticket so that we can look at your specific configuration.
@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?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.