text:
The Jenkins Docker Plugin does not seem to work

I followed this great tutorial to install jenkins on my k8s cluster (I'm new to jenkins), I could run jobs w/o any problem until I tried to use the Docker plugin to start docker container inside a job, for example:
stage "Prepare environment"
	docker.image('node:4.1.2').inside {
	    print "inside a node server"
	    sh("echo test");
	    //sh("npm install");
	  }

I get an error:
java.io.IOException: Failed to run image 'node:4.1.2'. Error: docker: Error response from daemon: mkdir /root/workspace: read-only file system.

here is the detailed log:
[Pipeline] stage (Prepare environment)
Using the ‘stage’ step without a block argument is deprecated
Entering stage Prepare environment
Proceeding
[Pipeline] sh
[play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA] Running shell script
+ docker inspect -f . node:4.1.2
.
[Pipeline] withDockerContainer
$ docker run -t -d -u 0:0 -w /root/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA -v /root/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA:/root/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA:rw -v /root/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA@tmp:/root/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA@tmp:rw -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** --entrypoint cat node:4.1.2
[Pipeline] // withDockerContainer
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
java.io.IOException: Failed to run image 'node:4.1.2'. Error: docker: Error response from daemon: mkdir /root/workspace: read-only file system.
	at org.jenkinsci.plugins.docker.workflow.client.DockerClient.run(DockerClient.java:125)
	at org.jenkinsci.plugins.docker.workflow.WithContainerStep$Execution.start(WithContainerStep.java:175)
	at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:184)
	at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:126)
	at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:108)
	at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:48)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
	at com.cloudbees.groovy.cps.sandbox.DefaultInvoker.methodCall(DefaultInvoker.java:18)
	at org.jenkinsci.plugins.docker.workflow.Docker$Image.inside(jar:file:/var/jenkins_home/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:122)
	at org.jenkinsci.plugins.docker.workflow.Docker.node(jar:file:/var/jenkins_home/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:63)
	at org.jenkinsci.plugins.docker.workflow.Docker$Image.inside(jar:file:/var/jenkins_home/plugins/docker-workflow/WEB-INF/lib/docker-workflow.jar!/org/jenkinsci/plugins/docker/workflow/Docker.groovy:116)
	at WorkflowScript.run(WorkflowScript:12)
	at ___cps.transform___(Native Method)
	at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
	at sun.reflect.GeneratedMethodAccessor382.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
	at com.cloudbees.groovy.cps.impl.ClosureBlock.eval(ClosureBlock.java:46)
	at com.cloudbees.groovy.cps.Next.step(Next.java:58)
	at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:33)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:30)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:30)
	at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:163)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:328)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:80)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:240)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:228)
	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:63)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)
	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Finished: FAILURE

For info the Kubernetes plugin is configured like this by the tuto.

What can I do to be able to use the jenkins docker plugin ? I tried many things but no success, since I don't really know what I'm doing...
Thanks a lot

Hey there! I think this relates to #52 and while I'm not 100% sure of the solution I believe its due to the multiple levels of indirection of filesystems when running docker in docker.
Can you try setting your working directory to / instead of /root?

Hi !, thanks for your answer,
Well, I also thought at the beginning that it was related but I was not sure anymore that it was also a docker plugin problem.
I tried what you suggested but it put all the jobs offline and blocked everything, had to trace the jenkins pod log:
INFO: Container is waiting jnlp-13d1c27e61818 [jnlp]: ContainerStateWaiting(message=runContainer: Error response from daemon: Invalid bind mount spec "/var/lib/kubelet/pods/feb0fae7-f304-11e6-ba47-42010a840096/volumes/kubernetes.io~empty-dir/workspace-volume:/": Invalid specification: destination can't be '/' in '/var/lib/kubelet/pods/feb0fae7-f304-11e6-ba47-42010a840096/volumes/kubernetes.io~empty-dir/workspace-volume:/', reason=RunContainerError, additionalProperties={})

To be totally exhaustif, when I tried to set the working directory to /home/jenkins (refering to #52 ), it seemed to go a little further in the pipeline process by reaching the "inside" block but it fails executing the sh "echo test":
[Pipeline] stage (Prepare environment)
Using the ‘stage’ step without a block argument is deprecated
Entering stage Prepare environment
Proceeding
[Pipeline] sh
[play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA] Running shell script
+ docker inspect -f . node:4.1.2
.
[Pipeline] withDockerContainer
$ docker run -t -d -u 0:0 -w /home/jenkins/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA -v /home/jenkins/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA:/home/jenkins/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA:rw -v /home/jenkins/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA@tmp:/home/jenkins/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA@tmp:rw -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** --entrypoint cat node:4.1.2
[Pipeline] {
[Pipeline] echo
inside a node server
[Pipeline] sh
[play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA] Running shell script
sh: 1: cannot create /home/jenkins/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA@tmp/durable-fd5a0e1f/pid: Directory nonexistent
sh: 1: cannot create /home/jenkins/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA@tmp/durable-fd5a0e1f/jenkins-log.txt: Directory nonexistent
sh: 1: cannot create /home/jenkins/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA@tmp/durable-fd5a0e1f/jenkins-result.txt: Directory nonexistent
[Pipeline] }
$ docker stop --time=1 c62003a2be8f613c384eb53348adb171abfb77210d91c16220fdf07d1a0a060a
$ docker rm -f c62003a2be8f613c384eb53348adb171abfb77210d91c16220fdf07d1a0a060a
[Pipeline] // withDockerContainer
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
ERROR: script returned exit code -2
Finished: FAILURE

Some other experiments, if I use this working dir "/toto/titi", I got:
java.io.IOException: Failed to run image 'node:4.1.2'. Error: docker: Error response from daemon: mkdir /toto: read-only file system.

If I use "/home/titi", I got the same as with "/home/jenkins":
[Pipeline] stage (Prepare environment)
Using the ‘stage’ step without a block argument is deprecated
Entering stage Prepare environment
Proceeding
[Pipeline] sh
[play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA] Running shell script
+ docker inspect -f . node:4.1.2
.
[Pipeline] withDockerContainer
$ docker run -t -d -u 0:0 -w /home/titi/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA -v /home/titi/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA:/home/titi/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA:rw -v /home/titi/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA@tmp:/home/titi/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA@tmp:rw -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** --entrypoint cat node:4.1.2
[Pipeline] {
[Pipeline] echo
inside a node server
[Pipeline] sh
[play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA] Running shell script
sh: 1: cannot create /home/titi/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA@tmp/durable-11a5c0ca/pid: Directory nonexistent
sh: 1: cannot create /home/titi/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA@tmp/durable-11a5c0ca/jenkins-log.txt: Directory nonexistent
sh: 1: cannot create /home/titi/workspace/play_PLR-437-jenkins-config-WQ5IB66PEGACJNE6UHFF54RVEEBWEEDWRSVCZM3YSVATI3UYUBXA@tmp/durable-11a5c0ca/jenkins-result.txt: Directory nonexistent
[Pipeline] }
$ docker stop --time=1 951eebec0ede3f094d1c5d28ef0d975d46d8de5cbfa58c72efd29c1d576a0f5b
$ docker rm -f 951eebec0ede3f094d1c5d28ef0d975d46d8de5cbfa58c72efd29c1d576a0f5b
[Pipeline] // withDockerContainer
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
ERROR: script returned exit code -2
Finished: FAILURE

leading me saying that only the /home dir is writable, but can't go any further with any subdir of /home. whatever it means...

I posted a question on stackoverflow here:
http://stackoverflow.com/questions/42238634/use-jenkins-docker-plugin-in-kubernetes-cluster-on-gke
Thanks for your time

I'm having this same problem now. Did you ever find a solution, @philippefuentes?

Unfortunately not...still waiting for a solution for this...

Hey folks!
Coming back around to this. I've been busy on other things but the core of the issue is that the directories have to exist at every level of the nested containment so configure all dirs in that way.
Is it possible to pass volumes to the Docker plugin? You need to essential say:
-v /root/workspace:/root/workspace

Remember that the executor is already running inside a container and the workspace is (by default) at /root/workspace. So you need to bind mount that workspace into your next container and have the docker plugin use that dir.

It turns out my issue was an unrelated configuration issue. I managed to figure it out. I didn't read the part in the guide about mounting /usr/bin/docker.
I hope the above solution works for you Philippe!

Hi guys, thanks for your inputs :)
@viglesiasce I checked to see if I can pass any volume to the docker plugin, but no success, don't see any option anywhere.
I tried to add it at a higher level in the global configuration (only place I found to add volumes) but it does not work there, as expected I guess:

@maxhawkins I don't really see what your are referring to in the guide, can you be more specific ?

I was talking about this subpage with the /usr/bin/docker volume mapping. It looks like you got that set up right.
I never had problems with the workspace permissions, only contacting the docker daemon. When I mapped the docker binary and socket I was able to run docker commands and everything worked.

Ok I see, in my case indeed this was already preconfigured by following this tuto.
To be sure we're talking about the same thing, I'm able to run docker commands in my script.
What I can't do is starting another container using the docker plugin syntax from inside my script.
Can you for example execute this code from a jenkinsfile in the multibranch pipeline job ?
docker.image('node:4.1.2').inside () {
  print "inside a node server"
  sh("echo test");
}

as a workaround for the moment, I installed the jenkins node plugin to be able to use node inside my jenkinsfile, but it would be great not having to install anything and start containers from a jenkinsfile.

I think i have same problem.
pipeline
node {
    stage "Container Prep"
    // do the thing in the container
    docker.image('maven:3.3.3-jdk-8').inside {
        // get the codez
        stage 'Checkout'
        git url: 'https://github.com/damnhandy/Handy-URI-Templates.git'
        stage 'Build'
        // Do the build
        //sh "./mvnw clean install"
        sh "whoami"
        sh "id"
        sh "cat /etc/passwd"

    }
}

output
[Pipeline] node
Running on jenkins-slave-2 in /var/jenkins_home/workspace/docker-test
[Pipeline] {
[Pipeline] stage (Container Prep)
Using the ‘stage’ step without a block argument is deprecated
Entering stage Container Prep
Proceeding
[Pipeline] sh
[docker-test] Running shell script
+ docker inspect -f . maven:3.3.3-jdk-8
.
[Pipeline] withDockerContainer
$ docker run -t -d -u 1001:1001 -w /var/jenkins_home/workspace/docker-test -v /var/jenkins_home/workspace/docker-test:/var/jenkins_home/workspace/docker-test:rw -v /var/jenkins_home/workspace/docker-test@tmp:/var/jenkins_home/workspace/docker-test@tmp:rw -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** --entrypoint cat maven:3.3.3-jdk-8
[Pipeline] {
[Pipeline] stage (Checkout)
Using the ‘stage’ step without a block argument is deprecated
Entering stage Checkout
Proceeding
[Pipeline] git
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url https://github.com/damnhandy/Handy-URI-Templates.git # timeout=10
Fetching upstream changes from https://github.com/damnhandy/Handy-URI-Templates.git
 > git --version # timeout=10
 > git fetch --tags --progress https://github.com/damnhandy/Handy-URI-Templates.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/master^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 9380caff2d46132c7e7a484c6aba02ac976642d0 (refs/remotes/origin/master)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 9380caff2d46132c7e7a484c6aba02ac976642d0
 > git branch -a -v --no-abbrev # timeout=10
 > git branch -D master # timeout=10
 > git checkout -b master 9380caff2d46132c7e7a484c6aba02ac976642d0
 > git rev-list 9380caff2d46132c7e7a484c6aba02ac976642d0 # timeout=10
[Pipeline] stage (Build)
Using the ‘stage’ step without a block argument is deprecated
Entering stage Build
Proceeding
[Pipeline] sh
[docker-test] Running shell script
+ whoami
whoami: cannot find name for user ID 1001
[Pipeline] }
$ docker stop --time=1 7855fa17acd5dd71b5649be5d1e28b6d0c990953c58e044e469d779e86917842
$ docker rm -f 7855fa17acd5dd71b5649be5d1e28b6d0c990953c58e044e469d779e86917842
[Pipeline] // withDockerContainer
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
ERROR: script returned exit code 1
Finished: FAILURE

In this case, docker run container with "docker run -t -d -u 1001:1001" where 1001 its user Jenkins in host system, but into container his dont know who is 1001. I think we must mount /etc/passwd in container "-v /etc/passwd:/etc/passwd:ro" but this way insecure. See https://github.com/docker/docker/issues/22323

unfortunately I have the same issue  , and was wondering if thier is any updates on the issue??
maybe i can help in some way?

Hey Folks,
Apologies that this did not come to me sooner but the approach here is wrong. What you should be doing is:

Create definitions for your pod templates that match the docker image to a Jenkins label

Use that label in the node section to get a pod with that docker image

node ('debian-8') {
// do stuff
}

Thanks @viglesiasce ,  I tried this approach but I have an exception when I use another Pod Template, even referencing the same jenkins-k8s-slave image:

node ('nodejs') {
//my stuff
}

I get:
Started by user Philippe Fuentes
Replayed #103
 > git rev-parse --is-inside-work-tree # timeout=10
Setting origin to https://github.com/vetup/jenkins-test.git
 > git config remote.origin.url https://github.com/vetup/jenkins-test.git # timeout=10
Fetching origin...
Fetching upstream changes from origin
 > git --version # timeout=10
using GIT_ASKPASS to set credentials Accès organisation Vetup Github
 > git fetch --tags --progress origin +refs/heads/*:refs/remotes/origin/*
Seen branch in repository origin/master
Seen 1 remote branch
Obtained Jenkinsfile from 33c5cc2a1c00e66ce1b17f92efd21c2e7c9527fc
[Pipeline] node
Running on default-c7fa966e79356 in /root/workspace/jenkins-test_master-X7X5Z54VVKXUA35MJKFUWRV7TO6FM63NQS24FG3FNTBT6FE67DVQ
[Pipeline] {
[Pipeline] sh
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
java.io.IOException: Failed to mkdirs: /root/workspace/jenkins-test_master-X7X5Z54VVKXUA35MJKFUWRV7TO6FM63NQS24FG3FNTBT6FE67DVQ
	at hudson.FilePath.mkdirs(FilePath.java:1169)
	at org.jenkinsci.plugins.durabletask.FileMonitoringTask$FileMonitoringController.<init>(FileMonitoringTask.java:112)
	at org.jenkinsci.plugins.durabletask.BourneShellScript$ShellController.<init>(BourneShellScript.java:167)
	at org.jenkinsci.plugins.durabletask.BourneShellScript$ShellController.<init>(BourneShellScript.java:161)
	at org.jenkinsci.plugins.durabletask.BourneShellScript.launchWithCookie(BourneShellScript.java:90)
	at org.jenkinsci.plugins.durabletask.FileMonitoringTask.launch(FileMonitoringTask.java:63)
	at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.start(DurableTaskStep.java:166)
	at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:184)
	at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:126)
	at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:108)
	at groovy.lang.GroovyObject$invokeMethod.call(Unknown Source)
	at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48)
	at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113)
	at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:151)
	at org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:21)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:115)
	at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:149)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:146)
	at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:123)
	at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:16)
	at WorkflowScript.run(WorkflowScript:10)
	at ___cps.transform___(Native Method)
	at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:109)
	at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:82)
	at sun.reflect.GeneratedMethodAccessor403.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
	at com.cloudbees.groovy.cps.impl.ConstantBlock.eval(ConstantBlock.java:21)
	at com.cloudbees.groovy.cps.Next.step(Next.java:74)
	at com.cloudbees.groovy.cps.Continuable.run0(Continuable.java:154)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.access$001(SandboxContinuable.java:18)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:33)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable$1.call(SandboxContinuable.java:30)
	at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.GroovySandbox.runInSandbox(GroovySandbox.java:108)
	at org.jenkinsci.plugins.workflow.cps.SandboxContinuable.run0(SandboxContinuable.java:30)
	at org.jenkinsci.plugins.workflow.cps.CpsThread.runNextChunk(CpsThread.java:165)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.run(CpsThreadGroup.java:328)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup.access$100(CpsThreadGroup.java:80)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:240)
	at org.jenkinsci.plugins.workflow.cps.CpsThreadGroup$2.call(CpsThreadGroup.java:228)
	at org.jenkinsci.plugins.workflow.cps.CpsVmExecutorService$2.call(CpsVmExecutorService.java:64)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)
	at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
Finished: FAILURE

When I switch back in my script to the first initial template, everything is fine again:
node () {
//my stuff
}

Or
node ('k8s') {
//my stuff
}

Running into the same issue here.
If I set the working directory to /root/workspace and then mount a host volume from /root/workspace onto the jnlp slave's /root/workspace dir, then the kubernetes plugin fails to provision a new container, throwing a read-only file system error.
I've tried using the home/jenkins working directory, which throws a Failed to write to /home/jenkins/.jenkins/cache/jars/** error instead.

Closing this out as you can now configure the Kubernetes plugin in your pipelines:
https://github.com/jenkinsci/kubernetes-plugin#container-configuration

I think this issue should be reopened, as in its current state the tutorial for setting this up on GCE doesn't work. I am also having the same problem as mentioned in this thread, and like @philippefuentes I've tried pretty much everything I can think of. The closest I can get to success is having it error out with the workspace dir being on a read-only file system. I've tried dozens of different variations on the configuration but I've made no progress in a week of messing about with this.
Things I've tried:

building docker inside the jnlp slave
various jnlp slave images
different workspace dirs
binding/unbinding the docker binary and socket volumes
binding a workspace volume

Being able to configure kubernetes in the pipelines hasn't helped in finding a working setup for this issue :(

Hi @robotmay , just in case you haven't read this, I recently created the issue #75 that is related I think, and it seems to be a good way to go, as defining additional podTemplate would allow to use custom slave images in the pipeline.
For now, the only podTemplate working is the default one created by this tutorial.
Meaning, to me, that a special configuration is applied through the predefined jenkins volume used to install Jenkins:
https://storage.googleapis.com/solutions-public-assets/jenkins-cd/jenkins-home-v3.tar.gz
that I cannot understand...

As noted in the other bug here is a pipeline that I got to work without issue:
podTemplate(label: 'ubuntu-k8s', containers: [
    containerTemplate(name: 'ubuntu', image: 'ubuntu:16.04', ttyEnabled: true,
        command: 'cat')
  ]) {
    node('ubuntu-k8s') {
        container('ubuntu') {
            stage('Run Command') {
                sh 'cat /etc/issue'
            }
        }
    }
}

Reopening until further feedback on this.

the podTemplate seems to create a new template for every possible combination of images! This creates an unbounded list of pod templates for me. Is there is anyway to use podTemplate without storing it in jenkins' config?

@bombela this is not in the Jenkins config it is in your pipeline definition. Each repository can define its own.
Closing this issue as this is the path forward for per pipeline template config.

why closed again? seems not having definite solution yet..
I am with kubernetes and jenkins on same node of GKE

@philippefuentes hey guy, Did you ever find a solution? I wasted almost three days tyring to make it work. ㅠㅠ

authors: amitgilad3 bombela cilindrox dehypnosis iglov maxhawkins philippefuentes robotmay viglesiasce


text:
Dataset isn't in the docs as a "concept"

We added back the Dataset class (basically an alias class that fills in some blanks for you), but it's not listed on the left navigation of the docs. Any chance we can put that back?
If we do, we should add a lovely ..note: banner on that page saying that if you only interact with one dataset (a default one) that you don't need to worry about this, and you can use datastore.<method> and we'll automatically use the default dataset.

Closing as a duplicate of #707 (I started commenting there before I realized this existed).

source: gharchive/issue

authors: dhermes jgeewax

repo: GoogleCloudPlatform/gcloud-python

license_type: permissive

license_source: bigquery


text:
Add connection as a parameter for any method that hits the wire?

From #796

@dhermes, @jgeewax could we make every API-triggering method take an optional connection argument, which would override the bound / default connection for only that call? Seems like that would be a useful pattern across all services; it would also help mark those methods as being API/latency relevant.

Thanks for filing. That's the goal. Mentioned this in #728 and #632 but it's not really spelled out.

datastore
Free API functions

[x] api.get
[x] api.put
[x] api.delete
[x] api.allocate_ids

batch.Batch methods
(note that Batch.__init__ takes a connection, handles fallback)

[ ] Batch.commit

dataset.Dataset methods
(note that Dataset.__init__ takes a connection, defaulting to None).

[ ] Dataset.get (wraps api.get)
[ ] Dataset.put (wraps api.put)
[ ] Dataset.delete (wraps api.delete)
[ ] Dataset.batch (Batch instance holds connection)
[ ] Dataset.transaction (Transaction instance holds connection)

query.Query methods

[x] Query.fetch (handles fallback, passes connection to Iterator)

transaction.Transaction methods:
(note that Transaction.__init__ takes a connection, handles fallback via Batch.__init__)

[ ] Transaction.begin
[ ] Transaction.rollback
[ ] Transaction.commit (delegates to Batch.commit).

pubsub
Free API functions

[x] api.list_topics
[x] api.list_subscriptions

subscription.Subscription methods

[x] Subscription.from_api_repr
[ ] Subscription.create (uses self.topic.connection)
[ ] Subscription.exists (uses self.topic.connection)
[ ] Subscription.reload (uses self.topic.connection)
[ ] Subscription.modify_push_configuration (uses self.topic.connection)
[ ] Subscription.pull (uses self.topic.connection)
[ ] Subscription.acknowledge (uses self.topic.connection)
[ ] Subscription.modify_ack_deadline (uses self.topic.connection)
[ ] Subscription.delete (uses self.topic.connection)

topic.Topic methods:
(note that Topic.__init__ takes a connection, handles fallback)

[x] Topic.from_api_repr
[ ] Topic.create (uses self.connection)
[ ] Topic.exists (uses self.connection)
[ ] Topic.publish (uses self.connection)
[ ] Topic.batch (delegates to _Batch instance)
[ ] Topic.delete (uses self.connection)

topic._Batch methods:

[ ] _Batch.commit (uses self.topic.connection, called from __exit__ when batch used as a context manager)

storage
_helpers._PropertyMixin methods (inherited by Blob / Bucket)

[ ] _PropertyMixin.reload
[ ] _PropertyMixin.patch

acl.ACL methods

[ ] ACL.reload ("pure virtual", but could work w/ explict connection)
[ ] ACL.save (ditto)
[ ] ACL.clear (ditto)

acl.BucketACL methods

[ ] BucketACL.reload (uses self.bucket.connection)
[ ] BucketACL.save (ditto)
[ ] BucketACL.clear (ditto)

acl.BlobACL methods

[ ] BlobACL.reload (uses self.blob.connection)
[ ] BlobACL.save (ditto)
[ ] BlobACL.clear (ditto)

Free API functions

[x] api.lookup_bucket
[x] api.list_buckets (handles fallback, passes connection to _BucketIterator)
[x] api.get_bucket
[x] api.create_bucket

batch.Batch methods
(note that Batch.__init__ takes a connection, handles fallback)

[ ] Batch._do_request (uses self._connection)
[ ] Batch.finish (delegates to _do_request;  called in __exit__ when batch used as a context manager).

blob.Blob methods

[ ] Blob.connection property (delegates to self.bucket.connection)
[x] Blob.generate_signed_url
[x] Blob.exists
[ ] Blob.rename (delegates to self.bucket.copy_blob)
[ ] Blob.delete (delegates to self.bucket.delete_blob)
[x] Blob.download_to_file
[x] Blob.download_to_filename
[x] Blob.download_as_string
[x] Blob.upload_from_file
[x] Blob.upload_from_filename
[x] Blob.upload_from_string
[ ] Blob.make_public

bucket.Bucket methods
(note that Bucket.__init__ takes a connection, does not handle fallback)

[ ] Bucket.connection property
[ ] Bucket.exists
[ ] Bucket.create
[ ] Bucket.get_blob
[ ] Bucket.list_blobs (delegates to _BlobIterator, which uses bucket's connection)
[ ] Bucket.delete_blob
[ ] Bucket.delete_blobs (delegates to delete_blob)
[ ] Bucket.copy_blob
[ ] Bucket.upload_file (should die?)
[ ] Bucket.upload_file_object (should die?)
[ ] Bucket.make_public (delegates to self.default_object_acl and blobs)

@tseaver Please re-open if this isn't covered (by clients now instead of connections)

authors: dhermes jgeewax tseaver


text:
Support autonaming of Pub/Sub Subscriptions

The Pub/Sub documentation states:

If the name is not provided in the request, the server will assign a random name for this subscription on the same project as the topic.

We are unable to make an API call to create a subscription without a name. We suspect this is an issue with the Google API Client library, since ArgumentError is being raised.

@tmatsuo - sorry if you've already been pinged about this elsewhere, but I couldn't find anything. Do you know if support for auto-named subscriptions is real, or if this was a documentation error?

@tmatsuo friendly ping :)

I just found this issue! Sorry for the late reply.
Yes, it is not currently supported on the API surface (although the internal core server supports it, thus the documentation discrepancy). Sorry about the confusion.

@tmatsuo Hah! Thanks for clarifying! We removed the docs from gcloud-ruby about this and made the name required. Glad to know the reason.
Is this a feature that will be supported in future API versions?

It' been one year and I still got bitten by this issue after following the documentation here
Is there anything I can do to help fix this issue?

authors: Draiken blowmage stephenplusplus tmatsuo

repo: GoogleCloudPlatform/gcloud-ruby

license_source: github-api


text:
Improve function calling accuracy when pulling SQL results

improve data format and handling
from [Row((3.85, datetime.date(2024, 3, 12)), {'max_day_cap': 0, 'timestamp': 1})]
when the model understood 0 and 1 as values from the column order, and wasn't picking up the real values from row object.
to
[{'max_day_cap': 3.85, 'timestamp': datetime.date(2024, 3, 12)}]

Thanks for your contribution. I appreciate the simplicity! If possible, could you post more context around the input prompt and output response in your original message before/after this change? Nonetheless I'll merge this and deploy a new version of the app now.

source: gharchive/pull-request

repo: GoogleCloudPlatform/generative-ai


text:
Open questions around additional packages

#137 introduced our second additional package. This raises some questions.

Should we continue to host them in this repo?

I think there is value in keeping these packages in this repository, but I can see argument for separating them into their own repositories. This would allow separate CI and simplify the release process for these libraries.

How should documentation be handled?

If we keep them here, should we roll-up their documentation into a special section in the google-auth documentation?

How should we handle releases?

If the packages stay here, how should we handle releases?
@dhermes I'd really like your input here, as you tackled a similar set of problems with google-cloud-python.

(this is not a 1.0.0 blocker)

I have found it both convenient and cumbersome to manage multiple packages in one place. For this set of packages, I see value in having them documented all at once.
As for releases, we just use tag names like pkgname-x.y.z and then manually parse the pkgname and the version x.y.z before upload. This isn't so bad, given you've already decided to host them in this repo. However, it completely hoses the concept of "stable" docs as far as RTD is concerned.

I see value in having them documented all at once.

We can still do that if we separate the repositories with some sphinx magic. Also, intersphinx is pretty powerful, and the documentation around oauthlib is already well separated.
The tag stuff sounds reasonable, but I'm wondering if it's just more reasonable to have a separate repo.
We could also just have a google-auth-extras or google-auth-contrib package and that might simplify things, but that would force users to pull in the whole kitchen sync.

I don't actually have a preference, though ISTM the most cogent argument for "one repo" is to have a single issue tracker.

ISTM the most cogent argument for "one repo" is to have a single issue tracker.

Ah, I'm seeing that as an argument against one repo. I don't necessarily think I want issues related to httplib2 and oauthlib integration in this repo.
@lukesneeringer any thoughts?

I think there is value in keeping these packages in this repository, but I can see argument for separating them into their own repositories. This would allow separate CI and simplify the release process for these libraries.

I really dislike the one-repository situation in google-cloud-python:

It makes CI cumbersome.

CI has to test everything if anything is changed (there are advantages to this, too, but on the whole it just makes CI take longer and become less useful).
In order to make CI complete reasonably, we maintain short-circuiting logic which mostly makes CI behave as if it would in separate repos, except not as well.

It makes installing development releases more difficult. pip install http://github.com/x/y/releases/master.zip no longer works.
The single issue tracker is a hindrance, not a benefit. It is harder to find things in a sea of unrelated issues. Filtering helps but it would be better for them to be logically separate.

There are a few other reasons. My general advice is, "1:1 repos:packages". I wish I could change this on google-cloud-python (it would be an insane amount of work so I am hoping my CI changes are "good enough").

Cool, looks like it's settled. I'll make separate repos. :)

:+1:

authors: dhermes jonparrott lukesneeringer


text:
Missing app engine standard framework option from menu

Open / create a project with an appengine-web.xml. Don't accept the popup to add framework support. Instead try to add it manually (right click on the module -> add framework support). Notice that the option for AE standard is missing.

Looks like this was introduced back in https://github.com/GoogleCloudPlatform/google-cloud-intellij/pull/1103

The problem is that IntelliJ doesn't let you add child framework elements when the parent already exists.
i.e. since "web" is already present, and "appengine" is a child of web, then the appengine option does not appear.
I'm trying to determine if this is an IJ bug, or intended behavior

https://intellij-support.jetbrains.com/hc/en-us/community/posts/115000073610-Cannot-add-child-framework-support-when-parent-is-already-added
According to JB, this is currently not possible. I can file a feature request with them. Also, we can restructure how we organize our framework support options.

https://youtrack.jetbrains.com/issue/IDEA-168955

removing this from the milestone as its dependent on an external JB bug

note the JB bug was accepted, but no fix has been schedule yet

I am hitting this bug, any workaround?

Instead of adding Framework support you can manually add the facet you are interested in:
Go to module settings -> facets. And select either the App Engine flexible or standard facet depending on the type of application you have. This will have essentially the same outcome as adding framework support.

Thanks Etan,
Using this procedure, I end up seeing the following 3 options in the plugins' menu :
Edit Configurations
Google App Engine Deployment
Google Stackdriver debug
Deploying to App engine works, but note that the option to deploy locally is missing!

Hi Julien. By missing do you actually mean it's not in the menu? If that's the case could you please post a screenshot of the menu as well as of your facet panel?
If you mean that clicking it doesn't have the desired effect then it's possible you don't have the App Engine standard facet. If you have the flexible facet instead, that option to run locally won't work as that runs a local App Engine standard server. Instead you can use a typical container like tomcat or jetty to run your app.

Forgot to mention, you can always add the local dev server run configuration manually if the menu shortcut isn't working (I'll investigate this myself too to see if some about missing App Engine standard framework support would cause this): open the run configurations editor, click to add a new one, and select the App Engine local dev server config (it may be hidden under 'irrelevant' on the bottom).

Thanks for following up Ethan. Here is more info:
First, here is the menu:

In the other menu:  "Tools > Google Cloud Tools", I can also deploy to app-engine, but not locally (option missing).
Right click on project, 'Add Framework support...' opens this, with a missing entry for App Engine Standard.

I had tried to add it manually after reading the doc, but the local dev server option is nowhere to be found, including in 'irrelevant':

Here is the Facets panel: It shows App engine standard, no info get displayed by selecting it, which may or may not be normal

That is strange indeed.
What version of the plugin are you running? To check, go to the plugins section of the settings and choose Google Cloud Tools, and the version will show up on the right:

For reference, here is what you should be seeing:
In the shortcut tools menu (do you mind posting a screenshot of this menu?):

As a new run configuration option:

In the available run configurations for you to use:

@Judp0m Julien does your project have an appengine-web.xml?

Ethan:
I'm pretty sure I'm using 17.6.2, I will check tonight and confirm
(I installed intelliJ and the google plugin just a few days ago).
https://plugins.jetbrains.com/plugin/8079-google-cloud-tools
Patrick,
Yes, the project has an appengine-web.xml
I was using eclipse until recently, and everything was working fine. Also, deploying to app engine works fine. I currently rely on maven to do the local deployment via mvn appengine:run. I use appengine 1.9.54 and appengine-maven-plugin 1.3.1.

@Judp0m - Aha it just came to me: are you using Community Edition of IntelliJ?
If so, the local dev server option will not be available. There are technical reasons why this is so: mainly due to the way that the IntelliJ platform only exposes these app server features in Ultimate Edition.
We do have it in our backlog to explore making this available for Community Edition, but currently the only way to do this directly in the IDE is to use Ultimate Edition.
Disregard this if you are already using Ultimate Edition.

Oh wow, yes I am using the community edition.
That is a pretty big deal... Is that mentioned in the docs? I don't recall
seeing that anywhere but may have missed it.
Too bad, but at least we now know why. Thanks!
On Tue, Aug 1, 2017, 12:25 PM Etan Shaul notifications@github.com wrote:

@Judp0m https://github.com/judp0m - Aha it just came to me: are you
using Community Edition of IntelliJ?
If so, the local dev server option will not be available. There are
technical reasons why this is so: mainly due to the way that the IntelliJ
platform only exposes these app server features in Ultimate Edition.
We do have it in our backlog to explore making this available for
Community Edition, but currently the only way to do this directly in the
IDE is to use Ultimate Edition.
Disregard this if you are already using Ultimate Edition.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/google-cloud-intellij/issues/1203#issuecomment-319471301,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AH8ekLLVP7Mg6PB2q_DVP3Mvl2vvX-3Gks5sT3u3gaJpZM4L2u4p
.

--
(Sent from my phone, please excuse any typos)

Sorry for the confusion here.
It is displayed in the docs (see the top of the page) in the 'before you begin' section, right below in the starred box: https://cloud.google.com/tools/intellij/docs/deploy-std
However, this has been good feedback; perhaps its still not prominent enough.

Oops, I linked to the wrong doc above. See this one:
https://cloud.google.com/tools/intellij/docs/deploy-local

closing:

we have documented support for running locally with community edition
we have added tools menu items for creating standard / flex framework support

authors: Judp0m etanshaul patflynn


text:
Writes the selected BOM from the client library wizard to the user's pom.xml

progress towards #1921

The user select a version of the BOM to use when adding a client library:

If the user previously did not have a BOM, the new depedency is written to the dependencyManagement section:

If the user did already have a bom, then the version is updated to match the selected version in the UI.

The client library is written without a version specified:

If no BOM is selected (i.e. if the flag is disabled or the API call to fetch the BOM versions fail), this will fallback to not writing any BOM and using the version from the libraries.json file.

The notification is now shown without a version, since the version may be managed by the BOM:

TODO in a near PR (I left it out of this one to keep things easier to review) I want to refactor CloudLibraryDependencyWriter into a mockable service (right now its a bunch of static methods). This will allow us to mock things out and get some test coverage around AddCloudLibrariesAction.

note: as discussed offline, this workflow will not strip out the versions of dependencies already specified in the pom.xml. Instead, we'll use inspections for this case.


text:
When publishing to GKE, if Kubectl is not installed, the info on the dialog window that appears is wrong.

The command that appears on the dialog window is wrong because it says gcloud components install Kubectl with a capital K and it fails, it should say gcloud components install kubectl with lower case k.

Fixed in #942


text:
sbom: fix the call to generate_and_push_sbom for rpm build

In the rpm builds we don't have BUILD_DIR variable defined, this change assumes (as all the remaining of the build script does) that PWD is the build dir.

/lgtm

repo: GoogleCloudPlatform/guest-test-infra


text:
Added support for specifying a separate project to run bq jobs

Add support for specifying a different project for running BQ jobs. This prevents granting Security Admin in the project that the data resides in.
This PR has changes from https://github.com/GoogleCloudPlatform/healthcare-federated-access-services/pull/9

@chaopeng could you please help me with the build logs, I do not have permissions to view the logs.

I also don't have permission. I think this is not build logs.

The build logs are cryptic here, with a number of errors of the form:
failed: invalid character 'p' after top-level value
For example:
Step #3 - "go_test": === RUN   TestConfigHandlers
Step #3 - "go_test": E0514 15:18:24.867239    2046 dam.go:467] failed to sync hydra clients: rpc error: code = Internal desc = DecodeJSON() failed: json.Unmarshal(404 page not found
Step #3 - "go_test": ) failed: invalid character 'p' after top-level value
Step #3 - "go_test": === RUN   TestConfigHandlers/#00
...
Could it be that ") failed" is trying to tell us what failed, but it is getting ")" as the name of the item?

@mbarkley sorry, this PR has been merged. Please start another PR for https://github.com/DNAstack/healthcare-federated-access-services/commit/0d18bf6787832d5fb74f0fe50e94d31c9edf2e55 commit

authors: cdvoisin chaopeng monicavalluri


text:
Should managed VM samples be reorganized?

Both the managedvms folder and appengine folders have managed VMs samples.  Shouldn't they be placed in the same folder?

The https://github.com/GoogleCloudPlatform/java-docs-samples/tree/master/appengine/appidentity sample is including from the Java App Engine docs for App Identity. It actually runs on managed VMs or standard App Engine if you remove true.
My understanding was that new samples should be Managed VMs if possible, but I put it in the App Engine folder for the reason that it is used from https://cloud.google.com/appengine/docs/java/appidentity/

Possibly we should remove the managedvms folder. I just noticed that the README.md in https://github.com/GoogleCloudPlatform/java-docs-samples/tree/master/appengine/appidentity talks about Managed VMs.

I think we've done the renames and now the docs all point to the right place.  I'm closing.

authors: ajkannan lesv tswast

repo: GoogleCloudPlatform/java-docs-samples


text:
Read Me updated

The command to publish has been corrected.

I have signed it

It looks like this change has been merged elsewhere, so I'm going to close this.
(If this is incorrect please feel free to let me know)


text:
feat(aiplatform): add batch code predict sample

Description
This sample was done for Python - https://github.com/GoogleCloudPlatform/python-docs-samples/blob/3d6340881961a238b2ecc3a0028a02aa2ee9d944/generative_ai/batch_predict/batch_code_predict.py
Fixes #
Note: Before submitting a pull request, please open an issue for discussion if you are not associated with Google.
Checklist

[x] I have followed Sample Format Guide
[ ] pom.xml parent set to latest shared-configuration
[ ] Appropriate changes to README are included in PR
[ ] These samples need a new API enabled in testing projects to pass (let us know which ones)
[ ] These samples need a new/updated env vars in testing projects set to pass (let us know which ones)
[x] Tests pass:   mvn clean verify required
[x] Lint  passes: mvn -P lint checkstyle:check required
[ ] Static Analysis:  mvn -P lint clean compile pmd:cpd-check spotbugs:check advisory only
[ ] This sample adds a new sample directory, and I updated the CODEOWNERS file with the codeowners for this sample
[ ] This sample adds a new Product API, and I updated the Blunderbuss issue/PR auto-assigner with the codeowners for this sample
[ ] Please merge this PR for me once it is approved

Error from build log:
Caused by: io.grpc.StatusRuntimeException: FAILED_PRECONDITION: Training text objective TEXT_CLASSIFICATION_SINGLE_LABEL is no longer supported. Please migrate to Vertex AI https://cloud.google.com/vertex-ai/docs/start/automl-gemini-comparison.


text:
Import com.google.cloud:libraries-bom in

Libraries BOM is the recommended way of managing versions for GCP client libraries.
I've ran into a problem with split versions between gax and gax-grpc when working on GoogleCloudPlatform/java-docs-samples#5836. I am fine with applying a workaround (either forcing a gax version, or importing the BOM on the individual sample level), but it may make sense to do it for all samples.
The counterargument is that all samples should function well without the shared-configuration parent, so setting versions on the parent is not desirable.

Memo:
Many of the samples in Java-docs-samples repository use the Libraries BOM
https://github.com/GoogleCloudPlatform/java-docs-samples/pull/5808/files

That's probably the way for me to go then. Closing this issue.

authors: elefeint suztomo

repo: GoogleCloudPlatform/java-repo-tools