qalinn
commented
3 years ago @rcollette Did you find any workaround for this problem?
Open rcollette opened 3 years ago
qalinn
commented
3 years ago @rcollette Did you find any workaround for this problem?
rcollette
commented
3 years ago @qalinn - I have not found a workaround.
rcollette
commented
1 year ago @qalinn The workaround I have used looks like:
Gitlab build job
# BUILD
build:
stage: build
interruptible: true
extends: .kubernetes_runners
<<: *except_master_and_prodfix
variables:
AWS_ACCESS_KEY_ID: $DEV_AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY: $DEV_AWS_SECRET_ACCESS_KEY
image:
name: gcr.io/kaniko-project/executor:$KANIKO_EXECUTOR_VERSION
entrypoint: [ "sh" ]
script:
# We cannot git merge from master here because busybox used in Kaniko does not have git nor does it have
# a package installer.
# Docker command is not available in Kaniko image so we have to create the .docker/config.json file manually.
- echo "$DOCKER_AUTH_CONFIG" > /kaniko/.docker/config.json
#This builds and image but does not push to the registry
- /kaniko/executor
--context $CI_PROJECT_DIR
--no-push
--skip-unused-stages=true
--cache=true
--cache-repo=${CI_REGISTRY_IMAGE}/cache
--log-timestamp=true
--log-format=text
--target build-and-test
# Copy artifacts from the root where the Dockerfile copied them, to the project dir because artifacts
# can only be captured from there.
- cp -R /reports $CI_PROJECT_DIR
artifacts:
when: always
expire_in: 30 days
expose_as: Code coverage report
paths:
- reports/coverage/index.html
- reports/coverage
reports:
coverage_report:
coverage_format: cobertura
path: reports/coverage/Cobertura.xml
junit:
- reports/unit-tests/*test-result.xmlDockerfile - The build and test stage moves the reports folder to the root. This is the key to preservation.
#With restore completed, now copy over the entire application.
FROM restore as build-and-test
LABEL type="build"
ARG SOLUTION_NAME="Precisely.Pdx.Api"
ARG VERSION="0.0.0"
WORKDIR /app_build/$SOLUTION_NAME
COPY $SOLUTION_NAME .
# We still want to capture coverage reports even if there was a coverage threshold or test error
# Any artifacts we want to capture have to be moved to root.
# The kaniko working directory is removed when kaniko finishes working.
RUN ./coverage.sh || flag=1 ; \
mv reports / ; \
exit $flag
RUN dotnet publish $SOLUTION_NAME.Web --output /dist --configuration Release --no-restore /p:Version=$VERSIONThis solution works for us because, though the files are copied to the root of the gitlab runner instance and that might be unnerving, the runner is an ephemeral kubernetes pod so it's not going to conflict with other build jobs.
It would be a little more straight forward if the build context was preserved perhaps in a known/controlled location and perhaps by using a CLI option so as not to break existing behavior.
pasfl
commented
4 months ago Is there any news on this? i ran into it with a three stage build (common setup, build, final image) where i need to copy the context in the second stage. So the above workaround does not work for me.
Actual behavior The context directory is deleted when targeting a second stage of a multi-stage build when the second stage relies on a prior stage.
Expected behavior The context directory should not be deleted.
To Reproduce Steps to reproduce the behavior:
docker run -it --entrypoint sh gcr.io/kaniko-project/executor:debug-v1.3.0Insert the following into the Dockerfile and save
Observe the following
The current working directory has been deleted.
Commands from the current working directory will not function
When running with the Gitlab Runner Operator for Openshift, this behavior causes a loss of command pathing and the ability to locate the busybox directory itself, even if you first change directories to root (outside the current context)
.gitlab-ci.yaml
gitlab build log (note the directory not found message appears in the log before the command that caused it)
With commands like
lsandcpno longer functioning due to the missing busybox directory, build artifacts cannot be copied back to the context directory path, which is where they must be located for Gitlab to be able to store them using its artifacts functionality.Additional Information
FROM base as build-and-test LABEL type="build-and-test"