[JIRA] (JENKINS-40723) Built Dockerfile images are never removed

2019-01-30 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi edited a comment on  JENKINS-40723  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Built Dockerfile images are never removed   
 

  
 
 
 
 

 
 {quote}[~brianjmurrell]Doesn't deleting all of the Jenkins produced hashy type tags mean that Jenkins won't be able to find an image to re-use for a future run of a job where the Dockerfile has not changed?{quote}First of all, Jenkins doesn't even do that. If a build would be rerun, it would just build the Docker image again. Secondly, it's not like Jenkins does any kind of caching for non-Docker agents (like caching the node_modules/ generated from an npm install). And besides, Docker already has decent caching built into it; any step in the Dockerfile where the involved files did not change since last time, Docker automatically just re-uses the cached layer; so no additional help from Jenkins is needed.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-40723) Built Dockerfile images are never removed

2019-01-30 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi commented on  JENKINS-40723  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Built Dockerfile images are never removed   
 

  
 
 
 
 

 
 

Brian J Murrell Doesn't deleting all of the Jenkins produced hashy type tags mean that Jenkins won't be able to find an image to re-use for a future run of a job where the Dockerfile has not changed?
 First of all, Jenkins doesn't even do that. If a build would be rerun, it would just build the Docker image again. Secondly, it's not like Jenkins does any kind of caching for non-Docker agents (like caching the node_modules/ generated from an npm install). And besides, Docker already has decent caching built into it; any step in the Dockerfile where the involved files did not change since last time, Docker automatically just re-uses the cached layer; so no additional help from Jenkins is needed.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-40723) Built Dockerfile images are never removed

2019-01-30 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi edited a comment on  JENKINS-40723  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Built Dockerfile images are never removed   
 

  
 
 
 
 

 
 I disagree with brushing this ticket off to use `docker-gc` instead.First of all, it makes no sense to use `docker-gc` in the `post` section of the declarative pipeline, because `docker-gc` only removes images that are older than (by default) 1 hour old. The image we'd want to clean is very fresh though.Secondly, `docker-gc` (to me) undesirably removes all other images as well; ones I might still be using. If I have a cron job set to run a Docker image every 2 hours, and `docker-gc` would keep removing the image, then I would need to have the re-download the image from the registry each time, wasting time and bandwidth.It would be great if either the generated image tag would automatically be removed on build finish, or if the image tag were predictable so that I could clean up manually in the end. Or simply just making the image tag available so I could read it.Currently    +[here| https://github.com/amcsi/youtube-delete-tracker/blob/master/Jenkinsfile.groovy #L48] ] + is how I clean up my built Docker image. I am forced to use  [   + [ imperative scripts +  | https://github.com/amcsi/youtube-delete-tracker/blob/master/Jenkinsfile.groovy #L11-L12] ] + to build the Docker image to get the image tag so that I could clean up in the end.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-40723) Built Dockerfile images are never removed

2019-01-30 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi edited a comment on  JENKINS-40723  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Built Dockerfile images are never removed   
 

  
 
 
 
 

 
 I disagree with brushing this ticket off to use `docker-gc` instead.First of all, it makes no sense to use `docker-gc` in the `post` section of the declarative pipeline, because `docker-gc` only removes images that are older than (by default) 1 hour old. The image we'd want to clean is very fresh though.Secondly, `docker-gc` (to me) undesirably removes all other images as well; ones I might still be using. If I have a cron job set to run a Docker image every 2 hours, and `docker-gc` would keep removing the image, then I would need to have the re-download the image from the registry each time, wasting time and bandwidth.It would be great if either the generated image tag would automatically be removed on build finish, or if the image tag were predictable so that I could clean up manually in the end. Or simply just making the image tag available so I could read it.Currently +[here|https://github.com/amcsi/youtube-delete-tracker/blob/master/Jenkinsfile.groovy#L48]+ is how I clean up my built Docker image. I am forced to use +[imperative scripts|https://github.com/amcsi/youtube-delete-tracker/blob/master/Jenkinsfile.groovy#L11-L12]+ to build the Docker image to get the image tag so that I could clean up in the end. EDIT: I have fixed the links in the above paragraph.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-40723) Built Dockerfile images are never removed

2019-01-29 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi edited a comment on  JENKINS-40723  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Built Dockerfile images are never removed   
 

  
 
 
 
 

 
 I disagree with brushing this ticket off to use `docker-gc` instead.First of all, it makes no sense to use `docker-gc` in the `post` section of the declarative pipeline, because `docker-gc` only removes images that are older than (by default) 1 hour old. The image we'd want to clean is very fresh though.Secondly, `docker-gc` (to me) undesirably removes all other images as well; ones I might still be using. If I have a cron job set to run a Docker image every 2 hours, and `docker-gc` would keep removing the image, then I would need to have the re-download the image from the registry each time, wasting time and bandwidth.It would be great if either the generated image tag would automatically be removed on build finish, or if the image tag were predictable so that I could clean up manually in the end. Or simply just making the image tag available so I could read it.Currently  +  [here| [https://github.com/amcsi/youtube-delete-tracker/blob/6848efaa2186325d76b1c676b756363746fdd227/Jenkinsfile.groovy #L48]] +  is how I clean up my built Docker image. I am forced to use [ + imperative scripts +  | [https://github.com/amcsi/youtube-delete-tracker/blob/6848efaa2186325d76b1c676b756363746fdd227/Jenkinsfile.groovy #L11-L12]]to build the Docker image to get the image tag so that I could clean up in the end.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-40723) Built Dockerfile images are never removed

2019-01-28 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi commented on  JENKINS-40723  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Built Dockerfile images are never removed   
 

  
 
 
 
 

 
 I disagree with brushing this ticket off to use `docker-gc` instead. First of all, it makes no sense to use `docker-gc` in the `post` section of the declarative pipeline, because `docker-gc` only removes images that are older than (by default) 1 hour old. The image we'd want to clean is very fresh though. Secondly, `docker-gc` (to me) undesirably removes all other images as well; ones I might still be using. If I have a cron job set to run a Docker image every 2 hours, and `docker-gc` would keep removing the image, then I would need to have the re-download the image from the registry each time, wasting time and bandwidth. It would be great if either the generated image tag would automatically be removed on build finish, or if the image tag were predictable so that I could clean up manually in the end. Or simply just making the image tag available so I could read it. Currently here is how I clean up my built Docker image. I am forced to use imperative scriptsto build the Docker image to get the image tag so that I could clean up in the end.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-33510) dir('foo') inside "docker.image().inside{}" does not affect CWD of launched processes

2019-01-07 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi edited a comment on  JENKINS-33510  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: dir('foo') inside "docker.image().inside{}" does not affect CWD of launched processes   
 

  
 
 
 
 

 
 [~duemir] oh, so it needs to create a directory like that as a sort of preparation.But it doesn't make sense to me how it's expecting for the parent of the workdir to be writable.I thought `/var/www` is fine for a workdir, but of course `/var` wouldn't be writable to the default user under normal circumstances. [ + A popular article + |https://buddy.works/guides/how-dockerize-node-application] suggests to use `/app` as the workdir, where of course `/` wouldn't be writable. Why isn't Docker writing to `/var/tmp` instead which is writable? What am I (or others) expected to do instead?   
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-33510) dir('foo') inside "docker.image().inside{}" does not affect CWD of launched processes

2019-01-07 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi commented on  JENKINS-33510  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: dir('foo') inside "docker.image().inside{}" does not affect CWD of launched processes   
 

  
 
 
 
 

 
 Denys Digtiar oh, so it needs to create a directory like that as a sort of preparation. But it doesn't make sense to me how it's expecting for the parent of the workdir to be writable. I thought `/var/www` is fine for a workdir, but of course `/var` wouldn't be writable to the default user under normal circumstances. A popular article suggests to use `/app` as the workdir, where of course `/` wouldn't be writable. Why isn't Docker writing to `/var/tmp` instead which is writable? What am I (or others) expected to do instead?    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-33510) dir('foo') inside "docker.image().inside{}" does not affect CWD of launched processes

2019-01-02 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi edited a comment on  JENKINS-33510  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: dir('foo') inside "docker.image().inside{}" does not affect CWD of launched processes   
 

  
 
 
 
 

 
 [~duemir] I have Docker Pipeline plugin 1.17, and Docker version 18.09.0. And doing dir in  +  [my Jenkinsfile|https://github.com/amcsi/youtube-delete-tracker/blob/723ab7a9fcb508608141abbcd1615740c1d63264/Jenkinsfile.groovy] +  got me...  {code:java}[Pipeline] {[Pipeline] stage[Pipeline] { (Run tests)[Pipeline] dirRunning in /var/www[Pipeline] {[Pipeline] sh[Pipeline] }[Pipeline] // dir[Pipeline] }[Pipeline] // stage[Pipeline] }$ docker stop --time=1 baa0c2d74c1fdc4944eb4e0bb5eb57f8435caac1a2e28ab562140bb3e0daaf38$ docker rm -f baa0c2d74c1fdc4944eb4e0bb5eb57f8435caac1a2e28ab562140bb3e0daaf38[Pipeline] // withDockerContainer[Pipeline] }[Pipeline] // withEnv[Pipeline] }[Pipeline] // node[Pipeline] End of PipelineGitHub has been notified of this commit’s build resultjava.nio.file.AccessDeniedException: /var/www@tmp at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) at sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384) at java.nio.file.Files.createDirectory(Files.java:674) at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781) at java.nio.file.Files.createDirectories(Files.java:767) at hudson.FilePath.mkdirs(FilePath.java:3273) at hudson.FilePath.access$1300(FilePath.java:213) at hudson.FilePath$Mkdirs.invoke(FilePath.java:1254) at hudson.FilePath$Mkdirs.invoke(FilePath.java:1250) at hudson.FilePath.act(FilePath.java:1078) at hudson.FilePath.act(FilePath.java:1061) at hudson.FilePath.mkdirs(FilePath.java:1246) at org.jenkinsci.plugins.durabletask.FileMonitoringTask$FileMonitoringController.(FileMonitoringTask.java:174) at org.jenkinsci.plugins.durabletask.BourneShellScript$ShellController.(BourneShellScript.java:200) at org.jenkinsci.plugins.durabletask.BourneShellScript$ShellController.(BourneShellScript.java:192) at org.jenkinsci.plugins.durabletask.BourneShellScript.launchWithCookie(BourneShellScript.java:110) at org.jenkinsci.plugins.durabletask.FileMonitoringTask.launch(FileMonitoringTask.java:99) at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.start(DurableTaskStep.java:278) at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:270) at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:178) at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:122) at sun.reflect.GeneratedMethodAccessor312.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1213) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022) at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:42) 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:157) at org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:23) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:155) at 

[JIRA] (JENKINS-33510) dir('foo') inside "docker.image().inside{}" does not affect CWD of launched processes

2019-01-02 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi edited a comment on  JENKINS-33510  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: dir('foo') inside "docker.image().inside{}" does not affect CWD of launched processes   
 

  
 
 
 
 

 
 [~duemir] I have Docker Pipeline plugin 1.17, and Docker version 18.09.0. And  `sh 'pwd'` still gives me {{  doing dir in [my Jenkinsfile|https: / var / jenkins_home github.com / workspace amcsi /youtube-delete- tracker_cd tracker/blob/723ab7a9fcb508608141abbcd1615740c1d63264/Jenkinsfile.groovy] got me...  {code:java } } rather than my expected Docker workdir which is [Pipeline]  { [Pipeline] stage[Pipeline] {  (Run tests)[Pipeline] dirRunning in /var/www [Pipeline] {[Pipeline] sh[Pipeline] } [Pipeline] // dir[Pipeline] } [Pipeline] // stage[Pipeline] }$ docker stop --time=1 baa0c2d74c1fdc4944eb4e0bb5eb57f8435caac1a2e28ab562140bb3e0daaf38$ docker rm -f baa0c2d74c1fdc4944eb4e0bb5eb57f8435caac1a2e28ab562140bb3e0daaf38[Pipeline] // withDockerContainer[Pipeline] }[Pipeline] // withEnv[Pipeline] }[Pipeline] // node[Pipeline] End of PipelineGitHub has been notified of this commit’s build resultjava . nio.file.AccessDeniedException: /var/www@tmp at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102) at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107) at sun.nio.fs.UnixFileSystemProvider.createDirectory(UnixFileSystemProvider.java:384) at java.nio.file.Files.createDirectory(Files.java:674) at java.nio.file.Files.createAndCheckIsDirectory(Files.java:781) at java.nio.file.Files.createDirectories(Files.java:767) at hudson.FilePath.mkdirs(FilePath.java:3273) at hudson.FilePath.access$1300(FilePath.java:213) at hudson.FilePath$Mkdirs.invoke(FilePath.java:1254) at hudson.FilePath$Mkdirs.invoke(FilePath.java:1250) at hudson.FilePath.act(FilePath.java:1078) at hudson.FilePath.act(FilePath.java:1061) at hudson.FilePath.mkdirs(FilePath.java:1246) at org.jenkinsci.plugins.durabletask.FileMonitoringTask$FileMonitoringController.(FileMonitoringTask.java:174) at org.jenkinsci.plugins.durabletask.BourneShellScript$ShellController.(BourneShellScript.java:200) at org.jenkinsci.plugins.durabletask.BourneShellScript$ShellController.(BourneShellScript.java:192) at org.jenkinsci.plugins.durabletask.BourneShellScript.launchWithCookie(BourneShellScript.java:110) at org.jenkinsci.plugins.durabletask.FileMonitoringTask.launch(FileMonitoringTask.java:99) at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.start(DurableTaskStep.java:278) at org.jenkinsci.plugins.workflow.cps.DSL.invokeStep(DSL.java:270) at org.jenkinsci.plugins.workflow.cps.DSL.invokeMethod(DSL.java:178) at org.jenkinsci.plugins.workflow.cps.CpsScript.invokeMethod(CpsScript.java:122) at sun.reflect.GeneratedMethodAccessor312.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1213) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1022) at org.codehaus.groovy.runtime.callsite.PogoMetaClassSite.call(PogoMetaClassSite.java:42) 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:157) at org.kohsuke.groovy.sandbox.GroovyInterceptor.onMethodCall(GroovyInterceptor.java:23) at 

[JIRA] (JENKINS-33510) dir('foo') inside "docker.image().inside{}" does not affect CWD of launched processes

2019-01-02 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi commented on  JENKINS-33510  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: dir('foo') inside "docker.image().inside{}" does not affect CWD of launched processes   
 

  
 
 
 
 

 
 Denys Digtiar I have Docker Pipeline plugin 1.17, and Docker version 18.09.0. And `sh 'pwd'` still gives me /var/jenkins_home/workspace/youtube-delete-tracker_cd rather than my expected Docker workdir which is /var/www.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-55351) docker.build().inside() not run "inside" in Jenkins within Docker

2018-12-31 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi closed an issue as Duplicate  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-55351  
 
 
  docker.build().inside() not run "inside" in Jenkins within Docker   
 

  
 
 
 
 

 
Change By: 
 Attila Szeremi  
 
 
Status: 
 Open Closed  
 
 
Resolution: 
 Duplicate  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-55351) docker.build().inside() not run "inside" in Jenkins within Docker

2018-12-31 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi commented on  JENKINS-55351  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: docker.build().inside() not run "inside" in Jenkins within Docker   
 

  
 
 
 
 

 
 Closing this issue in favor of JENKINS-33510. It turns out that I only thought that that the commands were run on the host, but what I didn't know was that Jenkins mounted the exact same folder for the job into the container and cd'd into it for me (which I didn't expect nor want).  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-33510) dir('foo') inside "docker.image().inside{}" does not affect CWD of launched processes

2018-12-31 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi commented on  JENKINS-33510  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: dir('foo') inside "docker.image().inside{}" does not affect CWD of launched processes   
 

  
 
 
 
 

 
 This ticket is supposedly resolved... but then what do I need to write to make sure the `sh` commands are run in the correct working directory?    
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-55351) docker.build().inside() not run "inside" in Jenkins within Docker

2018-12-28 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-55351  
 
 
  docker.build().inside() not run "inside" in Jenkins within Docker   
 

  
 
 
 
 

 
Change By: 
 Attila Szeremi  
 

  
 
 
 
 

 
 My Jenkins is within a Docker container, and I try to run {{docker.build(...).inside(...)  }} in it, but the inside bit does _not_ run within the newly built container}}{{ {{ . I know, because  {{ pwd}} gives me:  {{/var/jenkins_home/workspace/youtube-delete-tracker_jenkins}} which is clearly the Jenkins container.I've tried this both in imperative and declarative style.I have a lot more details in a StackOverflow question: [https://stackoverflow.com/questions/53950128/jenkins-within-docker-dockerfile-agent-happens-outside-new-container]  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-55351) docker.build().inside() not run "inside" in Jenkins within Docker

2018-12-28 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-55351  
 
 
  docker.build().inside() not run "inside" in Jenkins within Docker   
 

  
 
 
 
 

 
Change By: 
 Attila Szeremi  
 

  
 
 
 
 

 
 My Jenkins is within a Docker container, and I try to run {{docker.build(...).inside(...) }}in it, but the inside bit does _not_ run within the newly built  containe  container }} r {{{{ . I know, because {{pwd}} gives me:  {{/var/jenkins_home/workspace/youtube-delete-tracker_jenkins}} which is clearly the Jenkins container.I've tried this both in imperative and declarative style.I have a lot more details in a StackOverflow question: [https://stackoverflow.com/questions/53950128/jenkins-within-docker-dockerfile-agent-happens-outside-new-container]  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-55351) docker.build().inside() not run "inside" in Jenkins within Docker

2018-12-28 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-55351  
 
 
  docker.build().inside() not run "inside" in Jenkins within Docker   
 

  
 
 
 
 

 
Change By: 
 Attila Szeremi  
 

  
 
 
 
 

 
 My Jenkins is within a Docker container, and I try to run {{docker.build(...).inside(...) }}in it, but the inside bit does _not_ run within the newly built  container  containe}}r . I know, because {{pwd}} }}  gives me:  {{/var/jenkins_home/workspace/youtube-delete-tracker_jenkins}} which is clearly the Jenkins container.I've tried this both in imperative and declarative style.I have a lot more details in a StackOverflow question: [https://stackoverflow.com/questions/53950128/jenkins-within-docker-dockerfile-agent-happens-outside-new-container]  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-55351) docker.build().inside() not run "inside" in Jenkins within Docker

2018-12-28 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-55351  
 
 
  docker.build().inside() not run "inside" in Jenkins within Docker   
 

  
 
 
 
 

 
Change By: 
 Attila Szeremi  
 

  
 
 
 
 

 
 My Jenkins is within a Docker container, and I try to run {{docker.build(...).inside(...) }}in it, but the inside bit does _not_ run within the newly built container. I know, because {{pwd}} }}  gives me:  {{/var/jenkins_home/workspace/youtube-delete-tracker_jenkins}} which is clearly the Jenkins container.I've tried this both in imperative and declarative style.I have a lot more details in a StackOverflow question: [https://stackoverflow.com/questions/53950128/jenkins-within-docker-dockerfile-agent-happens-outside-new-container]  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-52493) Declarative: Steps don't run inside container with "dockerfile true"

2018-12-28 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi commented on  JENKINS-52493  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Declarative: Steps don't run inside container with "dockerfile true"   
 

  
 
 
 
 

 
 And I'm getting the same issue even if I'm running Jenkins outside of a container, and on my host.  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-55351) docker.build().inside() not run "inside" in Jenkins within Docker

2018-12-28 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi updated an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-55351  
 
 
  docker.build().inside() not run "inside" in Jenkins within Docker   
 

  
 
 
 
 

 
Change By: 
 Attila Szeremi  
 

  
 
 
 
 

 
 My Jenkins is within a Docker container, and I try to run  `  {{ docker.build(...).inside(...) `  }}  in it, but the inside bit does _not_ run within the newly built container. I know, because  `  {{ pwd ` }}   gives me:   `  {{ /var/jenkins_home/workspace/youtube-delete-tracker_jenkins ` }}  which is clearly the Jenkins container.I 've tried this both in imperative and declarative style.I  have a lot more details in a StackOverflow question: [https://stackoverflow.com/questions/53950128/jenkins-within-docker-dockerfile-agent-happens-outside-new-container]  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-55351) docker.build().inside() not run "inside" in Jenkins within Docker

2018-12-28 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi created an issue  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
 Jenkins /  JENKINS-55351  
 
 
  docker.build().inside() not run "inside" in Jenkins within Docker   
 

  
 
 
 
 

 
Issue Type: 
  Bug  
 
 
Assignee: 
 Unassigned  
 
 
Components: 
 docker-workflow-plugin  
 
 
Created: 
 2018-12-28 13:42  
 
 
Priority: 
  Minor  
 
 
Reporter: 
 Attila Szeremi  
 

  
 
 
 
 

 
 My Jenkins is within a Docker container, and I try to run `docker.build(...).inside(...)` in it, but the inside bit does not run within the newly built container. I know, because `pwd` gives me:  `/var/jenkins_home/workspace/youtube-delete-tracker_jenkins` which is clearly the Jenkins container. I have a lot more details in a StackOverflow question: https://stackoverflow.com/questions/53950128/jenkins-within-docker-dockerfile-agent-happens-outside-new-container  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

[JIRA] (JENKINS-52493) Declarative: Steps don't run inside container with "dockerfile true"

2018-12-27 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi edited a comment on  JENKINS-52493  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Declarative: Steps don't run inside container with "dockerfile true"   
 

  
 
 
 
 

 
 I'm getting pretty much the  exact  same issue, but with trying to run PHP tests rather than node ones. Although for me it says "Jenkins seems to be running inside container" (which is true). Any solutions?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[JIRA] (JENKINS-52493) Declarative: Steps don't run inside container with "dockerfile true"

2018-12-27 Thread att...@szeremi.org (JIRA)
Title: Message Title


 
 
 
 

 
 
 

 
   
 Attila Szeremi commented on  JENKINS-52493  
 

  
 
 
 
 

 
 
  
 
 
 
 

 
  Re: Declarative: Steps don't run inside container with "dockerfile true"   
 

  
 
 
 
 

 
 I'm getting pretty much the exact same issue, but with trying to run PHP tests rather than node ones. Any solutions?  
 

  
 
 
 
 

 
 
 

 
 
 Add Comment  
 

  
 

  
 
 
 
  
 

  
 
 
 
 

 
 This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)  
 

  
 

   





-- 
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.