[JIRA] (JENKINS-26100) SCM steps should return revision state
Title: Message Title Norbert Lange commented on JENKINS-26100 Re: SCM steps should return revision state "Which docs send you in the wrong direction?" Plain Pipelines using "inline Jenkinsfiles" seem to be largely ignored from all docs, similarly you often need to checkout multiple sources. If this is not explicitly mentioned, one would assume it works the same. The step returns a map of env variables already, so pushing those into withEnv would be a natural fit. That there is no "declarative" way to do this, is weird. I had many Problems with scripted pipelines, particularly when it comes to error handling (storing artifacts will silently fail, then cause an error at the end of the pipeline?) that I would want to stay clear of those. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.159680.1418774393000.7239.1581438063644%40Atlassian.JIRA.
[JIRA] (JENKINS-26100) SCM steps should return revision state
Title: Message Title Norbert Lange edited a comment on JENKINS-26100 Re: SCM steps should return revision state Yeah, I posted the entire declarative pipeline couple posts before.I managed to get the variables with a script block, but I expected that there would be a way to get to this without breaking into scripting mode.What is a default checkout: where would the pipeline know the url from?Does *withCheckout* exist? its referenced in this thread.Would be nice to get *withEnv* working like I illustrated above.Docs send you completely in the wrong direction unfortunately. Edit: I replied here because this is often referenced as "answer" Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.159680.1418774393000.4175.1581092403085%40Atlassian.JIRA.
[JIRA] (JENKINS-26100) SCM steps should return revision state
Title: Message Title Norbert Lange commented on JENKINS-26100 Re: SCM steps should return revision state Yeah, I posted the entire declarative pipeline couple posts before. I managed to get the variables with a script block, but I expected that there would be a way to get to this without breaking into scripting mode. What is a default checkout: where would the pipeline know the url from? Does withCheckout exist? its referenced in this thread. Would be nice to get withEnv working like I illustrated above. Docs send you completely in the wrong direction unfortunately. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f) -- 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.159680.1418774393000.4073.1581092341720%40Atlassian.JIRA.
[JIRA] (JENKINS-26100) SCM steps should return revision state
Title: Message Title
Norbert Lange commented on JENKINS-26100
Re: SCM steps should return revision state
Mark Waite: No, video is generally a bad idea, and that specific one is not helping at all. Here is the problem in a single paragraph:
checkout()
// returns ""
sh 'echo ${GIT_COMMIT}'
// returns "null"
echo "${env.GIT_COMMIT}"
No environment variables are set.
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
--
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.159680.1418774393000.3623.1581087902538%40Atlassian.JIRA.
[JIRA] (JENKINS-26100) SCM steps should return revision state
Title: Message Title
Norbert Lange commented on JENKINS-26100
Re: SCM steps should return revision state
I might be dense, but I still dont understand how I would do this with a declarative pipeline (without script blocks). Any help here? withCheckout is nowhere to be found the env variables are not set by default:
pipeline {
agent none
stages {
stage('checkout') {
post { always { deleteDir() } }
agent any
steps {
checkout([$class: 'GitSCM',
userRemoteConfigs: [[url: 'https://github.com/docker/for-linux.git']]])
sh 'set'
}
}
}
}
trying to stuff into a withEnv block fails with `java.lang.UnsupportedOperationException: must specify $class with an implementation of interface java.util.List`
pipeline {
agent none
stages {
stage('checkout') {
post { always { deleteDir() } }
agent any
steps {
withEnv(checkout([$class: 'GitSCM',
userRemoteConfigs: [[url: 'https://github.com/docker/for-linux.git']]])) {
sh 'set'
}
}
}
}
}
Jenkins ver. 2.219 (docker alpine installation) git 4.1.1 true git-client 3.1.1 true workflow-scm-step 2.10 true
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-54832) Groovy Parser cannot access console log
Title: Message Title Norbert Lange commented on JENKINS-54832 Re: Groovy Parser cannot access console log Daniel Saier: No I did not knew about this yet, I proposed practically the same thing in JENKINS-44930. Thanks. That seems to be the proper solution for me now, as I prefer feeding just the output from the build command to the warnings-plugin (vs. using the whole log output) 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.195821.1542969482000.17511.1559311500275%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54832) Groovy Parser cannot access console log
Title: Message Title Norbert Lange commented on JENKINS-54832 Re: Groovy Parser cannot access console log I picked the above workaround, as this works with any POSIX shells, credit goes out to: unix.stackexchange.com. the workaround with `set -o pipefail`only works with bash, and therefore does not work if you for ex. use alpine linux. 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.195821.1542969482000.17464.1559309820296%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-44930) Allow sh to return exit status, stdout and stderr all at once
Title: Message Title
Norbert Lange commented on JENKINS-44930
Re: Allow sh to return exit status, stdout and stderr all at once
Fernando Nasser: I would like and prefer a dump into a file into workspace, while also having normal output. I am not sure what you mean by "command", you you mean the pipeline command ("sh"), or the native script? The native script is cumbersome, there might even be different ways with different shells, if you meant the pipeline command then I am all for it. but some other idea would be to use a context wrappers like
output(stdout: "build.log", stderr: "err.log") {
sh 'cmake --build .'
}
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.183003.149756330.13821.1559054763251%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-57712) Allow entering search path for git blame
Title: Message Title
Norbert Lange created an issue
Jenkins / JENKINS-57712
Allow entering search path for git blame
Issue Type:
Improvement
Assignee:
Ulli Hafner
Components:
warnings-ng-plugin
Created:
2019-05-28 11:26
Environment:
Jenkins 2.164.3-alpine via docker Warnings NG Plugin 5.0.0 Analysis plugin 5.1.0
Priority:
Minor
Reporter:
Norbert Lange
The warnings plugin searches the build directory and parents for a git repository, but this fails for out-of-tree-builds.
out-of-tree build is preferred, having for ex. ${WORKSPACE}/src for sources and ${WORKSPACE}/build for build output.
the build runs in the build directory, hence paths are based on it and the warningsplugin should run from this directory
switching across agents/docker containers could make things even harder (need to stash/unstash).
eg. "checkout agent" checks out from git, stashes sources without the .git database (or might make a shallow clone). "build agent" unstashes sources, starts a docker container for the build and runs the warning plugin afterwards. I dont have a perfect solution, but having a parameter for either adding the path to the git repository on disk would help. even better would be to give the plugin the repository + commit information so it can pull more stuff if needed.
[JIRA] (JENKINS-44930) Allow sh to return exit status, stdout and stderr all at once
Title: Message Title Norbert Lange commented on JENKINS-44930 Re: Allow sh to return exit status, stdout and stderr all at once I would really like this to be supported, as the use of the warnings plugin is otherwise really cumbersome and invasive, see JENKINS-54832 for the issue and workaround. The usecase of using the returncode to fail a build using the output for displaying progress re-using the output later in further plugins should be supported by Jenkins natively, and not require workarounds in the buildscripts 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.183003.149756330.13505.1559035922851%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-54833) Warnings Parser fails parsing log
Title: Message Title Norbert Lange commented on JENKINS-54833 Re: Warnings Parser fails parsing log Its not necessary because of security, but rather efficiency and generally avoiding issues (like triggering this bug in files that could simply be ignored). For example I would guess that for builds on docker agents you might try to parse/hash unrelated files from the host and not those inside the container? The less you do, the less trouble there can be. 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-54833) Warnings Parser fails parsing log
Title: Message Title Norbert Lange commented on JENKINS-54833 Re: Warnings Parser fails parsing log ad. 1 What I meant is that you don't show the file, but still try to parse it. ie. decide first if you have any use for the file, do the work only in that case =) 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-54833) Warnings Parser fails parsing log
Title: Message Title Norbert Lange commented on JENKINS-54833 Re: Warnings Parser fails parsing log I changes the source encoding and I now understand the issue (the new fake job still tried to read the files from the real jobs workspace). Some thoughts/inputs: 1) The log contained filenames that did not reside in the workspace and the plugin apparently does try to read and decode them, even if it then decides to do nothing with them. Means it bugged out for no reason [GNU Make + GNU C Compiler (gcc)] Copying affected files to Jenkins' build folder /var/jenkins_home/jobs/ztest/builds/19 [GNU Make + GNU C Compiler (gcc)] -> 0 copied, 2 not in workspace, 0 not-found, 0 with I/O error 2) If the filename points to a exe, DSO or object file, then no encoding setting will help - parsing will always fail (like for linker warnings). I have some custom messages about the object format and a fitting parser - not setting the linenumber or setting it to a negative value could indicate to skip source-file parsing, 3) failing to parse a file should not be an error (just as failing to copying the files is not). 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-54858) Detect working directory from build output
Title: Message Title Norbert Lange updated an issue Jenkins / JENKINS-54858 Detect working directory from build output Change By: Norbert Lange Issue Type: Bug Improvement 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-54858) Detect working directory from build output
Title: Message Title Norbert Lange updated an issue Jenkins / JENKINS-54858 Detect working directory from build output Change By: Norbert Lange This a proposal to generalize the bahaviour of the "Gnu Make + Gnu Gcc Parser". The idea being that: * The functionality is split, do that "Gnu Make" can be enabled independently. This makes sense as it "just" keeps track of the current working directory for resolving relative paths. * To allow other build-systems or manually communicating the working directory to Jenkins from scripts, some "directory change notification" regex could be specified (potentially more with multiple fields for complex builds using multiple build systems). "Gnu Make" would then be just a predefined regex.IMHO this would not be hard to do, and the "Next Gen" plugin would be a natural fit for such a change 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-54833) Warnings Parser fails parsing log
Title: Message Title Norbert Lange commented on JENKINS-54833 Re: Warnings Parser fails parsing log Hmm, just to add: do you try to parse the source-code files? What happens if filename relates not to a text-file but an executable/DSO (like with linker-warnings/errors). I tried setting up a "fake-build" which just outputs the log I attached, no source-code involved at all. The issue stays the same, so atleast my problem is not related to the source-code encodings. 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-54858) Detect working directory from build output
Title: Message Title Norbert Lange created an issue Jenkins / JENKINS-54858 Detect working directory from build output Issue Type: Bug Assignee: Ulli Hafner Components: warnings-ng-plugin Created: 2018-11-26 11:07 Environment: Jenkins ver. 2.138.3 (Docker Hub) Wanings NG 1.0.0-beta5 Priority: Minor Reporter: Norbert Lange This a proposal to generalize the bahaviour of the "Gnu Make + Gnu Gcc Parser". The idea being that: The functionality is split, do that "Gnu Make" can be enabled independently. This makes sense as it "just" keeps track of the current working directory for resolving relative paths. To allow other build-systems or manually communicating the working directory to Jenkins from scripts, some "directory change notification" regex could be specified (potentially more with complex builds using multiple build systems). "Gnu Make" would then be just a predefined regex. IMHO this would not be hard to do, and the "Next Gen" plugin would be a natural fit for such a change
[JIRA] (JENKINS-54833) Warnings Parser fails parsing log
Title: Message Title Norbert Lange commented on JENKINS-54833 Re: Warnings Parser fails parsing log I specified nothing, and the log consists entirely of ASCII Characters. Specifying UTF-8 did not make a difference either. I run the Jenkins server on musl (jenkins/jenkins:2.138.3-alpine from docker hub), while the builder is based on glibc (debian 8) and has locale/encoding "en_US.UTF-8". musl has some differences to glibc when it comes to locale handling (and no "locale" tool), maybe that's relevant. 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-54833) Warnings Parser fails parsing log
Title: Message Title Norbert Lange created an issue Jenkins / JENKINS-54833 Warnings Parser fails parsing log Issue Type: Bug Assignee: Ulli Hafner Attachments: build.tar.xz Components: warnings-ng-plugin Created: 2018-11-23 10:49 Environment: Jenkins ver. 2.138.3 (Docker Hub) Wanings NG 1.0.0-beta5 Priority: Major Reporter: Norbert Lange The log is attached, this is a freestyle job and 2 warnings parsers are configured (Make + GCC and a custom Groovy parser). After the build, the plugin fails with the following output, while also marking the build as failure. Archiving artifacts Skipping issues blame since Git is the only supported SCM up to now. [GNU Make + GNU C Compiler (gcc)] Searching for all files in '/home/build/jenkins/jenkins/workspace/poe-baseline.binaries.tfs' that match the pattern 'build.log' [GNU Make + GNU C Compiler (gcc)] -> found 1 file [GNU Make + GNU C Compiler (gcc)] Successfully parsed file /home/build/jenkins/jenkins/workspace/poe-baseline.binaries.tfs/build.log [GNU Make + GNU C Compiler (gcc)] -> found 3 issues (skipped 2022 duplicates) ERROR: Build step failed with exception java.nio.charset.MalformedInputException: Input length = 1 at java.nio.charset.CoderResult.throwException(CoderResult.java:281) at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:339) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178) at
[JIRA] (JENKINS-54832) Groovy Parser cannot access console log
Title: Message Title Norbert Lange created an issue Jenkins / JENKINS-54832 Groovy Parser cannot access console log Issue Type: Bug Assignee: Ulli Hafner Components: warnings-plugin Created: 2018-11-23 10:38 Environment: Jenkins ver. 2.138.3 (Docker Hub) Wanings NG 1.0.0-beta5 Priority: Minor Reporter: Norbert Lange (discussion is split from JENKINS-54759) Issue console parsers currently run on the master and for security reasons, this excludes the customizable Groovy Parser. for an user this is surprising and adding a custom warning parser will need changes in the buildscript to dump output to a log file, ideally adding a parser would not otherwise affect existing jobs . not piping would be the most clear, and similar to the scripts you would run on a local build piping it just to a file will remove all visible status during execution naively splitting it (eg. | tee file.log) will mean the error state of the script doing the build will vanish. see here additionally storing and restoring the errors state of the script adds boilerplate code just to reiterate how invasive this change is, here is my current (POSIX Shell) workaround with variant 4): before: sh buildscript.sh ARGS...
[JIRA] (JENKINS-54759) Groovy Parsers - improve help text
Title: Message Title Norbert Lange updated an issue Jenkins / JENKINS-54759 Groovy Parsers - improve help text Change By: Norbert Lange Summary: Groovy Parsers - improve help text Issue Type: Bug Improvement 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-54759) Groovy Parsers
Title: Message Title Norbert Lange commented on JENKINS-54759 Re: Groovy Parsers Scanning of the console log is done on the master currently, all other files are scanned on the agentDo you have a better idea? I would try to move all processing to the agent(s), its not obvious to me why this split exists (has to exist). Can’t you pipe your log output to a file on the agent? Yes I can, but not without issues. Some variants: not piping would be the most clear, and similar to the scripts you would run on a local build piping it just to a file will remove all visible status during execution naively splitting it (eg. | tee file.log) will mean the error state of the script doing the build will vanish. see here additionally storing and restoring the errors state of the script adds boilerplate code That's why I asked about a recommendation (a bug tracker is the wrong place, but you don't have a forum?) As for the split, keep the help-text issue here, and handle the rest in JENKINS-52237? Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
[JIRA] (JENKINS-54759) Groovy Parsers
Title: Message Title Norbert Lange created an issue Jenkins / JENKINS-54759 Groovy Parsers Issue Type: Bug Assignee: Ulli Hafner Components: warnings-plugin Created: 2018-11-21 17:35 Environment: Jenkins ver. 2.138.3 (Docker Hub) Wanings NG 1.0.0-beta5 Priority: Minor Reporter: Norbert Lange The configuration and functionality is currently lacking 1) The help text under the Static Analysis Tool configuration (Freestyle job), should add that the own configured Parser can be found if "Groovy Parser" is selected For each static analysis tool a dedicated parser will be used to read the report files. If your tool is not yet supported then you can create your own parser in the system configuration. 2) Groovy Parser cant scan console log output ?! Seems a bit weird to me that a single scanner has this limitation, is this getting fixed, or is there a recommendation to start writing logs to a file first? (As in best practices, generally for Jenkins or specific to this plugin). like using "2>&1 | tee some.log" on commands? FATAL: Static analysis tool Groovy Parser cannot scan console log output, please define a file pattern
[JIRA] (JENKINS-39990) favorite plugin causes Exception at user/name/configure page
Title: Message Title Norbert Lange created an issue Jenkins / JENKINS-39990 favorite plugin causes Exception at user/name/configure page Issue Type: Improvement Assignee: Larry Shatzer, Jr. Components: favorite-plugin Created: 2016/Nov/23 10:52 PM Environment: Jenkins 2.33 favorite:2.0.3 ssh-credentials:1.12 Priority: Major Reporter: Norbert Lange The favorite plugin 2.0.3 causes an exception on the confiugration page for users, breaking other fields like the shh credentials on this page. Downgrade to 2.0.2 removes the issue javax.servlet.ServletException: org.apache.commons.jelly.JellyTagException: jar:file:/var/jenkins_home/plugins/favorite/WEB-INF/lib/favorite.jar!/hudson/plugins/favorite/user/FavoriteUserProperty/config.jelly:4:66: No page found '/hudson/plugins/favorite/assets/css.jelly' for class hudson.model.User at org.kohsuke.stapler.jelly.JellyFacet$1.dispatch(JellyFacet.java:103) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.MetaClass$5.doDispatch(MetaClass.java:236) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:746) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:876) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649) at org.kohsuke.stapler.Stapler.service(Stapler.java:238) at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812) at
[JIRA] (JENKINS-38147) Allow per-job Parameters for Multi-Branch
Title: Message Title Norbert Lange created an issue Jenkins / JENKINS-38147 Allow per-job Parameters for Multi-Branch Issue Type: Improvement Assignee: Matthew DeTullio Components: multi-branch-project-plugin Created: 2016/Sep/12 4:40 PM Environment: Jenkins 2.22 Pipeline: Multibranch 2.8 Priority: Minor Reporter: Norbert Lange Hello, I have following requirements: I want several Jobs for a Project with multiple Branches (or even Repositories) Integration: Build everything (with flags for faster compilation), don`t archive anything Staging: Allow a set of Parameters to control the build (what & how), Archive the output files. Usefull for building feature Branches for testing and verifying bug fixes. Release: Build the release artifacts with release settings. Archive release artifacts and sources Changelogs are preserved for branches. Incremential Builds should be possible To solve this, I would need to create 3 multibranch jobs for the same sources - and a way to differenciate between them I could work with job names (eg. adding .staging to the name) and parse the
[JIRA] (JENKINS-37156) Push notification from pipeline repositories doesnt take credentials
Title: Message Title Norbert Lange closed an issue as Not A Defect Jenkins / JENKINS-37156 Push notification from pipeline repositories doesnt take credentials Change By: Norbert Lange Status: Open Closed Resolution: Not A Defect Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-37156) Push notification from pipeline repositories doesnt take credentials
Title: Message Title Norbert Lange commented on JENKINS-37156 Re: Push notification from pipeline repositories doesnt take credentials Ok, it was my fault. I added a SSH Credential with the same name, which got a different automatically generated UID. The build itself ran on another machine, which has .ssh credentials already configured. Only on Jenkins the credentials where needed and wrong. I like some answers for #1 and #3 still. What are recommended practices? Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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-37156) Push notification from pipeline repositories doesnt take credentials
Title: Message Title Norbert Lange created an issue Jenkins / JENKINS-37156 Push notification from pipeline repositories doesnt take credentials Issue Type: Bug Assignee: Mark Waite Components: git-plugin Created: 2016/Aug/03 9:35 PM Environment: Jenkins 2.16, git-plugin 2.5.3 (also tested on 3.0.0b2) Priority: Major Reporter: Norbert Lange Setting up a Pipeline Job on a new Jenkins installation shows some problems with push notifications. The job ist configured to pull a Repository containing the Jenkinsfile and -scripts. The script checks out 4 git repositories, a single one is configured to affect changelog and polling. Interestingly (and as afar as i know undocumented) the webhook would work - I dont know how exactly and under what circumstances ( I guess a previously successfull build?). But the polling then fails to use the credentials that where previously used (it seems to somehow store the correct path and browser). Its unclear to me me, if this scheme should even work, and what the recommended practice would be. In the job configuration I have to specify the repository with the Jenkins-files (which ideally would not end up polled or in the changelog). The I have a cannonical repository that should be polled, which gets cloned/pulled from the former scripts The webhook kinda works, but some information (path, browser) seems to be saved and atleast the credentials seem to be missing. On a different Jenkins server it works, likely because added a ssh key to the linux-account runninng jenkins Seems to be impossible to
[JIRA] [git-plugin] (JENKINS-34698) Allow picking a Browser for Git
Title: Message Title Norbert Lange edited a comment on JENKINS-34698 Re: Allow picking a Browser for Git I think the majority of the mappings could be catched with this transformation:aproto://\[auser@](ahost.xz\[:aport]/\[aprefix/])path/to/repo[.git] -> (bproto://bhost.xz\[:bport]/\[bprefix/]\[otherstuff])path/to/repoie. Take the substring from a clone URL, starting from hostname, ending before the repository path - name this *clonebase* from now on.The rest of the clone URL is the *repositorypath* with a potentially trailing .git removed, together with the *webbase* you can form the *repoUrl* key for a specific "Git Browser" Instance.Your idea of adding the target URL for a normal Browser, could be done in two ways: make the "Git Browser" Classes generate them from the *repoUrl*, or (taking Gitweb as example) add the query portion to the *webbase* and remove it when generating the *repoUrl*.For the examples above, in a map that you can graphically configure in the global settings you`d have these entries:||clonebase||webbase||browser settings||potential other stuff|||mark-pc1.markwaite.net/git/|http://mark-pc1.markwaite.net/gitweb/?p=|\[$class: 'GitWeb']||github.com/|https://github.com/|\[$class: 'GithubWeb']||mark-pc1.markwaite.net:/var/lib/git/|http://mark-pc1.markwaite.net/gitweb/?p=|\[$class: 'GitWeb']||localhost:10022/|http://localhost:10080/|\[$class: 'GogsGit']|\[userRemoteConfigs: \[\[credentialsId: 'aad288c5-ea8e-4484-8e2d-9dc7abab7910']]]||10.99.10.4/|http://10.99.10.4:8080/gitlab/|\[$class: 'Gitlab' , version: '8.7']|ie. git://mark-pc1.markwaite.net/git/foo - > finds clonebase = mark-pc1.markwaite.net/git/, repositorypath = foo, webbase = http://mark-pc1.markwaite.net/gitweb/?p=, browser = \[$class: 'GitWeb'] - > website = webbase + repositorypath = http://mark-pc1.markwaite.net/gitweb/?p=foo - > browserurl = http://mark-pc1.markwaite.net/gitweb-/?p=foo- - > browser = \[$class: 'GitWeb', repoUrl: 'http://mark-pc1.markwaite.net/gitweb'] - > add the browser and "other Stuff" fields to the checkout options (only those that arent explicitely set in a Job)I think a really big portions of the are covered with this rather simple scheme. Of yourse you can always have totally unrelated clone URS and webpages, and existing installations should still use the values specified in the jobs.But it would be a nice way of having a configurable default.* the scp URLs [user@]host.xz:path/to/repo.git/ and raw file URLs /path/to/repo.git/ schould be internally converted to the "protocol URLS" for consistent clone URL syntax and simpler matching. * Matching a *clonebase* needs to take the longest match, so you could override a Server default for single repositories. Add Comment
[JIRA] [git-plugin] (JENKINS-34698) Allow picking a Browser for Git
Title: Message Title Norbert Lange edited a comment on JENKINS-34698 Re: Allow picking a Browser for Git I think the majority of the mappings could be catched with this transformation:aproto://\[auser@](ahost.xz\[:aport]/\[aprefix/])path/to/repo[.git] -> (bproto://bhost.xz\[:bport]/\[bprefix/]\[otherstuff])path/to/repoie. Take the substring from a clone URL, starting from hostname, ending before the repository path - name this *clonebase* from now on.The rest of the clone URL is the *repositorypath* with a potentially trailing .git removed, together with the *webbase* you can form the *repoUrl* key for a specific "Git Browser" Instance.Your idea of adding the target URL for a normal Browser, could be done in two ways: make the "Git Browser" Classes generate them from the *repoUrl*, or (taking Gitweb as example) add the query portion to the *webbase* and remove it when generating the *repoUrl*.For the examples above, in a map that you can graphically configure in the global settings you`d have these entries:||clonebase||webbase||browser settings||potential other stuff|||mark-pc1.markwaite.net/git/|http://mark-pc1.markwaite.net/gitweb/?p=|\[$class: 'GitWeb']||github.com/|https://github.com/|\[$class: 'GithubWeb']||mark-pc1.markwaite.net:/var/lib/git/|http://mark-pc1.markwaite.net/gitweb/?p=|\[$class: 'GitWeb']||localhost:10022/|http://localhost:10080/|\[$class: 'GogsGit']|\[userRemoteConfigs: \[\[credentialsId: 'aad288c5-ea8e-4484-8e2d-9dc7abab7910']]]||10.99.10.4/|http://10.99.10.4:8080/gitlab/|\[$class: ' GitWeb Gitlab ' , version: '8.7']|ie. git://mark-pc1.markwaite.net/git/foo-> finds clonebase = mark-pc1.markwaite.net/git/, repositorypath = foo, webbase = http://mark-pc1.markwaite.net/gitweb/?p=, browser = \[$class: 'GitWeb']-> website = webbase + repositorypath = http://mark-pc1.markwaite.net/gitweb/?p=foo-> browserurl = http://mark-pc1.markwaite.net/gitweb-/?p=foo--> browser = \[$class: 'GitWeb', repoUrl: 'http://mark-pc1.markwaite.net/gitweb'] -> add the browser and "other Stuff" fields to the checkout options (only those that arent explicitely set in a Job) I think a really big portions of the are covered with this rather simple scheme. Of yourse you can always have totally unrelated clone URS and webpages, and existing installations should still use the values specified in the jobs.But it would be a nice way of having a configurable default.* the scp URLs [user@]host.xz:path/to/repo.git/ and raw file URLs /path/to/repo.git/ schould be internally converted to the "protocol URLS" for consistent clone URL syntax and simpler matching. * Matching a *clonebase* needs to take the longest match, so you could override a Server default for single repositories. Add Comment
[JIRA] [git-plugin] (JENKINS-34698) Allow picking a Browser for Git
Title: Message Title Norbert Lange commented on JENKINS-34698 Re: Allow picking a Browser for Git I think the majority of the mappings could be catched with this transformation: aproto://[auser@](ahost.xz[:aport]/[aprefix/])path/to/repo[.git] -> (bproto://bhost.xz[:bport]/[bprefix/][otherstuff])path/to/repo ie. Take the substring from a clone URL, starting from hostname, ending before the repository path - name this clonebase from now on. The rest of the clone URL is the repositorypath with a potentially trailing .git removed, together with the webbase you can form the repoUrl key for a specific "Git Browser" Instance. Your idea of adding the target URL for a normal Browser, could be done in two ways: make the "Git Browser" Classes generate them from the repoUrl, or (taking Gitweb as example) add the query portion to the webbase and remove it when generating the repoUrl. For the examples above, in a map that you can graphically configure in the global settings you`d have these entries: clonebase webbase browser settings potential other stuff mark-pc1.markwaite.net/git/ http://mark-pc1.markwaite.net/gitweb/?p= [$class: 'GitWeb'] github.com/ https://github.com/ [$class: 'GithubWeb'] mark-pc1.markwaite.net:/var/lib/git/
[JIRA] [git-plugin] (JENKINS-34698) Allow picking a Browser for Git
Title: Message Title Norbert Lange commented on JENKINS-34698 Re: Allow picking a Browser for Git Dunno about the implementation cost, but this sound like a rather in-transparent scheme, and not really reflecting the usage. Typically you want to configure a server (and update/change) independent of the jobs using it Wouldn`t it be easiest to add a section in the Jenkins preferences, mapping clone url prefixes to properties than solving the issue on multiple endpoints? Eg. a configuration would look like: 'github.com' = [browser: [$class: 'GitHub', repoUrl: 'http://github.com'] 'localhost:10022' = [browser: [$class: 'GogsGit', repoUrl: 'http://localhost:10080', credentialsId = 'blah' ] '10.99.10.4' = [browser: [$class: 'Gitlab', repoUrl: 'http://10.99.10.4:8080/gitlab, version: '8.7'', credentialsId = 'blah2' ] That would make migrations and upgrades of local servers very easy, while the predefined stuff like Github would be visible (and edible, like adding credentials?) to the user and not some magic in the plugin. Maybe you could even use a second table, to map names to servers or repositories, that way jobs are completely ignorant of the source repository - quite similar to how users only deal with "origin" in most local git repositories Add Comment This message was sent by Atlassian JIRA (v6.4.2#64017-sha1:e244265) -- 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] [multi-branch-project-plugin] (JENKINS-34698) Allow picking a Browser for Git
Title: Message Title
Norbert Lange created an issue
Jenkins / JENKINS-34698
Allow picking a Browser for Git
Issue Type:
Improvement
Assignee:
Matthew DeTullio
Components:
multi-branch-project-plugin
Created:
2016/May/09 10:14 PM
Priority:
Minor
Reporter:
Norbert Lange
Hello,
Currently there is no way to specify a Browser for linking to the commit/files/diffs for changes. Either there should be a way to specify the Browser in the Piepeline configuration, or there should be a way to - for example - add the browser to the scm variable.
A third option would be to allow configuring a global mapping between the "host:port" of a connection to a browser. I coded such a scheme and it works for normal Pipelines, but it doesnt for Multibranch Pipeline. With this one could set a mapping from the clone-urls to the projects web-url and additional stuff like browser information
@NonCPS
def call(name) {
def servermap = [
'localhost:10022': [browser: [$class: 'GogsGit', repoUrl: 'http://localhost:10080'],
credentialsId: 'aad288c5-ea8e-4484-8e2d-9dc7abab7910', ],
]
def repomap = [
'tools': [git: 'ssh://git@localhost:10022/mn/tools.git', ],
'firmware': [git: 'ssh://git@localhost:10022/mn/firmware.git', ],
'jenkins-jobscripts': [git: 'ssh://git@localhost:10022/mn/jenkinspipeline.git', ],
]
def repo = repomap[name]
if (repo != null) {
repo = repo.clone()
def url = ""
if (url != null) {
[JIRA] [script-security-plugin] (JENKINS-34658) Whitelist more Functions for trivial operations on builtin types
Title: Message Title Norbert Lange created an issue Jenkins / JENKINS-34658 Whitelist more Functions for trivial operations on builtin types Issue Type: Improvement Assignee: Jesse Glick Components: script-security-plugin Created: 2016/May/06 11:08 PM Priority: Minor Reporter: Norbert Lange I have problems writing pipeline Scripts without having to approve several functions that are rather trivial operations of the most basic types. List of approvals follows, and some short fragments showing some code fragments using them. method java.lang.Object clone method java.util.Map putAll java.util.Map new java.util.AbstractMap$SimpleImmutableEntry java.lang.Object java.lang.Object new java.util.AbstractMap$SimpleEntry java.lang.Object java.lang.Object staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods minus java.lang.String java.lang.Object staticMethod org.codehaus.groovy.runtime.DefaultGroovyMethods plus java.util.Map java.util.Map // String minus operator def file = "foo.exe" def base = file - ".exe" Cloning a Map, so you can have a template and change fields without modifying the original.
