[JIRA] (JENKINS-56215) git submodule support
Title: Message Title Raphael Höser commented on JENKINS-56215 Re: git submodule support After digging around in the code from warnings-ng I can say that each issue in a report has a "getFolder()" method which returns the folder for the file of that issue. In my opinion this should be solved at an git-forensics-plugin level or even better in jgit (git implementation used by git-forensics-plugin). Sadly jgit is unrelated to this project and I didn't find an issue tracker for it. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.197774.1550660208000.20954.1588584900258%40Atlassian.JIRA.
[JIRA] (JENKINS-56215) git submodule support
Title: Message Title Raphael Höser commented on JENKINS-56215 Re: git submodule support If I understand it correctly you somehow have the filepath in any shape or form which you pass to the GitBlamer. The Warnings-ng plugin shows this as "Folders" in the report. This information could be used. A also created an issue which was marked as duplicate where I saw the problem on the git blamer and not the warnings-ng side, because they also can resolve this problem by splitting the filename and the path and doing what I described. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.197774.1550660208000.20917.1588582620278%40Atlassian.JIRA.
[JIRA] (JENKINS-56215) git submodule support
Title: Message Title Raphael Höser commented on JENKINS-56215 Re: git submodule support You're currently doing something like "git blame /". If you change this behavior to "cd ; git blame " this would always work for all files correctly. (Also this would solve a problem if the warnings come from multiple repos, which are not submodules, but checked out seperately) The only downside is the (in my opinion minnimal) performance hit for cding into each directory. Add Comment This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.197774.1550660208000.20871.1588576440285%40Atlassian.JIRA.
[JIRA] (JENKINS-62119) Warnings Next Generation support Git Submodules
Title: Message Title Raphael Höser created an issue Jenkins / JENKINS-62119 Warnings Next Generation support Git Submodules Issue Type: Improvement Assignee: Ulli Hafner Components: git-forensics-plugin, warnings-ng-plugin Created: 2020-04-30 10:46 Environment: Jenkins ver. 2.204.4 Warnings Next Generation 7.2.2 Git-Forensics 0.6.0 Labels: plugin git Priority: Major Reporter: Raphael Höser Given that we have the following repo structure: _/ And we call the build in so the warnings paths are relative to , git blame doesn't work because the blame information is in . A possible solution would be to do an aequivalent to the following: Instead of: "git blame /path/to/file" do: "cd /path/to ; git blame file" That way the correct would always be selected to retrieve the blame info (a minor performance hit is possible).
[JIRA] (JENKINS-61709) Map.get("${var}") returns null
Title: Message Title
Raphael Höser commented on JENKINS-61709
Re: Map.get("${var}") returns null
Just in case someone stumbles upon this: you can use map["key_${id}"] since this works fine. I created this issue, because I wanted to use get with a default parameter and the workaround is way more ugly with if tmp == null.
Add Comment
This message was sent by Atlassian Jira (v7.13.12#713012-sha1:6e07c38)
--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.205534.1585316713000.2798.1585574340057%40Atlassian.JIRA.
[JIRA] (JENKINS-61709) Map.get("${var}") returns null
Title: Message Title
Raphael Höser created an issue
Jenkins / JENKINS-61709
Map.get("${var}") returns null
Issue Type:
Bug
Assignee:
Unassigned
Components:
pipeline
Created:
2020-03-27 13:45
Environment:
Jenkins 2.204.4 LTS
Labels:
pipeline jenkins
Priority:
Minor
Reporter:
Raphael Höser
When accessing a map key via .get() with a var replacement in the key the get operation always returns null. Example snippet: def map = ["key_identifier": "test"] def id = "identifier" def resA = map.get("key_identifier") print(resA) def resB = map.get("key_${id}") print(resB) This will return in the output: Test null
Add Comment
[JIRA] (JENKINS-57256) Kubernetes plugin Windows agent support
Title: Message Title Raphael Höser commented on JENKINS-57256 Re: Kubernetes plugin Windows agent support In my opinion this would be solved, if jenkins would provide a jnlp image based on the openjdk:8-windowsservercore image. This would make the jnlp image windows friendly. By the way: If your windows node allows running windows and linux containers side by side I think no changes are necessary. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.199020.1556632253000.12663.1563305760170%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36776) Support Windows Server Containers
Title: Message Title Raphael Höser commented on JENKINS-36776 Re: Support Windows Server Containers Guillaume Egles I don't know whether you really need direct docker support, but we moved onto using Kubernetes in our setup - you just need a windows based jnlp container which you insert as "jnlp" into your pod and then you can have windows based kubernetes pods. That way you need one Linux Kube Master Node in your cluster and after that you can mix and match windows and linux containers in seperate pods as you need for your builds. Note for high scalings: Avoid running Linux Containers on Windows nodes, since this is possible with current builds, but the windows process scheduler doesn't handle high core counts well (up to 16 works totally fine). 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.172815.1468881746000.7158.1562773381150%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-57256) Kubernetes plugin Windows agent support
Title: Message Title Raphael Höser commented on JENKINS-57256 Re: Kubernetes plugin Windows agent support Olivier Vernin Since you need to create two pods to build on windows and linux you can use two different containers as jnlp containers. You create two podTemplates with each a container named jnlp. In the containerTemplate you set the image to thw jnlp image for your platform (on linux you can also not create a jnlp container to use the default, but be aware of inheritance). That way you can have a linux and a windows jnlp node in your cluster. If I didn't understand you correctly and you meant something else with "your linux node will not use the correct docker image anymore" please clarify. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.199020.1556632253000.675.1560516240209%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-57256) Kubernetes plugin Windows agent support
Title: Message Title Raphael Höser commented on JENKINS-57256 Re: Kubernetes plugin Windows agent support If you create a container with the name "jnlp" you prevent the default jnlp image from starting - so you can create your own jnlp windows image which takes it place. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.199020.1556632253000.8616.1558526220133%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-48518) Docker Pipeline: invalid volume specification with Windows slave and Linux master
Title: Message Title Raphael Höser commented on JENKINS-48518 Re: Docker Pipeline: invalid volume specification with Windows slave and Linux master Larry Silverman Sadly not really - the github issue had some ideas with writing libraries, which call the docker commands directly, but that doesn't provide the same feature set. Maybe it is possible to use a kubernetes cluster to use docker on windows. (We switched to jenkins in kubernetes, but we also now use wine in the most part with linux hosts) 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.187135.1513098516000.2973.1558091940725%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-36776) Support Windows Server Containers
Title: Message Title Raphael Höser commented on JENKINS-36776 Re: Support Windows Server Containers Jesse Glick commented under that pull request saying, that the Plugin shoud better be left untouched to prevent "a critical regression". Even though I do not share his opinion on leaving the plugin untouched, I get his point - especially because the plugin has no active maintainer - and appreciate, that he even looked into this. So the current state of this problem shouldn't be "In Progress" anymore, as the development won't go on in the foreseeable future. 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-36776) Support Windows Server Containers
Title: Message Title Raphael Höser stopped work on JENKINS-36776 Change By: Raphael Höser Status: In Progress Open 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-34454) Add support for Docker-Toolbox/Windows
Title: Message Title Raphael Höser commented on JENKINS-34454 Re: Add support for Docker-Toolbox/Windows I made some research on this, because we need windows containers in our build chain and I came to this findings: The nohup isn't a big deal, because you can work around it by installing a sh environment on windows (e.g. git with git-scm and add C:\Program Files\Git\usr\bin to the PATH variable). This isn't a nice workaround, but the real problem is the way Jenkins calls docker! Jenkins passes a "z" flag in the volume description, which isn't supported by docker for windows and throws an error. Fixing this, I tried to write a bat and a sh script, which remove the "z" flag and naming them "docker.bat" and "docker" (I renamed docker.exe to docker-client.exe). Running from sh and cmd I was able to run all docker commands, but Jenkins complained about not finding the file. Caused: java.io.IOException: Cannot run program "docker": CreateProcess error=2, The system cannot find the file specified In general I think, that the plugin shouldn't provide the "z" flag outside of an SELinnux environment and that would solve the problem. Add Comment This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396) -- 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-36776) Support Windows Server Containers
Title: Message Title Raphael Höser commented on JENKINS-36776 Re: Support Windows Server Containers The nohup isn't a big deal, because you can work around it by installing a sh environment on windows (e.g. git with git-scm and add C:\Program Files\Git\usr\bin to the PATH variable). This isn't a nice workaround, but the real problem is the way Jenkins calls docker! Jenkins passes a "z" flag in the volume description, which isn't supported by docker for windows and throws an error. Fixing this, I tried to write a bat and a sh script, which remove the "z" flag and naming them "docker.bat" and "docker" (I renamed docker.exe to docker-client.exe). Running from sh and cmd I was able to run all docker commands, but Jenkins complained about not finding the file. Caused: java.io.IOException: Cannot run program "docker": CreateProcess error=2, The system cannot find the file specified In general I think, that the plugin shouldn't provide the "z" flag outside of an SELinnux environment and that would solve the problem. Add Comment This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396) -- 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-48518) Docker Pipeline: invalid volume specification with Windows slave and Linux master
Title: Message Title Raphael Höser commented on JENKINS-48518 Re: Docker Pipeline: invalid volume specification with Windows slave and Linux master ... -v C:\Jenkins\workspace\dummy-windows_dockerfile-2QPBAXYBKIKABK3TWL47EDMYETQTPG4UEJF46JIKPPRRDECSXV4Q:C:\Jenkins\workspace\dummy-windows_dockerfile-2QPBAXYBKIKABK3TWL47EDMYETQTPG4UEJF46JIKPPRRDECSXV4Q:rw,z According to my research the problem isn't the C: filepath, as windows has no Problems working with it, but the "z" flag at the end! When I remove that flag and run the docker command like it's given in the Jenkins Log everything works fine, but when you add the z flag (even when it's the only one) it makes the path description invalid for Docker on windows. I currently don't have a linux machine not running SELinux on hand to test it on other Linux derivates, but I think this flag shouldn't always be added to the volume specification. Add Comment This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396) -- 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.
