[JIRA] (JENKINS-62171) Can't handle class jenkins.security.plugins.ldap.FromGroupSearchLDAPGroupMembershipStrategy#authoritiesPopulator
Title: Message Title
Anders Hammar created an issue
Jenkins / JENKINS-62171
Can't handle class jenkins.security.plugins.ldap.FromGroupSearchLDAPGroupMembershipStrategy#authoritiesPopulator
Issue Type:
Bug
Assignee:
Unassigned
Components:
ldap-plugin
Created:
2020-05-06 06:08
Environment:
Jenkins 2.222.3 on RHEL7 and openJdk 1.8 LDAP plugin v1.24 JCasc plugin v1.39
Labels:
jcasc-compatibility
Priority:
Minor
Reporter:
Anders Hammar
During startup when JCasC loads configuration (se below) the following is logged:
May 05, 2020 3:17:51 PM WARNING io.jenkins.plugins.casc.BaseConfigurator createAttribute Can't handle class jenkins.security.plugins.ldap.FromGroupSearchLDAPGroupMembershipStrategy#authoritiesPopulator: type is abstract but not Describable.
Here's the JCasC yaml (sensitive data replaced with dummy):
jenkins:
securityRealm:
ldap:
configurations:
- server: "ldap.acme.org"
rootDN: "dc=utv,dc=acme,dc=org"
userSearchBase: "ou=people"
userSearch: "uid={0}"
groupSearchBase: "ou=group"
groupSearchFilter: "(& (cn={0}) (objectclass=posixGroup))"
groupMembershipStrategy:
fromGroupSearch:
filter: ""
[JIRA] (JENKINS-61882) JCasC GitOps support
Title: Message Title Anders Hammar updated an issue Jenkins / JENKINS-61882 JCasC GitOps support Change By: Anders Hammar Use case:We would like to handle our Jenkins' configuration through GitOps. The idea is that the config file(s) are stored in a git repo and JCasC reloads these when updated , without downtime . This could be handled by polling the repo or possible via webhook.It would be great if this would be supported by the plugin. 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.205752.1586791192000.9742.1586791440224%40Atlassian.JIRA.
[JIRA] (JENKINS-61882) JCasC GitOps support
Title: Message Title Anders Hammar created an issue Jenkins / JENKINS-61882 JCasC GitOps support Issue Type: New Feature Assignee: Ewelina Wilkosz Components: configuration-as-code-plugin Created: 2020-04-13 15:19 Environment: n/a Priority: Minor Reporter: Anders Hammar Use case: We would like to handle our Jenkins' configuration through GitOps. The idea is that the config file(s) are stored in a git repo and JCasC reloads these when updated. This could be handled by polling the repo or possible via webhook. It would be great if this would be supported by the plugin. Add Comment
[JIRA] (JENKINS-61468) Configuration option for shared pipeline libs
Title: Message Title Anders Hammar created an issue Jenkins / JENKINS-61468 Configuration option for shared pipeline libs Issue Type: Improvement Assignee: Unassigned Components: workflow-cps-global-lib-plugin Created: 2020-03-13 12:40 Environment: n/a Priority: Minor Reporter: Anders Hammar Scenario: A shared groovy lib which needs to be configured per Jenkins environment (like the URL to some server), but not per build project. Currently a solution is to define an environment variabel for this. The drawback is that the env variabel is then available to everything in Jenkins. A much cleaner solution would be if it was possible to specify configuration just for this shared groovy lib. For example a key/value pair (configured for the library) which is then available as a variable in the groovy script. Add Comment
[JIRA] (JENKINS-60712) Copied managed config file should be removed when block ends
Title: Message Title Anders Hammar updated an issue Jenkins / JENKINS-60712 Copied managed config file should be removed when block ends Change By: Anders Hammar Environment: nodejs-plugin Jenkins 2.190.3 (on RHEL7 with openJDK 1.8.0)Token Macro Plugin v2.10Config FIle Provider Plugin v3.6.2NodeJS Plugin v1.3.4 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.203960.157858259.6323.1578655860225%40Atlassian.JIRA.
[JIRA] (JENKINS-60720) Possibility to specify if env variables should be filtered or not in npm config file
Title: Message Title Anders Hammar updated an issue Jenkins / JENKINS-60720 Possibility to specify if env variables should be filtered or not in npm config file Change By: Anders Hammar Environment: Jenkins 2.190.3 (on RHEL7 with openJDK 1.8.0)Token Macro Plugin v2.10Config FIle Provider Plugin v3.6.2NodeJS Plugin 1.3.4 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.203969.157864169.6321.1578655800059%40Atlassian.JIRA.
[JIRA] (JENKINS-60720) Possibility to specify if env variables should be filtered or not in npm config file
Title: Message Title
Anders Hammar edited a comment on JENKINS-60720
Re: Possibility to specify if env variables should be filtered or not in npm config file
This is handled by the Token Macro plugin and after some investigation there is an (undocumented) way to do this by specifying three four ( 3 4 ) '$' chars. So my example would then be:{code}registry=http://nexus.acme.org/repository/npm-group///nexus.acme.org/repository/npm-releases/:_authToken=$$$ $ {NPM_TOKEN}{code} Checking the token macro code it looks like it should be enough with two '$' chars but I can't get that to work with token-macro-plugin v2.10.
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.203969.157864169.6115.1578646620057%40Atlassian.JIRA.
[JIRA] (JENKINS-60720) Possibility to specify if env variables should be filtered or not in npm config file
Title: Message Title Anders Hammar closed an issue as Not A Defect Solution exists in Token Macro plugin, se above. Closing. Jenkins / JENKINS-60720 Possibility to specify if env variables should be filtered or not in npm config file Change By: Anders Hammar Status: Open Closed Assignee: Nikolas Falco Resolution: Not A Defect Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-60720) Possibility to specify if env variables should be filtered or not in npm config file
Title: Message Title
Anders Hammar commented on JENKINS-60720
Re: Possibility to specify if env variables should be filtered or not in npm config file
This is handled by the Token Macro plugin and after some investigation there is an (undocumented) way to do this by specifying three (3) '$' chars. So my example would then be:
registry=http://nexus.acme.org/repository/npm-group/
//nexus.acme.org/repository/npm-releases/:_authToken=$$${NPM_TOKEN}
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.203969.157864169.6085.1578645300178%40Atlassian.JIRA.
[JIRA] (JENKINS-60720) Possibility to specify if env variables should be filtered or not in npm config file
Title: Message Title
Anders Hammar updated an issue
Jenkins / JENKINS-60720
Possibility to specify if env variables should be filtered or not in npm config file
Change By:
Anders Hammar
In a npm configuration file any environment variable (specified by $VARIABLE_NAME or ${VARIABLE_NAME}) is being filtered/replaced by the env varibale value. If the filtering process can't find the env varibale an error message is logged in the build console.However, in some cases it would be desirable to keep the "${VARIABLE_NAME}" string in the used npm config file so that npm itself replaces this. One scenario is for authentication, like this:{code}registry=http://nexus.acme.org/repository/npm-group///nexus.acme.org/repository/npm-releases/:_authToken= \ ${NPM_TOKEN}{code}In this case, for security reasons, you don't want the env variable to be expanded/filtered during the copying of the config file but rather have npm fetching the env variable value during the "npm publish" execution.
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-60720) Possibility to specify if env variables should be filtered or not in npm config file
Title: Message Title Anders Hammar commented on JENKINS-60720 Re: Possibility to specify if env variables should be filtered or not in npm config file Seems as this is controlled by the used functionality in config-file-provider-plugin, which always expands (not way to turn off). 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.203969.157864169.6073.1578643500119%40Atlassian.JIRA.
[JIRA] (JENKINS-60720) Possibility to specify if env variables should be filtered or not in npm config file
Title: Message Title
Anders Hammar created an issue
Jenkins / JENKINS-60720
Possibility to specify if env variables should be filtered or not in npm config file
Issue Type:
Improvement
Assignee:
Nikolas Falco
Components:
nodejs-plugin
Created:
2020-01-10 07:34
Priority:
Major
Reporter:
Anders Hammar
In a npm configuration file any environment variable (specified by $VARIABLE_NAME or ${VARIABLE_NAME}) is being filtered/replaced by the env varibale value. If the filtering process can't find the env varibale an error message is logged in the build console. However, in some cases it would be desirable to keep the "${VARIABLE_NAME}" string in the used npm config file so that npm itself replaces this. One scenario is for authentication, like this:
registry=http://nexus.acme.org/repository/npm-group/
//nexus.acme.org/repository/npm-releases/:_authToken=\${NPM_TOKEN}
In this case, for security reasons, you don't want the env variable to be expanded/filtered during the copying of the config file but rather have npm fetching the env variable value during the "npm publish" execution.
[JIRA] (JENKINS-60712) Copied managed config file should be removed when block ends
Title: Message Title Anders Hammar created an issue Jenkins / JENKINS-60712 Copied managed config file should be removed when block ends Issue Type: Improvement Assignee: Nikolas Falco Components: nodejs-plugin Created: 2020-01-09 15:09 Environment: nodejs-plugin v1.3.4 Priority: Major Reporter: Anders Hammar When specifying a config file for the nodejs step (in a pipeline), the copied config file should be removed when the step finishes. In v1.3.4 it is not. As a reference, the configFileProvider step (of the Config File Provider Plugin) does remove any copied config file then the step finishes. Add Comment
[JIRA] (JENKINS-60709) base64 encoding support when binding usernameColonPassword
Title: Message Title Anders Hammar created an issue Jenkins / JENKINS-60709 base64 encoding support when binding usernameColonPassword Issue Type: Improvement Assignee: Unassigned Components: credentials-binding-plugin Created: 2020-01-09 14:15 Environment: n/a Priority: Minor Reporter: Anders Hammar Would it make sense to have support for optionally have the value bound by usernameColonPassword base64 encoded? The scenario is that I'd like to have ONE Username and password credential defined in my Jenkins instance, representing the (user) account in Nexus. I'd like to be able to use that for all access with NExus, e.g. Maven repos and npm registries. When publishing to a npm registry in Nexus it is possible to use basic auth and hence this username/password credential, but it needs to be base64 encoded. Info here: https://help.sonatype.com/repomanager3/formats/npm-registry#NpmRegistry-AuthenticationUsingBasicAuth My idea is to add an additional optional param for usernameColonPassword to be able to specify that the value should be base64 encoded before bound. Possibly it could generalized to support different encodings, should it make sense.
[JIRA] (JENKINS-59731) Moving pipeline job to folder causes loss of "Recent changes"
Title: Message Title Anders Hammar updated an issue Jenkins / JENKINS-59731 Moving pipeline job to folder causes loss of "Recent changes" Change By: Anders Hammar Issue:A pipeline build job which has been built and has changes listed for builds (seen by accessing ./changes on the job URL) as well as the number of commits for each build shown in the Stage View UI.When that pipeline job then is moved to a folder, all recent changes are lost. Also, it now says "No changes" in the Staeg View for all builds.If then a change is committed to the git repo a new build is triggered, that change is listed in "Recent changes" and it says "1 commit" for that build in the Stage view. All older builds says "No Changes".No stack trace or problem indication in the log.If I move the build back to where it was from the beginning, the changes are back again! (But then any changes recorden recorded when the job was in the folder is lost instead.)I have tested the same procedure with a Maven project build job and then recent changes are still there after moving to a folder. Add Comment This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-59731) Moving pipeline job to folder causes loss of "Recent changes"
Title: Message Title Anders Hammar created an issue Jenkins / JENKINS-59731 Moving pipeline job to folder causes loss of "Recent changes" Issue Type: Bug Assignee: Unassigned Attachments: packager-config.yml Components: pipeline Created: 2019-10-10 13:33 Environment: Jenkins 2.176.2 on RHEL7 with OpenJDK 1.8. All used plugins can be seen in attached yaml file. Git 2.9 OS client Priority: Minor Reporter: Anders Hammar Issue: A pipeline build job which has been built and has changes listed for builds (seen by accessing ./changes on the job URL) as well as the number of commits for each build shown in the Stage View UI. When that pipeline job then is moved to a folder, all recent changes are lost. Also, it now says "No changes" in the Staeg View for all builds. If then a change is committed to the git repo a new build is triggered, that change is listed in "Recent changes" and it says "1 commit" for that build in the Stage view. All older builds says "No Changes". No stack trace or problem indication in the log. If I move the build back to where it was from the beginning, the changes are back again! (But then any changes recorden when the job was in the folder is lost instead.) I have tested the same procedure with a Maven project build job and then recent changes are still there after moving to a folder.
[JIRA] (JENKINS-58659) ZipExtractionInstaller should ignore timestamp if URL changes
Title: Message Title Anders Hammar updated an issue Jenkins / JENKINS-58659 ZipExtractionInstaller should ignore timestamp if URL changes Change By: Anders Hammar Component/s: core Component/s: customtools-plugin 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.200940.1564060967000.255.1565418840131%40Atlassian.JIRA.
[JIRA] (JENKINS-58659) ZipExtractionInstaller should ignore timestamp if URL changes
Title: Message Title Anders Hammar updated an issue Jenkins / JENKINS-58659 ZipExtractionInstaller should ignore timestamp if URL changes Change By: Anders Hammar Background:We're using the Custom Tools Plugin to define misc custom tools in our Jenkins environment. Typically we use "Install automatically" and use the "Extract *.zip/*.tar.gz" installer to download the tool archive. The archive is typically hosted in our Nexus instance and we specify the exact version, like this:http://nexus.acme.org/content/repositories/releases/org/acme/jenkins/nifty-tool/1.0.0/nifty-tool-1.0.0.tar.gz(In this example we're pointing at a Maven artifact, but it could be any URL.)When there is a new version of the tool we just update the ULR and Jenkins will update automatically.Problem:The problem is when we want to downgrade to an earlier version. For example, we havehttp://nexus.acme.org/content/repositories/releases/org/acme/jenkins/nifty-tool/1.0.1/nifty-tool-1.0.1.tar.gzbut want to change back to the oldhttp://nexus.acme.org/content/repositories/releases/org/acme/jenkins/nifty-tool/1.0.0/nifty-tool-1.0.0.tar.gzIn this case the older version is not automatically installed, but we need to manually go in on every slave and remove the .timestamp file to force a downgrade.Suggested Improvement:The current behavior where only a newer archive is downloaded and installed is suitable when the URL doesn't change but one just updates the archive (overwriting the old file). But if the URL changes, the archive should be installed regardless of the timestamp. A different URL should always indicate a different archive.The change should be done in hudson. tool. FilePath.installIfNecessaryFrom(). The current javadoc says that if the timestamp of the archive doesn't match the local timestamp it is re-extracted, which is not fully correct. JENKINS-16215 changed this behavior so that the local timestamp value is use as if-modified-since header on the UrlConnection. So a downgrade to an earlier/older archive from an Http URL will never happen.A possible impl solution is to store the URL in the timestamp file and use that to check if the URL has changed. If it has, always re-extract regardless of the local timestamp. Add Comment
[JIRA] (JENKINS-58659) ZipExtractionInstaller should ignore timestamp if URL changes
Title: Message Title Anders Hammar updated an issue Jenkins / JENKINS-58659 ZipExtractionInstaller should ignore timestamp if URL changes Change By: Anders Hammar Background:We're using the Custom Tools Plugin to define misc custom tools in our Jenkins environment. Typically we use "Install automatically" and use the "Extract *.zip/*.tar.gz" installer to download the tool archive. The archive is typically hosted in our Nexus instance and we specify the exact version, like this:http://nexus.acme.org/content/repositories/releases/org/acme/jenkins/nifty-tool/1.0.0/nifty-tool-1.0.0.tar.gz(In this example we're pointing at a Maven artifact, but it could be any URL.)When there is a new version of the tool we just update the ULR and Jenkins will update automatically.Problem:The problem is when we want to downgrade to an earlier version. For example, we havehttp://nexus.acme.org/content/repositories/releases/org/acme/jenkins/nifty-tool/1.0.1/nifty-tool-1.0.1.tar.gzbut want to change back to the oldhttp://nexus.acme.org/content/repositories/releases/org/acme/jenkins/nifty-tool/1.0.0/nifty-tool-1.0.0.tar.gzIn this case the older version is not automatically installed, but we need to manually go in on every slave and remove the .timestamp file to force a downgrade.Suggested Improvement:The current behavior where only a newer archive is doenloaded downloaded and installed is suitable when the URL doesn't change but one just updates the archive (overwriting the old file). But if the URL changes, the archive should be installed regardless of the timestamp. A different URL should always indicate a different archive.The change should be done in hudson.tool.FilePath.installIfNecessaryFrom(). The current javadoc says that if the timestamp of the archive doesn't match the local timestamp it is re-extracted, which is not fully correct. JENKINS-16215 changed this behavior so that the local timestamp value is use as if-modified-since header on the UrlConnection. So a downgrade to an earlier/older archive from an Http URL will never happen.A possible impl solution is to store the URL in the timestamp file and use that to check if the URL has changed. If it has, always re-extract regardless of the local timestamp. Add Comment
[JIRA] (JENKINS-58659) ZipExtractionInstaller should ignore timestamp if URL changes
Title: Message Title Anders Hammar commented on JENKINS-58659 Re: ZipExtractionInstaller should ignore timestamp if URL changes The functionality is in core, could someone please change back the specified component? (Custom tools plugin, and other plugins, uses this core func.) 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.200940.1564060967000.1532.1564126680199%40Atlassian.JIRA.
[JIRA] (JENKINS-58659) ZipExtractionInstaller should ignore timestamp if URL changes
Title: Message Title Anders Hammar created an issue Jenkins / JENKINS-58659 ZipExtractionInstaller should ignore timestamp if URL changes Issue Type: Improvement Assignee: Unassigned Components: core Created: 2019-07-25 13:22 Environment: Jenkins LTS 2.176.2 RedHat OpenJDK 1.8.0 RHEL 7 Priority: Minor Reporter: Anders Hammar Background: We're using the Custom Tools Plugin to define misc custom tools in our Jenkins environment. Typically we use "Install automatically" and use the "Extract .zip/.tar.gz" installer to download the tool archive. The archive is typically hosted in our Nexus instance and we specify the exact version, like this: http://nexus.acme.org/content/repositories/releases/org/acme/jenkins/nifty-tool/1.0.0/nifty-tool-1.0.0.tar.gz (In this example we're pointing at a Maven artifact, but it could be any URL.) When there is a new version of the tool we just update the ULR and Jenkins will update automatically. Problem: The problem is when we want to downgrade to an earlier version. For example, we have http://nexus.acme.org/content/repositories/releases/org/acme/jenkins/nifty-tool/1.0.1/nifty-tool-1.0.1.tar.gz but want to change back to the old http://nexus.acme.org/content/repositories/releases/org/acme/jenkins/nifty-tool/1.0.0/nifty-tool-1.0.0.tar.gz In this case the older version is not automatically installed, but we need to manually go in on every slave and remove the .timestamp file to force a downgrade. Suggested Improvement: The current behavior where only a newer archive is doenloaded and installed is suitable when the URL doesn't change but one just updates the archive (overwriting the old file). But if the URL changes, the archive should be installed regardless of the timestamp. A different URL should always indicate a different archive.
[JIRA] (JENKINS-56592) Mixed checkout info in console output when two git statements in pipeline
Title: Message Title
Anders Hammar updated an issue
Jenkins / JENKINS-56592
Mixed checkout info in console output when two git statements in pipeline
Change By:
Anders Hammar
When I have two git repos checkout in a pipeline, the console output is inconsistent and the info is mixed up. All the repo info i s specified in the Jenkinsfile.{code:groovy}def REPO1_URL = 'ssh://g...@bitbucket.acme.org:7999/~X/repo1.git'def REPO1_BRANCH = 'master'def REPO2_URL = 'ssh://g...@bitbucket.acme.org:7999/~X/repo2.git'def REPO2_BRANCH = 'branch'node('git && linux') {dir('git-repo1') {deleteDir()git(url: "${REPO1_URL}", branch: "${REPO1_BRANCH}", credentialsId: 'bitbucket-creds')} dir('git-repo2') {deleteDir()git(url: "${REPO2_URL}", branch: "${REPO2_BRANCH}", credentialsId: 'bitbucket-creds')}}{code}Console output:{quote}Started by user XXXRunning in Durability level: MAX_SURVIVABILITY[Pipeline] Start of Pipeline[Pipeline] nodeRunning on XXX in /var/lib/jenkins/workspace/X/X-two-git-stmt-bug[Pipeline] {[Pipeline] dirRunning in /var/lib/jenkins/workspace/X/X-two-git-stmt-bug/git-repo1[Pipeline] {[Pipeline] deleteDir[Pipeline] gitusing credential bitbucket-credsCloning the remote Git repositoryChecking out Revision 46ad07ce6d689dda4f59e1aff54fc45b8dc1786a (refs/remotes/origin/master)Commit message: "xxx"[Pipeline] }[Pipeline] // dir[Pipeline] dirRunning in /var/lib/jenkins/workspace/X/X-two-git-stmt-bug/git-repo2[Pipeline] {[Pipeline] deleteDir[Pipeline] gitusing credential bitbucket-credsCloning the remote Git repositoryCloning repository ssh://g...@bitbucket.acme.org:7999/~X/repo1.git > git init /var/lib/jenkins/workspace/X/X-two-git-stmt-bug/git-repo1 # timeout=10Fetching upstream changes from ssh://g...@bitbucket.acme.org:7999/~X/repo1.git > git --version # timeout=10using GIT_SSH to set credentials SSH key credentials for Jenkins to access Bitbucket > git fetch --tags --progress ssh://g...@bitbucket.acme.org:7999/~X/repo1.git +refs/heads/*:refs/remotes/origin/* > git config remote.origin.url ssh://g...@bitbucket.acme.org:7999/~X/repo1.git # timeout=10 > git config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10 > git config remote.origin.url ssh://g...@bitbucket.acme.org:7999/~X/repo1.git # timeout=10Fetching upstream changes from ssh://g...@bitbucket.acme.org:7999/~X/repo1.gitusing GIT_SSH to set credentials SSH key credentials for Jenkins to access Bitbucket > git fetch --tags --progress ssh://g...@bitbucket.acme.org:7999/~X/repo1.git +refs/heads/*:refs/remotes/origin/* > git rev-parse refs/remotes/origin/master^{commit} # timeout=10 > git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10 > git config core.sparsecheckout # timeout=10 > git checkout -f 46ad07ce6d689dda4f59e1aff54fc45b8dc1786a > git branch -a -v --no-abbrev # timeout=10 > git checkout -b master 46ad07ce6d689dda4f59e1aff54fc45b8dc1786a > git rev-list --no-walk
[JIRA] (JENKINS-56592) Mixed checkout info in console output when two git statements in pipeline
Title: Message Title Anders Hammar updated an issue Jenkins / JENKINS-56592 Mixed checkout info in console output when two git statements in pipeline Change By: Anders Hammar Environment: RHEL 7, OpenJDK 1.8.0_191, Jenkins LTS 2.150.3Git plugin 3.9.3, Git client plugin 2.7.6, SCM API plugin 2.3.0 , Pipeline: SCM Step 2.7 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-56592) Mixed checkout info in console output when two git statements in pipeline
Title: Message Title
Anders Hammar created an issue
Jenkins / JENKINS-56592
Mixed checkout info in console output when two git statements in pipeline
Issue Type:
Bug
Assignee:
Mark Waite
Components:
git-plugin
Created:
2019-03-18 08:11
Environment:
RHEL 7, OpenJDK 1.8.0_191, Jenkins LTS 2.150.3 Git plugin 3.9.3, Git client plugin 2.7.6, SCM API plugin 2.3.0
Priority:
Minor
Reporter:
Anders Hammar
When I have two git repos checkout in a pipeline, the console output is inconsistent and the info is mixed up. All the repo info i s specified in the Jenkinsfile.
def REPO1_URL = 'ssh://g...@bitbucket.acme.org:7999/~X/repo1.git'
def REPO1_BRANCH = 'master'
def REPO2_URL = 'ssh://g...@bitbucket.acme.org:7999/~X/repo2.git'
def REPO2_BRANCH = 'branch'
node('git && linux') {
dir('git-repo1') {
deleteDir()
git(url: "${REPO1_URL}", branch: "${REPO1_BRANCH}", credentialsId: 'bitbucket-creds')
}dir('git-repo2') {
deleteDir()
git(url: "${REPO2_URL}", branch: "${REPO2_BRANCH}", credentialsId: 'bitbucket-creds')
}
}
Console output:
Started by user XXX Running in Durability level: MAX_SURVIVABILITY [Pipeline] Start of Pipeline
[Pipeline] node
Running on XXX in
[JIRA] [m2release-plugin] (JENKINS-35261) SCM username/password env variables don't work with SECURITY-170
Title: Message Title Anders Hammar updated an issue Jenkins / JENKINS-35261 SCM username/password env variables don't work with SECURITY-170 More info here: https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2016-05-11 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] [m2release-plugin] (JENKINS-35261) SCM username/password env variables don't work with SECURITY-170
Title: Message Title Anders Hammar created an issue Jenkins / JENKINS-35261 SCM username/password env variables don't work with SECURITY-170 Issue Type: Bug Assignee: James Nord Components: m2release-plugin Created: 2016/Jun/01 11:08 AM Environment: Jenkins LTS 1.651.2, Oracle JDK 8u92, Windows Server 2008R2 Priority: Major Reporter: Anders Hammar For a Maven job a have SCM username and password environment variables configured. This work with Jenkins LTS v1.651.1 but with v1.651.2 it doesn't. The environment variables don't seem to be set. I suspect that SECURITY-170 fix is the reason for this behavior. The plugin needs to be updated to work with this change. Add Comment
[JIRA] [maven-plugin] (JENKINS-4428) MavenProbeAction exposes password parameters
Title: Message Title Anders Hammar commented on JENKINS-4428 Re: MavenProbeAction exposes password parameters Ping. Could someone review and merge please? 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] [parameterized-remote-trigger-plugin] (JENKINS-31170) Credentials aren't filtered based on entered remote server address (and port)
Title: Message Title Anders Hammar updated an issue Jenkins / JENKINS-31170 Credentials aren't filtered based on entered remote server address (and port) Change By: Anders Hammar Both in the server's config and the job's config, all credentials configured in the server show up in the drop-down list regardless of the credentials' configured domain. Using domains for the credentials they are supposed to be filtered which doesn't seem to work.What I have:* A credential domain for the hostname "remotejenkins.acme.org"* In the server's config I've configured the "Remote address and port" in "Parameterized Remote Trigger Configuration" as "http://remotejenkins.acme.org"What I then see:* In the credentials drop-down list (both in server's config and job's config) lists all credentails configured are listed regardless of credentail credential domain. Even credential credentials configured for hostname such as "svn.acme.org". 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] [parameterized-remote-trigger-plugin] (JENKINS-31170) Credentials aren't filtered based on entered remote server address (and port)
Title: Message Title Anders Hammar created an issue Jenkins / JENKINS-31170 Credentials aren't filtered based on entered remote server address (and port) Issue Type: Bug Assignee: Maurice W. Components: parameterized-remote-trigger-plugin Created: 26/Oct/15 12:51 PM Environment: Jenkins LTS v1.609.3 parameterized-remote-trigger-plugin v2.2.2 credentials plugin v1.24 Oracle JDK 1.7.0_75 Priority: Minor Reporter: Anders Hammar Both in the server's config and the job's config, all credentials configured in the server show up in the drop-down list regardless of the credentials' configured domain. Using domains for the credentials they are supposed to be filtered which doesn't seem to work. What I have: A credential domain for the hostname "remotejenkins.acme.org" In the server's config I've configured the "Remote address and port" in "Parameterized Remote Trigger Configuration" as "http://remotejenkins.acme.org"
[JIRA] [parameterized-remote-trigger-plugin] (JENKINS-31170) Credentials aren't filtered based on entered remote server address (and port)
Title: Message Title Anders Hammar commented on JENKINS-31170 Re: Credentials aren't filtered based on entered remote server address (and port) Possibly this could be due to something in the credentials plugin. I see a similar behavior for a different plugin using credentials. 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] [m2release-plugin] (JENKINS-29995) Fails with m-release-p v2.5.2
Title: Message Title Anders Hammar resolved as Not A Defect It seems as this was something bad in the plugin. It works with the newly released v2.5.3. (There was a lengthy mail thread about one of the plugin's deps on the Maven dev list, which might be the cause for this issue.) Jenkins / JENKINS-29995 Fails with m-release-p v2.5.2 Change By: Anders Hammar Status: Open Resolved Assignee: James Nord Resolution: Not A Defect 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
[JIRA] [negotiate-sso-plugin] (JENKINS-30990) Fix links on wiki page
Title: Message Title Anders Hammar created an issue Jenkins / JENKINS-30990 Fix links on wiki page Issue Type: Task Assignee: Bryson Gibbons Components: negotiate-sso-plugin Created: 16/Oct/15 10:54 AM Environment: n/a Priority: Minor Reporter: Anders Hammar On the wiki page https://wiki.jenkins-ci.org/display/JENKINS/Negotiate+SSO+for+Windows the links to Github and Jira issues isn't correct and should be fixed. The info seems to be fetch from somewhere so I don't know how to fix it. It's the plugin name that should be 'Negotiate-SSO-plugin' not 'NegotiateSSO-plugin'. Add Comment
[JIRA] [m2release-plugin] (JENKINS-30794) Support for nexus-staging-maven-plugin
Title: Message Title Anders Hammar commented on JENKINS-30794 Re: Support for nexus-staging-maven-plugin One basic reason for using nexus-staging-m-p and not just m-deploy-p is if you want to explicitly specify the stagingProfileId (and not have Nexus handle that implicitly). To my knowledge, that is not possible with the m-deploy-p way. The are other benefits as well, for example you don't have to configure use agent for different Jenkins nodes so that deployment is separated correctly. In any case, I'm not saying that we should use Maven for everything with staging i Nexus (although Sonatype support says it's the prefered way). Basically, what I'd like is the nexus-staging-m-p to be supported as well. To be able to do anything later on with the staged repo, you need the ID. In the nexus-staging-m-p case I think it's done easiest by parsing a properties file (which the plugin does as well). Not perfect, but I wouldn't mind talking to Sonatype to have this logic hidden in a library they provide (which then the plugin would use as well). Then additional functionality could be added to the jenkins plugin to promote/release or drop the repo. And this should work regardless of if the staging was done the m-deploy-p or the nexus-staging-m-p way. WDYT? 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] [m2release-plugin] (JENKINS-30794) Support for nexus-staging-maven-plugin
Title: Message Title Anders Hammar created an issue Jenkins / JENKINS-30794 Support for nexus-staging-maven-plugin Issue Type: Improvement Assignee: James Nord Components: m2release-plugin Created: 05/Oct/15 12:19 PM Environment: n/a Priority: Major Reporter: Anders Hammar Staging support in Sonatype Nexus today is preferably handled via the nexus-staging-maven-plugin, which replace the default maven-deploy-plugin. It would be good with some support in m2release plugin for this by, for example, storing info on the created staging repo id. The nexus-staging-maven-plugin creates a properties file during execution (in the workspace) where this info is recorded: #Generated by org.sonatype.plugins:nexus-staging-maven-plugin:1.6.6 #Mon Oct 05 13:35:43 CEST 2015 stagingRepository.managed=true stagingRepository.profileId=ab12345cd67ef stagingRepository.id=test_staging-1001 stagingRepository.url=""> What I'm thinking is that this info could then later on be used to promote/release or drop the staging repo programatically. The properties file is typically removed during the next Maven build (mvn clean install). We could
[JIRA] [m2release-plugin] (JENKINS-29995) Fails with m-release-p v2.5.2
Title: Message Title Anders Hammar created an issue Jenkins / JENKINS-29995 Fails with m-release-p v2.5.2 Issue Type: Bug Assignee: James Nord Components: m2release-plugin Created: 18/Aug/15 6:11 AM Environment: Jenkins LTS 1.609.2, m2release-plugin v0.14.0, Maven 3.0.4, IBM JDK 1.6 Priority: Major Reporter: Anders Hammar Triggering a release build with maven-release-plugin v2.5.2 fails: [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.5.2:prepare (default-cli) on project ah-test: Execution default-cli of goal org.apache.maven.plugins:maven-release-plugin:2.5.2:prepare failed: A required class was missing while executing org.apache.maven.plugins:maven-release-plugin:2.5.2:prepare: org.codehaus.plexus.util.xml.pull.EntityReplacementMap
[JIRA] [maven-plugin] (JENKINS-29955) Can't build source on Windows
Title: Message Title
Anders Hammar commented on JENKINS-29955
Re: Can't build source on Windows
What's the preferable way to solve this; change the troublesome unicode character or upgrade the plugin? The troublesome character:
Messages.properties
MavenVersionCallable.MavenHomeDoesntExist=Maven Home {0} doesn\u2019t exist
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] [maven-plugin] (JENKINS-4428) MavenProbeAction exposes password parameters
Title: Message Title Anders Hammar commented on JENKINS-4428 Re: MavenProbeAction exposes password parameters https://github.com/jenkinsci/maven-plugin/pull/50 I don't know how to create an IT for this though. Somehow I need to trigger an action during the Maven build and not verify the outcome of a build. 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] [maven-plugin] (JENKINS-29955) Can't build source on Windows
Title: Message Title Anders Hammar created an issue Jenkins / JENKINS-29955 Can't build source on Windows Issue Type: Bug Assignee: Unassigned Components: maven-plugin Created: 14/Aug/15 12:16 PM Environment: Windows 7, Oracle JDK 1.7.0_79, Maven 3.2.5 Priority: Major Reporter: Anders Hammar Building master branch (2.12-SNAPSHOT, a598af0) fails on Windows: [INFO] — maven-compiler-plugin:2.5:compile (default-compile) @ maven-plugin — [INFO] Compiling 77 source files to C:\Users\KAHA14\git\maven-plugin\target\classes [INFO] - [ERROR] COMPILATION ERROR : [INFO] - [ERROR] C:\Users\KAHA14\git\maven-plugin\target\generated-sources\localizer\hudson\maven\Messages.java:[17,27] error: unmappable character for encoding UTF-8 [ERROR] C:\Users\KAHA14\git\maven-plugin\target\generated-sources\localizer\hudson\maven\Messages.java:[25,27] error: unmappable character for encoding UTF-8 [INFO] 2 errors On Mac OS (same JDK and Maven level) it works just fine. Building v2.10 of the plugin works. I've narrowed it down to the parent upgrade from 1.554.3 to 1.580.1 triggers this failure.
[JIRA] [maven-plugin] (JENKINS-29955) Can't build source on Windows
Title: Message Title Anders Hammar commented on JENKINS-29955 Re: Can't build source on Windows Here's a mail thread around this issue hitting other people: https://groups.google.com/forum/#!topic/jenkinsci-dev/mLrAoiYH6bk 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] [maven-plugin] (JENKINS-29955) Can't build source on Windows
Title: Message Title
Anders Hammar updated an issue
Jenkins / JENKINS-29955
Can't build source on Windows
Change By:
Anders Hammar
Buildingmasterbranch(2.12-SNAPSHOT,a598af0)failsonWindows: {quote} [INFO]---maven-compiler-plugin:2.5:compile(default-compile)@maven-plugin---[INFO]Compiling77sourcefilestoC:\Users\KAHA14\git\maven-plugin\target\classes[INFO]-[ERROR]COMPILATIONERROR:[INFO]-[ERROR]C:\Users\KAHA14\git\maven-plugin\target\generated-sources\localizer\hudson\maven\Messages.java:[17,27]error:unmappablecharacterforencodingUTF-8[ERROR]C:\Users\KAHA14\git\maven-plugin\target\generated-sources\localizer\hudson\maven\Messages.java:[25,27]error:unmappablecharacterforencodingUTF-8[INFO]2errors {quote} OnMacOS(sameJDKandMavenlevel)itworksjustfine.Buildingv2.10ofthepluginworks.I'venarroweditdowntotheparentupgradefrom1.554.3to1.580.1triggersthisfailure.
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] [maven-plugin] (JENKINS-29955) Can't build source on Windows
Title: Message Title Anders Hammar commented on JENKINS-29955 Re: Can't build source on Windows Upgrading maven-localizer-plugin to v1.23 solves this. It doesn't explain the root cause though. 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] [maven-plugin] (JENKINS-4428) MavenProbeAction exposes password parameters
Title: Message Title Anders Hammar started work on JENKINS-4428 Change By: Anders Hammar Status: Open InProgress 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] [maven-plugin] (JENKINS-4428) MavenProbeAction exposes password parameters
Title: Message Title Anders Hammar assigned an issue to Anders Hammar Jenkins / JENKINS-4428 MavenProbeAction exposes password parameters Change By: Anders Hammar Assignee: AndersHammar 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] [config-file-provider-plugin] (JENKINS-29710) Hostname credentials show up in the Edit settings.xml page
Title: Message Title Anders Hammar updated an issue Jenkins / JENKINS-29710 Hostname credentials show up in the Edit settings.xml page I'm attaching a sample credentials.xml file. Please note that the passwords have been masked, not sure how that affects Jenkins. Change By: Anders Hammar Attachment: credentials.xml 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] [maven-plugin] (JENKINS-4428) MavenProbeAction exposes password parameters
Title: Message Title Anders Hammar commented on JENKINS-4428 Re: MavenProbeAction exposes password parameters I've looked into this and have a PoC fix for masking sensitive env vars: https://github.com/andham/maven-plugin/tree/poc-JENKINS-4428 I'd appreciate a second set of eyes on this and some input before starting a PR. I'm having issues executing the project's tests, so haven't looked into that just yet. Please note that this only masked the env vars, not anything in the system properties page. Maybe the same masking should be applied there? 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] [config-file-provider-plugin] (JENKINS-29805) Credentials don't show up in maven settings.xml (regression)
Title: Message Title Anders Hammar created an issue Jenkins / JENKINS-29805 Credentials don't show up in maven settings.xml (regression) Issue Type: Bug Assignee: Dominik Bartholdi Attachments: plugin-2_8_1.png, plugin-2_9_2.png Components: config-file-provider-plugin Created: 05/Aug/15 1:09 PM Environment: Jenkins LTS v1.609.2, config-file-provider-plugin v2.9.2, credentials-plugin v1.22 Priority: Blocker Reporter: Anders Hammar After upgrading from v2.8.1 to v.2.9.2, Maven serverId credentials don't show up in the edit Maven settings.xml page. See attachment! I've also tried creating a new settings.xml. Same behavior.
[JIRA] [config-file-provider-plugin] (JENKINS-26171) Add credentials labels to plugin wiki page
Title: Message Title Anders Hammar resolved as Fixed Closing as fixed after verifying that the wiki page is updated. Jenkins / JENKINS-26171 Add credentials labels to plugin wiki page Change By: Anders Hammar Status: Open Resolved Assignee: DominikBartholdi AndersHammar Resolution: Fixed 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] [config-file-provider-plugin] (JENKINS-22939) Temporary config file should not be world-readable
Title: Message Title Anders Hammar commented on JENKINS-22939 Re: Temporary config file should not be world-readable +1 for option 1. 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] [config-file-provider-plugin] (JENKINS-16706) Configure provided settings.xml at the Maven plugin level, not at the Maven job level
Title: Message Title Anders Hammar commented on JENKINS-16706 Re: Configure provided settings.xml at the Maven plugin level, not at the Maven job level Just to be clear, this default setting can be overridden on projetc level. But for every new project it is going to be the the default configuration. However, it will not affect any existing project. Maybe that's the confusion here. 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] [config-file-provider-plugin] (JENKINS-29720) Possibility to add credentials to Maven settings on project level
Title: Message Title Anders Hammar created an issue Jenkins / JENKINS-29720 Possibility to add credentials to Maven settings on project level Issue Type: Improvement Assignee: Dominik Bartholdi Components: config-file-provider-plugin Created: 30/Jul/15 12:17 PM Environment: n/a Priority: Major Reporter: Anders Hammar Today you configure credentials for Maven (global) settings file on Jenkins level. So all projects use the same credentials. Sometimes it would be good to be able to specify which credentials to use on project level though. A special use case that could utilize this functionality would be JENKINS-27033, where the m2release-plugin would supply credentials on build time based on user input. This would then require a methods for this in the config-file-provider-plugin. I'm thinking this use case could also be applicable in workflows.
[JIRA] [config-file-provider-plugin] (JENKINS-22939) Temporary config file should not be world-readable
Title: Message Title Anders Hammar commented on JENKINS-22939 Re: Temporary config file should not be world-readable I checked the source for v2.8.1 and option 1 seems to be implemented (in ManagedFileUtil.provisionConfigFiles()). Should this ticket be closed? 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] [config-file-provider-plugin] (JENKINS-16706) Configure provided settings.xml at the Maven plugin level, not at the Maven job level
Title: Message Title Anders Hammar commented on JENKINS-16706 Re: Configure provided settings.xml at the Maven plugin level, not at the Maven job level If you in the Jenkins configuration configure Default (global) settings provider as provided settings.xml, that will be the default configuration for both Maven projects (build step) and freeestyle projects (Maven build step). I've just verified this for settings (not global, but I assume that will work as well) in Jenkins LTS 1.609.2 with config-file-provider-plugin 2.8.1 (and maven-project-plugin 1.6). 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] [m2release-plugin] (JENKINS-27075) override default SCM tag from ${project.artifactid}-${project.version} to something else
Title: Message Title
Anders Hammar commented on JENKINS-27075
Re: override default SCM tag from ${project.artifactid}-${project.version} to something else
What we do is that we use the standard configuration of maven-release-plugin: http://maven.apache.org/maven-release/maven-release-plugin/prepare-mojo.html#tagNameFormat
You then configure this in the pom of the project, or possibly even in your corporate parent pom.
The Jenkins UI might not reflect the configured value correctly as the default one though (I don't remember), but as long as you keep that box unchecked the value configured for m-release-p will be used.
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] [config-file-provider-plugin] (JENKINS-29709) Missing relase/tag för v2.8.1 in Github
Title: Message Title Anders Hammar created an issue Jenkins / JENKINS-29709 Missing relase/tag fr v2.8.1 in Github Issue Type: Bug Assignee: Dominik Bartholdi Components: config-file-provider-plugin Created: 29/Jul/15 8:04 PM Environment: github Priority: Minor Reporter: Anders Hammar There is no tag/release for version 2.8.1. It seems (based on the info in the pom) as the tag/release 2.9 is actaully v2.8.1. Would it be possible to create a tag/release with the correct name to remove any confusion? Add Comment
[JIRA] [config-file-provider-plugin] (JENKINS-29710) Hostname credentials show up in the Edit settings.xml page
Title: Message Title Anders Hammar created an issue Jenkins / JENKINS-29710 Hostname credentials show up in the Edit settings.xml page Issue Type: Bug Assignee: Dominik Bartholdi Components: config-file-provider-plugin Created: 29/Jul/15 8:15 PM Environment: Jenkins LTS v1.609.2, config-file-provider-plugin v2.8.1, credentials-plugin v.1.22 Priority: Minor Reporter: Anders Hammar When creating/editing a Maven settings.xml file (either global or non-global) and adding (or editing) a server credentials, hostname specification credentials I have show up in the list. They are always in the list, if serverId is blank () or if I have something specified. This is wrong as only Maven serverid specification credentials should be listed. Add Comment
[JIRA] [config-file-provider-plugin] (JENKINS-29709) Missing relase/tag för v2.8.1 in Github
Title: Message Title Anders Hammar updated an issue Jenkins / JENKINS-29709 Missing relase/tag fr v2.8.1 in Github Change By: Anders Hammar Priority: Minor Trivial 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] [envinject-plugin] (JENKINS-29667) Text description in plugin manager shouldn't be in bold
Title: Message Title Anders Hammar created an issue Jenkins / JENKINS-29667 Text description in plugin manager shouldn't be in bold Issue Type: Bug Assignee: Gregory Boissinot Attachments: envinject-bold-desc.png Components: envinject-plugin Created: 28/Jul/15 6:44 AM Priority: Trivial Reporter: Anders Hammar The plugin's text description in the plugin manager's installed tab is differently formatted than other plugins (bold text etc.). See attachment. Add Comment
[JIRA] [maven-plugin] (JENKINS-4428) MavenProbeAction exposes password parameters
Title: Message Title Anders Hammar commented on JENKINS-4428 Re: MavenProbeAction exposes password parameters Until this is fixed, would it be possible to add a config option to turn this monitor feature off? 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] [m2release-plugin] (JENKINS-27869) entered SCM password should be masked in output
Title: Message Title Anders Hammar commented on JENKINS-27869 Re: entered SCM password should be masked in output The same will happen if SCM password environment variable is configured. The thing with the output above is that the maven-help-plugin prints all environment variables as part of the Maven build execution. If the Jenkins m2release plugin could mask that it would be great. However, that is not the only problem as these passwords are also revealed as part of the Jenkins Maven plugin: JENKINS-4428 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] [build-user-vars-plugin] (JENKINS-20787) BUILD_USER_ID is not set in Maven build execution triggered by release:perform
Title: Message Title Anders Hammar commented on JENKINS-20787 Re: BUILD_USER_ID is not set in Maven build execution triggered by release:perform Refreshing my memory I verified this for the m2release-plugin and JENKINS-20791 solves it and v0.14.0 is verified to work. The other plugins I don't know. 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] [m2release-plugin] (JENKINS-29675) No mail on failed release build
Title: Message Title
Anders Hammar updated an issue
Jenkins / JENKINS-29675
No mail on failed release build
Change By:
Anders Hammar
Onafailedreleasebuild,nomailissent(totheoneinitiatingthebuild).Itworksonordinarybuilds (triggeredmanuallyorbyscmpolling) ,butonreleasebuildsitsays:{quote}Anattempttosendane-mailtoemptylistofrecipients,ignored.{quote}
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] [build-user-vars-plugin] (JENKINS-20787) BUILD_USER_ID is not set in Maven build execution triggered by release:perform
Title: Message Title Anders Hammar commented on JENKINS-20787 Re: BUILD_USER_ID is not set in Maven build execution triggered by release:perform dan tran What PR is that? I can't find one. 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] [build-user-vars-plugin] (JENKINS-20787) BUILD_USER_ID is not set in Maven build execution triggered by release:perform
Title: Message Title Anders Hammar edited a comment on JENKINS-20787 Re: BUILD_USER_ID is not set in Maven build execution triggered by release:perform RefreshingmymemoryIverifiedthisforthem2release-pluginandJENKINS-20791solvesitandv0.14.0isverifiedtowork.Theother plugins plugin(release-plugin) Idon'tknow. 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] [m2release-plugin] (JENKINS-29675) No mail on failed release build
Title: Message Title Anders Hammar updated an issue Jenkins / JENKINS-29675 No mail on failed release build Change By: Anders Hammar Attachment: jenkins-29675.png 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] [m2release-plugin] (JENKINS-29675) No mail on failed release build
Title: Message Title Anders Hammar updated an issue Jenkins / JENKINS-29675 No mail on failed release build Change By: Anders Hammar Environment: JenkinsLTSv1.609.1, m2release- pluginv0.14.0 ,mailer-pluginv1.15 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] [m2release-plugin] (JENKINS-29675) No mail on failed release build
Title: Message Title Anders Hammar closed an issue as Not A Defect I'm closing this as I think it's me confusing things here. There are no changes in the release build and therefore there are no culprits to mail. The normal builds typically have changes and therefore culprits (hence mail is sent). Jenkins / JENKINS-29675 No mail on failed release build Change By: Anders Hammar Status: Open Closed Resolution: NotADefect 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] [m2release-plugin] (JENKINS-13527) Expose custom SCM tag and SCM login Username as environment variables
Title: Message Title Anders Hammar commented on JENKINS-13527 Re: Expose custom SCM tag and SCM login Username as environment variables SCM username and password can be exposed as env vars if configure for that in the Jenkins project configuration. 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] [m2release-plugin] (JENKINS-29675) No mail on failed release build
Title: Message Title Anders Hammar commented on JENKINS-29675 Re: No mail on failed release build I wonder if this is related to JENKINS-20787? 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] [m2release-plugin] (JENKINS-29675) No mail on failed release build
Title: Message Title Anders Hammar created an issue Jenkins / JENKINS-29675 No mail on failed release build Issue Type: Bug Assignee: James Nord Components: m2release-plugin Created: 28/Jul/15 12:57 PM Environment: Jenkins LTS v1.609.1, plugin v0.14.0 Priority: Minor Reporter: Anders Hammar On a failed release build, no mail is sent (to the one initiating the build). It works on ordinary builds, but on release builds it says: An attempt to send an e-mail to empty list of recipients, ignored. Add Comment
[JIRA] [m2release-plugin] (JENKINS-8107) Use Hudson login (already possible) and password (not yet possible) to release in maven
Title: Message Title Anders Hammar commented on JENKINS-8107 Re: Use Hudson login (already possible) and password (not yet possible) to release in maven Having the scm username default to Jenkins login user id would be nice. Either always or have a config option for this. I don't think it is possible to get the password though. At least it shouldn't as that would imply that it is stored in clear text somewhere in memory which I very much hope it isn't. 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] [m2release-plugin] (JENKINS-27033) Use user credential for Maven deploy
Title: Message Title Anders Hammar commented on JENKINS-27033 Re: Use user credential for Maven deploy This would be awesome! For now I'm exposing the scm creds as env variables and use an extension to the http wagon that picks that up and uses it instead of the creds from settings.xml. 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] [rundeck-plugin] (JENKINS-28081) Make plugin compatible with new Jenkins workflow
Anders Hammar created JENKINS-28081 Make plugin compatible with new Jenkins workflow Issue Type: Improvement Assignee: Vincent Behar Components: rundeck-plugin Created: 24/Apr/15 9:05 AM Description: It would be great to be able to use rundeck steps in the new Jenkins Workflow project style. It will require some updates to the plugin though. https://github.com/jenkinsci/workflow-plugin/blob/master/basic-steps/CORE-STEPS.md Environment: n/a Project: Jenkins Priority: Minor Reporter: Anders Hammar This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [rundeck-plugin] (JENKINS-22479) Rundeck plugin apiVersion change does not persist
Anders Hammar commented on JENKINS-22479 Rundeck plugin apiVersion change does not persist I've looked into this and the reason for that the apiVersion doesn't show up in the general config page is that the shown value is retrieved from the existing RundeckClient class, which is not possible. Maybe it was possible earlier, I don't know. Looking into this I see that the problem migth even be bigger; the RundeckClient is currently created from the stored values through reflection calls. I don't know if that creates it correctly (sets the apiVersion etc). The correct way should be to create it via RundeckClientBuilder. I tried to figure out how to create an xstream converter to do this, but didn't really manage in the time frame I had available. One other thing I was thinking about is that with the current solution around apiVersion, if the field is left blank (default) it will in fact be persisted as the current API version of the Rundeck client lib used. So when upgrading the rundeck plugin, the apiVersion will not follow along but stay with theearlier version. Not what the help text for the apiVersion field says and what I think it should work. It should be possible to not specify an apiVersion and then always use the default version. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [rundeck-plugin] (JENKINS-22479) Rundeck plugin apiVersion change does not persist
Anders Hammar commented on JENKINS-22479 Rundeck plugin apiVersion change does not persist I believe the problem is even worse, the apiVersion doesn't seem to be used at all. At least not for the test connection. Still a problem in v3.4. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [rundeck-plugin] (JENKINS-28059) API Version is not used in test connection
Anders Hammar created JENKINS-28059 API Version is not used in test connection Issue Type: Bug Assignee: Vincent Behar Components: rundeck-plugin Created: 23/Apr/15 9:18 AM Description: When performing a test connection (in teh global config) the specified API version is not honored. Environment: rundeck-plugin v3.4 Project: Jenkins Priority: Minor Reporter: Anders Hammar This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [rundeck-plugin] (JENKINS-22479) Rundeck plugin apiVersion change does not persist
Anders Hammar commented on JENKINS-22479 Rundeck plugin apiVersion change does not persist Digging into this I realize that the API version not being used in the test connection is a separate issue. Will open a separate ticket for that. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [rundeck-plugin] (JENKINS-27983) Rundeck does not use Jenkins proxy settings
Anders Hammar commented on JENKINS-27983 Rundeck does not use Jenkins proxy settings I've run into the same problem and the root cause is in the underlaying rundeck API java client library. What I did locally was to patch that library and did a custom build of the plugin. The proxy stuff is changing in the upcoming version for v13 of the Rundeck API. It will then pick up the http.proxyHost et al system properties. If we want the plugin to use the Jenkins proxy config hte plugin needs to be updated to handle that. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [rundeck-plugin] (JENKINS-22479) Rundeck plugin apiVersion change does not persist
Anders Hammar edited a comment on JENKINS-22479 Rundeck plugin apiVersion change does not persist Digging into this I realize that the API version not being used in the test connection is a separate issue. Will open a separate ticket for that (JENKINS-28059). This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [rundeck-plugin] (JENKINS-28059) API Version is not used in test connection
Anders Hammar assigned JENKINS-28059 to Anders Hammar API Version is not used in test connection Change By: Anders Hammar (23/Apr/15 9:19 AM) Assignee: VincentBehar AndersHammar This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [rundeck-plugin] (JENKINS-27971) NPE with Rundeck v2.4.2
Anders Hammar commented on JENKINS-27971 NPE with Rundeck v2.4.2 A quick test of upgrading the rundeck-client in the plugin to v12.0 (which Rundeck 2.4.2 uses) fixes this. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [rundeck-plugin] (JENKINS-27971) NPE with Rundeck v2.4.2
Anders Hammar created JENKINS-27971 NPE with Rundeck v2.4.2 Issue Type: Bug Assignee: Vincent Behar Components: rundeck-plugin Created: 16/Apr/15 7:13 AM Description: In a Jenkins job triggering a job in Rundeck, I get a NPE: java.lang.NullPointerException at org.rundeck.api.parser.ExecutionParser.parseXmlNode(ExecutionParser.java:52) at org.rundeck.api.parser.ExecutionParser.parseXmlNode(ExecutionParser.java:30) at org.rundeck.api.ApiCall.execute(ApiCall.java:315) at org.rundeck.api.ApiCall.get(ApiCall.java:180) at org.rundeck.api.RundeckClient.triggerJob(RundeckClient.java:1066) at org.jenkinsci.plugins.rundeck.RundeckNotifier.notifyRundeck(RundeckNotifier.java:168) at org.jenkinsci.plugins.rundeck.RundeckNotifier.perform(RundeckNotifier.java:88) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770) at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:734) at hudson.model.Build$BuildExecution.post2(Build.java:183) at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:683) at hudson.model.Run.execute(Run.java:1784) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) The job is successfully triggered though in Rundeck. The NPE occurs in Jenkins when trying to parse the answer. The config of the rundeck-plugin in Jenkins is the URL and the auth token. No API version specified (thus, default v9 is used). Environment: Jenkins LTS 1.596.2, JDK 1.7.0_72, Windows 7, rundeck-plugin v3.3 Rundeck 2.4.2, JDK 1.7.0_72, Windows 7 Project: Jenkins Priority: Minor Reporter: Anders Hammar This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [workflow-plugin] (JENKINS-26085) Credentials support for git step
Anders Hammar commented on JENKINS-26085 Credentials support for git step Only for git, not for svn? Why? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [workflow-plugin] (JENKINS-27275) Credentials support for svn step
Anders Hammar created JENKINS-27275 Credentials support for svn step Issue Type: Improvement Assignee: Jesse Glick Components: workflow-plugin Created: 06/Mar/15 11:14 PM Description: Support for specifying credentials for the svn step. (As JENKINS-26085, but for svn.) Project: Jenkins Priority: Minor Reporter: Anders Hammar This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [workflow-plugin] (JENKINS-27252) Workflow project build hangs for Groovy script error
Anders Hammar created JENKINS-27252 Workflow project build hangs for Groovy script error Issue Type: Bug Assignee: Jesse Glick Components: workflow-plugin Created: 05/Mar/15 8:07 AM Description: I have a workflow project, for which I typed an error inte the Groovy script. When executing the build it then reports an error in the console and then hangs (doesn't terminate). This is the output in the build console: Started by user Anders Hammar ERROR: failed to start build org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: WorkflowScript: 4: unexpected char: '\' @ line 4, column 74. n.repo.local=.repository -s D:\Jenkins\s ^ 1 error at org.codehaus.groovy.control.ErrorCollector.failIfErrors(ErrorCollector.java:302) at org.codehaus.groovy.control.ErrorCollector.addFatalError(ErrorCollector.java:149) at org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:119) at org.codehaus.groovy.control.ErrorCollector.addError(ErrorCollector.java:131) at org.codehaus.groovy.control.SourceUnit.addError(SourceUnit.java:359) at org.codehaus.groovy.antlr.AntlrParserPlugin.transformCSTIntoAST(AntlrParserPlugin.java:137) at org.codehaus.groovy.antlr.AntlrParserPlugin.parseCST(AntlrParserPlugin.java:108) at org.codehaus.groovy.control.SourceUnit.parse(SourceUnit.java:236) at org.codehaus.groovy.control.CompilationUnit$1.call(CompilationUnit.java:161) at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:846) at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:550) at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:526) at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:503) at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:302) at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:281) at groovy.lang.GroovyShell.parseClass(GroovyShell.java:731) at groovy.lang.GroovyShell.parse(GroovyShell.java:743) at org.jenkinsci.plugins.workflow.cps.CpsGroovyShell.reparse(CpsGroovyShell.java:100) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.parseScript(CpsFlowExecution.java:349) at org.jenkinsci.plugins.workflow.cps.CpsFlowExecution.start(CpsFlowExecution.java:317) at org.jenkinsci.plugins.workflow.job.WorkflowRun.run(WorkflowRun.java:173) at hudson.model.ResourceController.execute(ResourceController.java:89) at hudson.model.Executor.run(Executor.java:240) at hudson.model.OneOffExecutor.run(OneOffExecutor.java:43) Environment: Windows Server 2008, Oracle JDK 1.7.0_55, Jenkins LTS 1.596.1, Workflow plugin 1.2 Project: Jenkins Priority: Major Reporter: Anders Hammar This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [workflow-plugin] (JENKINS-27252) Workflow project build hangs for Groovy script error
Anders Hammar commented on JENKINS-27252 Workflow project build hangs for Groovy script error I use Groovy script sandboxing btw. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [workflow-plugin] (JENKINS-27252) Workflow project build hangs for Groovy script error
Anders Hammar updated JENKINS-27252 Workflow project build hangs for Groovy script error Change By: Anders Hammar (05/Mar/15 10:22 AM) Environment: WindowsServer2008,OracleJDK1.7.0_55,JenkinsLTS1.596.1,Workflowplugin1. 2 3 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [workflow-plugin] (JENKINS-26138) Better support for workspaces
Anders Hammar commented on JENKINS-26138 Better support for workspaces If the flow graph UI isn't available in the OSS version there needs to be some other way to manage the workspace, e.g. delete it. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [config-file-provider-plugin] (JENKINS-26171) Add credentials labels to plugin wiki page
Anders Hammar created JENKINS-26171 Add credentials labels to plugin wiki page Issue Type: Improvement Assignee: Dominik Bartholdi Components: config-file-provider-plugin Created: 19/Dec/14 7:42 AM Description: As the plugin provides credentials, it should be labeled as "credentials-provider" on wiki page. Also, I guess it should be labeled as "credentials-consumer" as well? I tried to do this myself but get an error message and the label(s) isn't added. Environment: n/a Project: Jenkins Priority: Trivial Reporter: Anders Hammar This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [config-file-provider-plugin] (JENKINS-26171) Add credentials labels to plugin wiki page
Anders Hammar commented on JENKINS-26171 Add credentials labels to plugin wiki page I managed do add these two labels after all. Could someone please verify that my understanding that the plugin is a provider consumer of the credentials plugin. Strangely, the plugin doesn't show up in the lists on the Credentials plugin wiki page. Maybe it takes some time to update. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [config-file-provider-plugin] (JENKINS-26171) Add credentials labels to plugin wiki page
Anders Hammar edited a comment on JENKINS-26171 Add credentials labels to plugin wiki page I managed do add these two labels after all. Could someone please second that the plugin is a provider consumer of the credentials plugin? Strangely, the plugin doesn't show up in the lists on the Credentials plugin wiki page. Maybe it takes some time to update. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [m2release-plugin] (JENKINS-21063) Indicate in icon (or tooltip) if a release build failed
Anders Hammar resolved JENKINS-21063 as Fixed Indicate in icon (or tooltip) if a release build failed Change By: Anders Hammar (30/Oct/14 7:23 AM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [core] (JENKINS-11046) Project deletion does not wipe out project workspaces
Anders Hammar commented on JENKINS-11046 Project deletion does not wipe out project workspaces A project's workspace is still not removed when deleting a project, seen in latest Jenkins as of today (v1.587). This with default setup and no extra plugins, on Windows 7 and JDK 1.6. A side effect of this is that if a project is deleted and then a new project is created with the same name, the old workspace is then reused. Very confusing! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [ws-cleanup-plugin] (JENKINS-25371) The Open Issues link on the wiki page doesn't work
Anders Hammar created JENKINS-25371 The Open Issues link on the wiki page doesnt work Issue Type: Task Assignee: vjuranek Components: ws-cleanup-plugin Created: 30/Oct/14 7:45 AM Description: The "Open Issues" link on the plugin's wiki page states the wrong JIRA component. It should be "ws-cleanup-plugin (not "ws-cleanup"). Environment: wiki page Project: Jenkins Priority: Minor Reporter: Anders Hammar This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [ws-cleanup-plugin] (JENKINS-11054) Support policies for workspace cleanup
Anders Hammar commented on JENKINS-11054 Support policies for workspace cleanup I'd like the possibility to trigger a cleanup once per day for example. In my case I would use it to delete the workspace local maven repository. Also, it would be great to have the cleanup triggered based on things like environment variables and such. For example, I'd like a workspace cleanup when I perform releases with the m2 release plugin, which sets an environment variable when a release is performed. But I suppose other triggers should also be possible. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [ws-cleanup-plugin] (JENKINS-21322) Cleanup workspace when last build is X days ago
Anders Hammar commented on JENKINS-21322 Cleanup workspace when last build is X days ago I don't really understand the use case here. Are you saying that you would like the workspace to be cleaned if the last build was, for example, more than 2 days ago? So then if there is at least one build every day, the workspace is never cleaned? The use case I have is that I want the workspace to be cleaned every day, but not more than once per day. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [disk-usage] (JENKINS-22389) Job directory size shown in trend graph does not show the trend
Anders Hammar updated JENKINS-22389 Job directory size shown in trend graph does not show the trend Attaching a screen shot of the trend graph from 0.24-SNAPSHOT of the plugin. As you can see the job directory (green area) is drawn at 590KB for all builds. This cannot be correct, but it should have started at somewhere around 200KB for hte first build and then grown. Checking the code also confirms that it is the current job directory size that is used for all graph plots. Change By: Anders Hammar (28/Mar/14 7:44 AM) Attachment: DiskUsage_JENKINS-22389.png This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [disk-usage] (JENKINS-21325) Strange Disk Usage message.
Anders Hammar commented on JENKINS-21325 Strange Disk Usage message. I believe this has been fixed in commit 54986c7e. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [disk-usage] (JENKINS-19070) Disk usage doesn't work - 1.523+
Anders Hammar commented on JENKINS-19070 Disk usage doesnt work - 1.523+ I'm using disk-usage v0.23 on Jenkins LTS 1.532.2 and it works just fine. I think this ticket should be closed. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [disk-usage] (JENKINS-22389) Job directory size shown in trend graph does not show the trend
Anders Hammar created JENKINS-22389 Job directory size shown in trend graph does not show the trend Issue Type: Bug Assignee: Lucie Votypkova Components: disk-usage Created: 27/Mar/14 3:55 PM Description: In the trend graph, the job directory size shown is not the trend. It is the current size for all plotted builds. Environment: plugin 0.24-SNAPSHOT (and 0.23 I think) Project: Jenkins Priority: Major Reporter: Anders Hammar This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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] [disk-usage] (JENKINS-13572) Disk usage trend graph is not displayed on project page
Anders Hammar commented on JENKINS-13572 Disk usage trend graph is not displayed on project page I use disk-usage plugin v0.23 on Jenkins LTS 1.532.2 and it works just fine. I think this ticket can be closed. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- 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.
