Jib in Pipeline with non root user

[2020testuser]

Hi,
Could you please let me know whether Gradle 4.6 image (from docker hub) with Jib need user -root to run in Kubernetes pod? Below is the yaml file content sample.

• name: app-build image: /gradle:4.6 imagePullPolicy: Always #securityContext: # runAsUser: 1000 #runAsGroup: 1000 workingDir: /workspace/app script: | #!/bin/sh gradle wrapper -u '1000' --info --scan --gradle-version=4.6 gradle wrapper -u '1000' --gradle-version=4.6 --distribution-type=bin gradle build service:jib -u '1000' --no-build-cache --recompile-scripts -S -i --debug --scan -x test \ -Djib.to.auth.username='xxxx' \ -Djib.to.auth.password=''xxxx' \ -Djib.container.user='1000:1000' \ -Djib.container.user='gradle:gradle' \ -Djib.extraDirectories.paths = ['/workspace/app', '/workspace/app/service'] \ -Djib.extraDirectories.permissions = ['/workspace/app': '775', '/workspace/app/service': '775'] \ -Djib.to.image='<my docker repo/new image name>:latest' volumeMounts: - name: workspace mountPath: /workspace

Gradle 4.6 image in Docker Hub need to run as user -root and fails for all other users when run in Kubernetes Pod.

Expected Behavior

Gradle 4.6 image must be able to run as user - gradle or user - 1000 when initiated in Kubernetes pod whose securitycontext is set to user - root and group as root.

Current Behavior

Gradle 4.6 image works only for user root in Kubernetes pod and fails for user 1000 and user - gradle in Kubernetes pod.

Context

How has this issue affected you? What are you trying to accomplish? I'm trying to run gradle image from within Kubernetes Pod as non-root user.

Steps to Reproduce

sample code above

Your Environment

Gradle 4.6 image pulled from Docker hub and pushed to company's Docker registry.
The Gradle 4.6 image when run in Kubernetes Pod as user -root , the application build is successful. The Gradle 4.6 image when run in Kubernetes Pod asnon-root user , the application build fails.
Exception Message is below.
[service-build-step] 07:43:25.705 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] Caused by: org.gradle.internal.service.ServiceCreationException: Could not create service of type CrossBuildFileHashCache using BuildSessionScopeServices.createCrossBuildFileHashCache(). [service-build-step] 07:43:25.705 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] at org.gradle.internal.service.DefaultServiceRegistry$FactoryMethodService.invokeMethod(DefaultServiceRegistry.java:857) [service-build-step] 07:43:25.705 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] at org.gradle.internal.service.DefaultServiceRegistry$FactoryService.create(DefaultServiceRegistry.java:808)

I tried passing -u - root, -u - gradle , changing the permission of the project directory using jib.extraDirectories.permissions and no luck.
Any info. to fix this issue would be greatly helpful.

Thanks in advance!

[chanseokoh]

Closing this as a dup of #2438. I believe the root issue is unrelated to Jib; the issue is that you just cannot run Gradle inside Tekton whether or not you use Jib.

BTW, I don't understand these commands:

gradle wrapper -u '1000' --info --scan --gradle-version=4.6
gradle wrapper -u '1000' --gradle-version=4.6 --distribution-type=bin

Downloading a wrapper in a Tekton step doesn't make sense at all because the Tekton step is running on the image gradle:4.6.

[chanseokoh]

FTR: issue resolved after @2020testuser configured a Tekton Task so that Gradle can create necessary files.

tektoncd/catalog#289 (comment)

[2020testuser]

@chanseokoh - Could you please confirm on the below?
I'm using a PVC ( in Kubernetes) to store my application source (pulled from git).
In my gradle command below (in my Tekton Pipeline), I'm passing --gradle-user-home=/workspace/.gradle as you recommended (to resolve permission issues) since I'm usiong gradle 4.6 image which runs as user-gradle by default.

gradle build testapp:jib --gradle-user-home=workspace/.gradle --build-cache -Duser.home=/workspace

I believe I don't need the below volume mounts as my /.gradle is under /workspace/.gradle. I had to change the mountpaths to /workspace/.gradle below. Is that correct? Also, since, /workspace is in PVC, caching these in PVC, would improve my build performance.
Since, I used the tekton catalog's jib, these volumemounts are in my pipeline. Thanks in advance!

volumeMounts: - name: $(params.cache) mountPath: /tekton/home/.gradle/caches subPath: gradle-caches - name: $(params.cache) mountPath: /tekton/home/.gradle/wrapper subPath: gradle-wrapper - name: $(params.cache) mountPath: /tekton/home/.m2 subPath: m2-cache - name: $(params.cache) mountPath: /tekton/home/.cache subPath: jib-cache

[chanseokoh]

@2020testuser basically you're right. I see that

• you set /workspace/.gradle as the Gradle user home
• you set -Duser.home=/workspace to tell Java to cache Maven artifacts into /workspace/.m2
• /workspace is a PVC (therefore everything under /workspace is persisted, not sure if this is a good idea)

then because everything is persisted, I think you don't really need all those extra mount points coming from the Jib Gradle catalog. (Definitely you don't need to think about /tekton/home at all.) You can still selectively mount subdirectories (e.g., /workspace/.gradle/caches, /workspace/.m2, etc) using different volumes (or using the same volume but with different subPath) if you like; volume mounts can be nested.

[2020testuser]

@chanseokoh - Thanks Much! I also tested. I'm not clear on the below you mentioned. Since, I have the /workspace as persistent volume, technically, workspace/.gradle/caches, /workspace/.m2, etc should be still available for next time build (task pod) even if my task (pod) gets completed. Looks like I'll have to do some reading on this. If you have any related info. could you please share? Thanks!

You can still selectively mount subdirectories (e.g., /workspace/.gradle/caches, /workspace/.m2, >etc) using different volumes (or using the same volume but with different subPath) if you like; >volume mounts can be nested.

[chanseokoh]

You understood it right. I was just saying that, even if you mounted a volume at /workspace, you can still mount separate volumes for any subdirectories if you think that'll help you manage things. For example, you mount volume A at /workspace, volume B at /workspace/foo, volume C at /workspace/bar, etc. Also, using the subPath property, you may use a single volume A for multiple mount points (this is what the Jib Tekton Gradle sample does), if that helps at all. Of course, you don't need to do this, because you are mounting the entire /workspace.

That said, I don't know if persisting everything under /workspace is a good idea. It is your choice, and maybe that's what you really want to do. For example, if you have project source files, they will be persisted too. If you run Gradle on, say, /workspace/my-java-project, then intermediate Gradle build output (/workspace/my-java-project/build) will be persisted too.

And you said you store project source files in a volume. Why? I think it's unusual to cache a source project that is available on a Git repository. Normally, you'll make Tekton pull in the Git repo at runtime.

[2020testuser]

@chanseokoh - I get it now. I use persistent volume. Yes , I use Tekton (git clone task) to pull the source from git repo and dump into persistent volume. My plan is to delete the source from persistent volume after successful build. But, don't delete the cache directories as my build will be fast next time.
I also want to test with plain empty volume instead of using persistent volume .
Will need to do further testing.

Thanks !