[JIRA] (JENKINS-36453) Replay does not reuse commit on non-multibranch pipeline jobs
Title: Message Title Brian J Murrell commented on JENKINS-36453 Re: Replay does not reuse commit on non-multibranch pipeline jobs Replay is actually not the central issue. scm for a CpsScmFlowDefinition is not guaranteed to match the commit of Jenkinsfile. This is because it is using hudson.model.SCM, i.e., the old core APIs, which do not support checking out a specific version. In order to fix this we would have to actually deprecate CpsScmFlowDefinition and provide a replacement using scm-api so it would behave more like multibranch, except of course for a predefined branch. Is this why, when I Replay a given build of a given multi-branch pipeline job, the Jenkinsfile is checked out at the commit build I'm Replaying was at, however a checkout in the pipeline job does not get the same commit? Is it because the scm.branches doesn't point at the commit of the Replay but rather points at the branch? If so, this is pretty horrible. Shouldn't one be able to depend on the global scm variable containing an accurate representation of what is being checked out (implicitly)? Why does the implicit checkout get the right commit and yet an explicit checkout doesn't? 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
[JIRA] (JENKINS-49540) Rebuild Commit
Title: Message Title Brian J Murrell commented on JENKINS-49540 Re: Rebuild Commit This looks like a duplicate of JENKINS-39218. 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.188443.1518550656000.22719.1588780200356%40Atlassian.JIRA.
[JIRA] (JENKINS-49540) Rebuild Commit
Title: Message Title Brian J Murrell updated an issue Jenkins / JENKINS-49540 Rebuild Commit Change By: Brian J Murrell Comment: This looks like a duplicate of JENKINS-39218. 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.188443.1518550656000.22721.1588780200379%40Atlassian.JIRA.
[JIRA] (JENKINS-39218) Rebuild uses the wrong commit
Title: Message Title Brian J Murrell commented on JENKINS-39218 Re: Rebuild uses the wrong commit To be frank, rebuilding on the commit of the job that the Rebuild link was clicked from feels like a basic requirement of calling the functionality that this plugin provides rebuild. Maybe the link that this plugin provides in a job's menu should be Re-use parameters or something. But unless using the same commit is included in the functionality, Rebuild probably deceives more people than it doesn't. 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.175645.1477326835000.22668.1588773120247%40Atlassian.JIRA.
[JIRA] (JENKINS-56395) Expose "trusted" attribute of a PR to the Pipeline
Title: Message Title
Brian J Murrell commented on JENKINS-56395
Re: Expose "trusted" attribute of a PR to the Pipeline
Craig Barber Your desire for this appears to be the same as mine – to build into my {{Jenkinsfile}}s the ability to prevent non-trusted people's PRs from being run through our CI. The irony of this whole ticket is that while this functionality could be useful for other reasons, we are desiring it simply because the mechanisms built into Jenkins that are supposed to provide this functionality are simply broken. If they worked, I wouldn't have opened this ticket.
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.197985.1551728691000.22546.1588765200197%40Atlassian.JIRA.
[JIRA] (JENKINS-62079) No way to email just a PR's owner
Title: Message Title Brian J Murrell commented on JENKINS-62079 Re: No way to email just a PR's owner I am using the github-branch-source plugin with pipelines. Ultimately the problem is that (AFAICT) the most useful recipientProvider to use with a single PR is: developers Sends email to all the people who caused a change in the change set. But as I mentioned before that list gets polluted with every author of every patch that was merged from a parent branch when doing a merge to get one's PR up-to-date with it's parent branch. 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.205984.1588084934000.19617.1588182900112%40Atlassian.JIRA.
[JIRA] (JENKINS-62079) No way to email just a PR's owner
Title: Message Title Brian J Murrell commented on JENKINS-62079 Re: No way to email just a PR's owner I do not know about the owner of the primary patch being lost Not lost, but not identifiable as the single individual for which the patches in the PR belong, among the many authors of the perhaps many patches that got added from a merged branch (i.e. again, when say, merging master to a PR). 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.205984.1588084934000.19602.1588181220134%40Atlassian.JIRA.
[JIRA] (JENKINS-62079) No way to email just a PR's owner
Title: Message Title Brian J Murrell commented on JENKINS-62079 Re: No way to email just a PR's owner Yeah, I suspected email-ext wouldn't have access to GH info. It's interesting that another plugin can implement a recipientProvider. Is my observation correct about a PR that merges other patches into it, such as say, merging another (i.e. master) branch, the single owner of the primary patch of the PR is lost and there is no existing recipientProvider that will distinguish that owner (of the primary patch) on the PR from all of the owners of patches in the merge? 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.205984.1588084934000.19339.1588163700116%40Atlassian.JIRA.
[JIRA] (JENKINS-62080) PR owner information in Pipeline?
Title: Message Title Brian J Murrell created an issue Jenkins / JENKINS-62080 PR owner information in Pipeline? Issue Type: Bug Assignee: Unassigned Components: github-branch-source-plugin Created: 2020-04-28 14:50 Priority: Minor Reporter: Brian J Murrell Is GitHub PR information available in an object/variable/etc. in a Pipeline job? I'd like to be able to send an e-mail to a PR's owner/author for example. But just the PR owner/author, not any of the authors of any other patches that may be merged into the PR, so I don't think any of email-ext's current recipientProviders can do this. So instead I'd like to get the PR owner from this plugin and use it as the recipient in an email-ext call. Add Comment
[JIRA] (JENKINS-62079) No way to email just a PR's owner
Title: Message Title Brian J Murrell created an issue Jenkins / JENKINS-62079 No way to email just a PR's owner Issue Type: Bug Assignee: Alex Earl Components: email-ext-plugin Created: 2020-04-28 14:42 Priority: Major Reporter: Brian J Murrell I can't seem to figure out any recipientProviders that contact just a (GitHub) PR's owner/author, in all cases. In simple cases, where somebody creates a PR and pushes a few patches, developers seems like the right target. But as soon as the PR owner merges with master, that becomes every patch owner in the merge also, correct? Is there an option I am missing here to achieve what I am looking for? Add Comment
[JIRA] (JENKINS-43820) Stage name must be a string literal
Title: Message Title Brian J Murrell commented on JENKINS-43820 Re: Stage name must be a string literal This gets really, super ugly in the context of matrix. Surely you can see how not being able to substitute a variable into the stage name makes this a much less-than-useful representation of the job: I have no idea what any of those stages are without hovering over the "Matrix" text for each combination. 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.181338.1493122184000.15166.1587499740777%40Atlassian.JIRA.
[JIRA] (JENKINS-43820) Stage name must be a string literal
Title: Message Title Brian J Murrell updated an issue Jenkins / JENKINS-43820 Stage name must be a string literal Change By: Brian J Murrell Attachment: screenshot-matrix.png 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.181338.1493122184000.15128.1587499681330%40Atlassian.JIRA.
[JIRA] (JENKINS-56255) occasionally builds the branch for a PR also
Title: Message Title Brian J Murrell commented on JENKINS-56255 Re: occasionally builds the branch for a PR also Roman Pickl No unfortunately not, per my previous comment. 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.197825.1550941413000.11099.1586881080142%40Atlassian.JIRA.
[JIRA] (JENKINS-56255) occasionally builds the branch for a PR also
Title: Message Title Brian J Murrell commented on JENKINS-56255 Re: occasionally builds the branch for a PR also OK. So I am back. There is something more flawed than just a race between new branch and PR discovery going on here. This doesn't just happen on initial branch/PR creation (i.e Build #1) but happens on subsequent pushes to the PR/branch. If this were just a race, subsequent pushes would not fall victim to this, correct? Additionally, working from forks (as much as my users really want to do it) is actually, unworkable due to these bugs. But working from forks or not is actually quite orthogonal, as I have described above, this does not seem to merely be a race condition on new branches/forks. This doesn't seem to be "by design". This seems like an actual bug. 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.197825.1550941413000.7709.1586277360205%40Atlassian.JIRA.
[JIRA] (JENKINS-61732) additional refspecs at the organisational level is unworkable
Title: Message Title Brian J Murrell commented on JENKINS-61732 Re: additional refspecs at the organisational level is unworkable OK. So then, is using a "bare" checkout command effectively do the same thing as not specifying skipDefaultCheckout? 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.205560.1585492427000.4508.1585763160116%40Atlassian.JIRA.
[JIRA] (JENKINS-61732) additional refspecs at the organisational level is unworkable
Title: Message Title Brian J Murrell commented on JENKINS-61732 Re: additional refspecs at the organisational level is unworkable Fair enough. How can one find out what the parameters to the default checkout are being used? IOW, if I wanted to start with replicating exactly what the default checkout does and then alter it to my needs, how would I know what that default checkout looks like? 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.205560.1585492427000.4411.1585759500130%40Atlassian.JIRA.
[JIRA] (JENKINS-61732) additional refspecs at the organisational level is unworkable
Title: Message Title Brian J Murrell created an issue Jenkins / JENKINS-61732 additional refspecs at the organisational level is unworkable Issue Type: Bug Assignee: Mark Waite Components: git-plugin Created: 2020-03-29 14:33 Priority: Critical Reporter: Brian J Murrell I'm using a github organization with declarative pipeline to build many projects in our organisation. I need some (one currently) project to fetch additional refspecs so that a job can do git operations on them. This however breaks for any projects that don't have all of the additional refspecs in them. It seems unrealistic to expect every project within an organisation to have all of the additional refspecs. Add Comment
[JIRA] (JENKINS-58085) BlueOcean UI stuck in "Waiting for run to start"
Title: Message Title Brian J Murrell commented on JENKINS-58085 Re: BlueOcean UI stuck in "Waiting for run to start" Devin Nusbaum A screenshot of the graph for the pipeline when in this state looks just like the existing two screenshots. 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.200110.1560887329000.892.1581954121406%40Atlassian.JIRA.
[JIRA] (JENKINS-61053) submodule checkout randomly fails without failing the job
Title: Message Title Brian J Murrell commented on JENKINS-61053 Re: submodule checkout randomly fails without failing the job Francisco Fernández Total SWAG: 50% or more of the time. i can only SWAG because as soon as it became apparent that it was doing it, I had to disable the feature as it was our production Jenkins server. As for the pairs, at this point in time, I simply don't have the time to be doing roll-backs/forwards and waiting and watching builds to see how many break. I have too many other $day-job tasks that need to get done. I've created a ticket in our local ticketing system to get this debugging done. Either somebody else here might have time to do it, or it will have to wait until I have time. 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.204533.1581430986000.8271.1581536400243%40Atlassian.JIRA.
[JIRA] (JENKINS-61053) submodule checkout randomly fails
Title: Message Title
Brian J Murrell updated an issue
Jenkins / JENKINS-61053
submodule checkout randomly fails
Change By:
Brian J Murrell
I have enabled submodule checkout in our configured GitHub organisation:!image-2020-02-11-09-12-02-680.png!However, when checking out projects now, intermittently, the checkout will fail with no indication why:{noformat} [ 2020-02-11T13:23:18.590Z] using credential daos_jenkins_project_github_access[2020-02-11T13:23:18.611Z] Fetching changes from the remote Git repository[2020-02-11T13:23:18.620Z] Fetching without tags[2020-02-11T13:23:18.602Z] > git rev-parse --is-inside-work-tree # timeout=10[2020-02-11T13:23:18.614Z] > git config remote.origin.url https://github.com/daos-stack/daos.git # timeout=10[2020-02-11T13:23:18.623Z] Fetching upstream changes from https://github.com/daos-stack/daos.git[2020-02-11T13:23:18.623Z] > git --version # timeout=10[2020-02-11T13:23:18.627Z] using GIT_ASKPASS to set credentials GitHub account for github project use (daos_jenkins_project_github_access)[2020-02-11T13:23:18.628Z] > git fetch --no-tags --progress https://github.com/daos-stack/daos.git +refs/pull/1818/head:refs/remotes/origin/PR-1818 # timeout=10[2020-02-11T13:23:20.000Z] Checking out Revision 1f757ccc6f67e2611cf704671ebd199c1cc852e9 (PR-1818)[2020-02-11T13:23:20.065Z] Commit message: "DAOS-2746 test: Add junit-capable go test runner"[2020-02-11T13:23:20.003Z] > git config core.sparsecheckout # timeout=10[2020-02-11T13:23:20.007Z] > git checkout -f 1f757ccc6f67e2611cf704671ebd199c1cc852e9 # timeout=10[2020-02-11T13:23:20.072Z] > git remote # timeout=10[2020-02-11T13:23:20.076Z] > git submodule init # timeout=10[2020-02-11T13:23:20.172Z] > git submodule sync # timeout=10[2020-02-11T13:23:20.284Z] > git config --get remote.origin.url # timeout=10[2020-02-11T13:23:20.292Z] > git submodule init # timeout=10[2020-02-11T13:23:20.380Z] > git config -f .gitmodules --get-regexp ^submodule\.(.+)\.url # timeout=10[2020-02-11T13:23:20.384Z] > git config --get submodule.scons_local.url # timeout=10[2020-02-11T13:23:20.387Z] > git remote # timeout=10[2020-02-11T13:23:20.391Z] > git config --get remote.origin.url # timeout=10[2020-02-11T13:23:20.394Z] > git config -f .gitmodules --get submodule.scons_local.path # timeout=10[2020-02-11T13:23:20.398Z] > git config --get submodule.raft.url # timeout=10[2020-02-11T13:23:20.401Z] > git remote # timeout=10[2020-02-11T13:23:20.406Z] > git config --get remote.origin.url # timeout=10[2020-02-11T13:23:20.410Z] > git config -f .gitmodules --get submodule.raft.path # timeout=10[2020-02-11T13:23:20.414Z] using GIT_ASKPASS to set credentials GitHub account for github project use (daos_jenkins_project_github_access)[2020-02-11T13:23:20.415Z] > git submodule update --init --recursive scons_local # timeout=10Could not perform submodule update{noformat}And yet at other times, it works:{noformat}[2020-02-10T19:04:15.801Z] using credential daos_jenkins_project_github_access[2020-02-10T19:04:15.825Z] Fetching
[JIRA] (JENKINS-61053) submodule checkout randomly fails
Title: Message Title Brian J Murrell created an issue Jenkins / JENKINS-61053 submodule checkout randomly fails Issue Type: Bug Assignee: Mark Waite Attachments: image-2020-02-11-09-12-02-680.png Components: git-plugin Created: 2020-02-11 14:23 Environment: Jenkins ver. 2.204.1 Git plugin 4.1.1 Priority: Blocker Reporter: Brian J Murrell I have enabled submodule checkout in our configured GitHub organisation: However, when checking out projects now, intermittently, the checkout will fail with no indication why: 2020-02-11T13:23:18.590Z] using credential daos_jenkins_project_github_access [2020-02-11T13:23:18.611Z] Fetching changes from the remote Git repository [2020-02-11T13:23:18.620Z] Fetching without tags [2020-02-11T13:23:18.602Z] > git rev-parse --is-inside-work-tree # timeout=10 [2020-02-11T13:23:18.614Z] > git config remote.origin.url https://github.com/daos-stack/daos.git # timeout=10 [2020-02-11T13:23:18.623Z] Fetching upstream changes from https://github.com/daos-stack/daos.git [2020-02-11T13:23:18.623Z] > git --version # timeout=10 [2020-02-11T13:23:18.627Z] using GIT_ASKPASS to set credentials GitHub account for github project use (daos_jenkins_project_github_access) [2020-02-11T13:23:18.628Z] > git fetch --no-tags --progress https://github.com/daos-stack/daos.git +refs/pull/1818/head:refs/remotes/origin/PR-1818 # timeout=10 [2020-02-11T13:23:20.000Z]
[JIRA] (JENKINS-49142) Be able to customize checkout as "options" in declarative pipeline
Title: Message Title Brian J Murrell commented on JENKINS-49142 Re: Be able to customize checkout as "options" in declarative pipeline This is sorely needed. It's a pity to see that the PR for it died on the vine. It seems the perfect became the enemy of the good perhaps. In any case, all of the zillions of work-arounds (git command in sh step, scm command in stage steps, etc.) for updating submodules once the per-stage default scm checkout is done don't work if the Dockerfile that the stage is supposed to use for it's agent is in the submodule that needs to be checked-out/updated. 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.187978.1516811382000.5553.1581354780243%40Atlassian.JIRA.
[JIRA] (JENKINS-58085) BlueOcean UI stuck in "Waiting for run to start"
Title: Message Title Brian J Murrell commented on JENKINS-58085 Re: BlueOcean UI stuck in "Waiting for run to start" https://raw.githubusercontent.com/daos-stack/daos/master/Jenkinsfile often exhibits the problem in the Functional/Functional_Hardware stages. 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.200110.1560887329000.8112.1579015321503%40Atlassian.JIRA.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Brian J Murrell commented on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script I will investigate if/how this helps the next time we hit the limit. 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.174127.1473169024000.11916.1576668843365%40Atlassian.JIRA.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Brian J Murrell commented on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script Liam Newman I think the point being made, and demonstrated with JenkinsCodeTooLarge.groovy is that even a pipeline that contains nothing except pipeline structure and calls to library functions can blow the limit on size. At some point, as the above pipeline demonstrates, you have factored out as much as you can and still blow the limit. The limit is the problem here, not how much of a pipeline has been factored away in to a library. The latter is just a band-aid, postponing of the inevitable and frankly a wasted investment if you are going to have to end up scrapping the whole thing at some point and moving to an entirely new solution that won't have such inevitable fatal limits. Hopefully the newly available matrix feature will help some people out, but there will still be people with big pipelines that are un-matrixable. 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.174127.1473169024000.10959.1576632721730%40Atlassian.JIRA.
[JIRA] (JENKINS-58604) Full Stage View only showing one
Title: Message Title Brian J Murrell commented on JENKINS-58604 Re: Full Stage View only showing one I've seen suggestions to use Blue Ocean, but there is a crucial flaw with this: the Chuck Norris plugin does not support it. Blue Ocean is simply not a suitable replacement for Stage View. It has it's own bugs and issues. It's heavy – it can take many (very many in some cases) seconds to load, it's often "out of date" telling me that it's waiting for a stage to start when the stage is well under way having executed many steps already. Those are just the issues off the top of my head. 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.200764.1563816065000.10178.1576593060219%40Atlassian.JIRA.
[JIRA] (JENKINS-43348) Option to use author instead of commiter in declarative pipeline
Title: Message Title Brian J Murrell commented on JENKINS-43348 Re: Option to use author instead of commiter in declarative pipeline I have to agree completely that substituting the commiter for what should really be the patch author is really not very useful at all. It doesn't make sense to e-mail the commiter when there is a problem with the patch. It doesn't make sense for Blue Ocean to list the commiter as the person responsible for the change. Is this issue anywhere near completion? 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.180496.1491327788000.11696.1575426300255%40Atlassian.JIRA.
[JIRA] (JENKINS-58085) BlueOcean UI stuck in "Waiting for run to start"
Title: Message Title Brian J Murrell commented on JENKINS-58085 Re: BlueOcean UI stuck in "Waiting for run to start" Can we please have this re-opened. I can confirm it's still happening here on 1.19.0 also. This together with stage-view being pretty crippled means finding logs of currently-running pipelines (i.e. in Pipeline Steps) is pretty cumbersome even for a Jenkins pro. Pretty much unusable for casual users with it's lack of collapsibility, etc. 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.200110.1560887329000.11336.1575387421086%40Atlassian.JIRA.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Brian J Murrell edited a comment on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script [~bitwiseman] But huge undertaking or not, this is a severely limiting (show-stopping in fact) factor. At some point somebody will have done all of the refactoring into a library that is possible and still hit this problem. What is the solution/recommendation for that person?As for 1.5.0-beta1, no, I have not. 1.5.0-beta1 of what exactly? Is there a high-level changelog somewhere highlighting what's going to be new/fixed in it? 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.174127.1473169024000.604.1573730944261%40Atlassian.JIRA.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Brian J Murrell commented on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script Liam Newman But huge undertaking or not, this is a severely limiting (show-stopping in fact) factor. At some point somebody will have done all of the refactoring into a library that is possible and still hit this problem. What is the solution/recommendation for that person? As for 1.5.0-beta1, no, I have not. Is there a high-level changelog somewhere highlighting what's going to be new/fixed in it? 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.174127.1473169024000.532.1573730763218%40Atlassian.JIRA.
[JIRA] (JENKINS-58442) Skip initial build on first branch indexing not working
Title: Message Title Brian J Murrell commented on JENKINS-58442 Re: Skip initial build on first branch indexing not working Indeed. Even just a single line stating that the default is Any Of so that people know it's an OR'd list would be useful. But thanks for the additional information. Very useful. 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.200574.1562853177000.462.1573730460348%40Atlassian.JIRA.
[JIRA] (JENKINS-37984) org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script
Title: Message Title Brian J Murrell commented on JENKINS-37984 Re: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: General error during class generation: Method code too large! error in pipeline Script I wonder how many people are here because of lack of proper matrix jobs in Pipeline. This problem has to be resolved one way or another that works for all currently accepted forms of Jenkinsfile. As pointed out in a previous comment there is a limit to how much you can refactor your Jenkinsfile before Declarative Pipelines are just plain unusable. What happened to the solution hinted at over a year ago that was then: not quite ready to demo or announce something (a few more pieces need to fall into place Are they still waiting to fall into place, over a year later? 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.174127.1473169024000.9682.1573016941357%40Atlassian.JIRA.
[JIRA] (JENKINS-59918) labels and step script content shown inconsistently in blue ocean steps
Title: Message Title
Brian J Murrell updated an issue
Jenkins / JENKINS-59918
labels and step script content shown inconsistently in blue ocean steps
Change By:
Brian J Murrell
Somewhat related to JENKINS-53649 and as described there, but this feels like it deserves it's own ticket.The content of a step in the B/O step summary seems inconsistent: ! image https://issues.jenkins - ci.org/secure/attachment/49301/49301_image- 2019-10-24-07-05-23-113.png!Those two steps in the red box are both of the form:{noformat}sh label: , script: '''...'''{noformat}The first one is in the {{steps}} portion of the stage and looks like:{noformat}sh label: env.STAGE_NAME, script: '''...'''{noformat}and the second one is in the {{post}}->{{success}} portion of the stage and looks like:{noformat} sh label: "Collect artifacts", script: '''...'''{noformat}But as you can see, they are displayed quite differently. But why?It doesn't seem like they should be. The second step shouldn't have the label prefixed with the script content of step.
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
[JIRA] (JENKINS-53649) Strings from the "echo" step are suppressed in BlueOcean UI if they contain values found in an environment variable
Title: Message Title
Brian J Murrell edited a comment on JENKINS-53649
Re: Strings from the "echo" step are suppressed in BlueOcean UI if they contain values found in an environment variable
[~mcw] Even using \{{label:}}s produces inconsistent results:!image-2019-10-24-07-05-23-113.png!Those two steps in the red box are both of the form:{noformat}sh label: , script: '''...'''{noformat}The first one is in the {{steps}} portion of the stage and looks like:{noformat}sh label: env.STAGE_NAME, script: '''...'''{noformat}and the second one is in the {{post}}->{{success}} portion of the stage and looks like:{noformat} sh label: "Collect artifacts", script: '''...'''{noformat} But as you can see, they are displayed quite differently. I've opened JENKINS-59918 about this, FWIW.
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.194144.1537309242000.276.1571916120899%40Atlassian.JIRA.
[JIRA] (JENKINS-59918) labels and step script content shown inconsistently in blue ocean steps
Title: Message Title Brian J Murrell created an issue Jenkins / JENKINS-59918 labels and step script content shown inconsistently in blue ocean steps Issue Type: Bug Assignee: Unassigned Components: blueocean-plugin Created: 2019-10-24 11:20 Environment: Jenkins ver. 2.190.1 Blue Ocean - BlueOcean Aggregator - 1.19.0 Priority: Major Reporter: Brian J Murrell Somewhat related to JENKINS-53649 and as described there, but this feels like it deserves it's own ticket. The content of a step in the B/O step summary seems inconsistent: Those two steps in the red box are both of the form: sh label: , script: '''...''' The first one is in the steps portion of the stage and looks like: sh label: env.STAGE_NAME, script: '''...''' and the second one is in the post->success portion of the stage and looks like: sh label: "Collect artifacts", script: '''...''' But as you
[JIRA] (JENKINS-53649) Strings from the "echo" step are suppressed in BlueOcean UI if they contain values found in an environment variable
Title: Message Title
Brian J Murrell commented on JENKINS-53649
Re: Strings from the "echo" step are suppressed in BlueOcean UI if they contain values found in an environment variable
Matt C. Wilson Even using {{label:}}s produces inconsistent results: Those two steps in the red box are both of the form:
sh label: ,
script: '''...'''
The first one is in the steps portion of the stage and looks like:
sh label: env.STAGE_NAME,
script: '''...'''
and the second one is in the post->success portion of the stage and looks like:
sh label: "Collect artifacts",
script: '''...'''
But as you can see, they are displayed quite differently.
Add Comment
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
--
You received this message
[JIRA] (JENKINS-53649) Strings from the "echo" step are suppressed in BlueOcean UI if they contain values found in an environment variable
Title: Message Title Brian J Murrell updated an issue Jenkins / JENKINS-53649 Strings from the "echo" step are suppressed in BlueOcean UI if they contain values found in an environment variable Change By: Brian J Murrell Attachment: image-2019-10-24-07-05-23-113.png 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.194144.1537309242000.235.1571915161118%40Atlassian.JIRA.
[JIRA] (JENKINS-49347) BlueOcean unusably slow, maybe related to having a lot of builds stored in history
Title: Message Title Brian J Murrell commented on JENKINS-49347 Re: BlueOcean unusably slow, maybe related to having a lot of builds stored in history We are fully up to date with Jenkins and plugins and Blue Ocean is still terrible to have to sit and wait through all of the stuff it loads. 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.188212.1517587105000.2656.1570465680331%40Atlassian.JIRA.
[JIRA] (JENKINS-56586) Parallel stages or branches cannot be nested ("can only be included in a top-level stage")
Title: Message Title
Brian J Murrell commented on JENKINS-56586
Re: Parallel stages or branches cannot be nested ("can only be included in a top-level stage")
the lack of parallel in parallel is intentional at this time
Indeed. But it's quite limiting, unfortunately. I wouldn't image a scenario of wanting to do multiple tests in parallel across multiple distros, in parallel of course, would be all that uncommon.
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.198201.1552662142000.1277.1570212720425%40Atlassian.JIRA.
[JIRA] (JENKINS-59370) post { unsuccessful {}} doesn't fire without a success {}
Title: Message Title
Brian J Murrell created an issue
Jenkins / JENKINS-59370
post { unsuccessful {}} doesn't fire without a success {}
Issue Type:
Bug
Assignee:
Unassigned
Components:
pipeline
Created:
2019-09-13 18:36
Priority:
Major
Reporter:
Brian J Murrell
If I have a:
post {
unsuccessful {
println("unsuccessful")
}
}
without also having a success block in there, the unsuccessful block fails to run as if it were just not there. Since empty stages are not allowed I had to write a noop() step in a pipeline library that does nothing in order to have a:
success { noop() }
in my post stage so that the unsuccessful stage would run.
[JIRA] (JENKINS-59368) Can upload from non-maven projects or not?
Title: Message Title Brian J Murrell created an issue Jenkins / JENKINS-59368 Can upload from non-maven projects or not? Issue Type: Bug Assignee: Suresh Kumar Components: nexus-artifact-uploader-plugin Created: 2019-09-13 17:28 Priority: Major Reporter: Brian J Murrell Right at the top of the wiki page for the Nexus Artifact Uploader it states: This plugin goal is to upload artifacts generated from non-maven projects to Nexus But a question was asked: How do I set a GroupId for a raw repository? I can not find a Nexus 3 setting to add a GroupId to a raw repository, and this plugin requires a GroupId to be specified. Which was answered with: Plugin supports only Maven type repositories in Nexus. So I am just trying to square that answer with the statement from the top of the wiki: This plugin goal is to upload artifacts generated from non-maven projects to Nexus before I expend time to dive in and try to use it.
[JIRA] (JENKINS-43982) Show stage view for individual jobs
Title: Message Title Brian J Murrell commented on JENKINS-43982 Re: Show stage view for individual jobs Pity that the PR for this is stagnating. 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.181517.1493721583000.3108.1568380920833%40Atlassian.JIRA.
[JIRA] (JENKINS-58604) Full Stage View only showing one
Title: Message Title Brian J Murrell commented on JENKINS-58604 Re: Full Stage View only showing one This really is quite hideous because this is really the only alternative to Blue Ocean[1] to seeing the individual stages in pipeline jobs. Mark Hermon Can you expand a bit on your findings? [1]Blue Ocean is too big, bloated and network heavy with it's constant refreshes to be effectively usable. 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.200764.1563816065000.3104.1568380500141%40Atlassian.JIRA.
[JIRA] (JENKINS-58604) Full Stage View only showing one
Title: Message Title Brian J Murrell assigned an issue to Sam Van Oort Jenkins / JENKINS-58604 Full Stage View only showing one Change By: Brian J Murrell Assignee: Brian J Murrell Sam Van Oort 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.200764.1563816065000.3101.1568380260430%40Atlassian.JIRA.
[JIRA] (JENKINS-58604) Full Stage View only showing one
Title: Message Title Brian J Murrell assigned an issue to Brian J Murrell Jenkins / JENKINS-58604 Full Stage View only showing one Change By: Brian J Murrell Assignee: Sam Van Oort Brian J Murrell 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.200764.1563816065000.3099.1568380260406%40Atlassian.JIRA.
[JIRA] (JENKINS-58618) Only ignores PRs from untrusted sources "once"
Title: Message Title Brian J Murrell commented on JENKINS-58618 Re: Only ignores PRs from untrusted sources "once" Is it really appropriate to downgrade a security-impacting issue like this to Major? Have you tried setting Trusted to "Nobody" as suggested here: That's not the behaviour we are looking for though. We want members of the organisation to be able to push PRs from their own GitHub accounts (i.e. as opposed to using branches within the organisation) and have Jenkins build those. 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.200782.1563892757000.6110.1567547460183%40Atlassian.JIRA.
[JIRA] (JENKINS-58683) Builds from untrusted source on Branch Indexing
Title: Message Title Brian J Murrell commented on JENKINS-58683 Re: Builds from untrusted source on Branch Indexing Is it really appropriate to downgrade a security-impacting issue like this to Major? Have you tried setting Trusted to "Nobody" as suggested here: That's not the behaviour we are looking for though. We want members of the organisation to be able to push PRs from their own GitHub accounts (i.e. as opposed to using branches within the organisation) and have Jenkins build those. 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.200966.1564154958000.6109.1567547460171%40Atlassian.JIRA.
[JIRA] (JENKINS-59171) carry junit results forward on restart
Title: Message Title Brian J Murrell created an issue Jenkins / JENKINS-59171 carry junit results forward on restart Issue Type: Bug Assignee: Unassigned Components: pipeline Created: 2019-09-01 11:52 Priority: Major Reporter: Brian J Murrell When restarting a job from a previously successful stage, if some of the previously run stages produced junit results, those results should be carried forward to the new job the same way that artifacts are. Add Comment This message was sent by Atlassian
[JIRA] (JENKINS-53752) Block PRs from forks from untrusted users
Title: Message Title Brian J Murrell commented on JENKINS-53752 Re: Block PRs from forks from untrusted users Liam Newman Perhaps you are referring to [#188| https://github.com/jenkinsci/github-branch-source-plugin/pull/188]. If so I would direct you to the last comment there about JENKINS-58618 and JENKINS-58683, neither of which have even been triaged. 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.194259.1537809356000.9001.1566612840315%40Atlassian.JIRA.
[JIRA] (JENKINS-53752) Block PRs from forks from untrusted users
Title: Message Title Brian J Murrell commented on JENKINS-53752 Re: Block PRs from forks from untrusted users Liam Newman Could you provide some more details? Which plugin, at least. 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.194259.1537809356000.8993.1566610080275%40Atlassian.JIRA.
[JIRA] (JENKINS-59065) When restarting from a stage, previous run artefacts are copied
Title: Message Title
Brian J Murrell created an issue
Jenkins / JENKINS-59065
When restarting from a stage, previous run artefacts are copied
Issue Type:
Bug
Assignee:
Unassigned
Components:
core
Created:
2019-08-23 15:13
Environment:
Jenkins ver. 2.176.2
Priority:
Major
Reporter:
Brian J Murrell
When I restart a run from a stage, say the test stage, because one of the the previous run's test stages failed, all of the artefacts from the previous run are copied to the new run. I'm not sure this is really the desired behaviour as the new run will be creating it's own new artefacts, duplicating, and in fact obsoleting (logically only since it doesn't overwrite the previous run's artefacts) the previous run('s artefacts). Is this behaviour intentional and if so, is it disable-able. I'm using multi-branch pipelines if that is relevant.
Add Comment
[JIRA] (JENKINS-9016) Git creates usernames based on 'name' not the email.
Title: Message Title Brian J Murrell commented on JENKINS-9016 Re: Git creates usernames based on 'name' not the email. Can't the e-mail address(es) in the commit message be used to find Jenkins security realm users? The e-mail address in my commit messages is the same as the e-mail address associated with my Jenkins account. Why can those not be matched up? 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.139161.1299868575000.4470.1566090300907%40Atlassian.JIRA.
[JIRA] (JENKINS-53752) Block PRs from forks from untrusted users
Title: Message Title Brian J Murrell commented on JENKINS-53752 Re: Block PRs from forks from untrusted users Andrey Babushkin That's not at all how the item description or help text reads. It very specifically says it will only build a change request / pull request ... 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.194259.1537809356000.3600.1565888640492%40Atlassian.JIRA.
[JIRA] (JENKINS-58952) sh labels can't be used in post stages
Title: Message Title Brian J Murrell commented on JENKINS-58952 Re: sh labels can't be used in post stages If I put the label after the script sh script: '''set -ex ...''', label: "Collect artifacts and tear down" it parses fine. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.201299.1565879837000.3495.1565880180053%40Atlassian.JIRA.
[JIRA] (JENKINS-58952) sh labels can't be used in post stages
Title: Message Title
Brian J Murrell created an issue
Jenkins / JENKINS-58952
sh labels can't be used in post stages
Issue Type:
Bug
Assignee:
Unassigned
Components:
pipeline-build-step-plugin
Created:
2019-08-15 14:37
Priority:
Major
Reporter:
Brian J Murrell
When I try to assign a label to an sh step in a post stage I get an error. I.e.:
post {
always {
sh label: "Collect artifacts and tear down",
script '''set -ex
I get the error:
WorkflowScript: 1078: Expected a step @ line 1078, column 29.
sh label: "Collect artifacts and tear down",
^
This works in a build step though:
stage('Build') {
when {
beforeAgent true
_expression_ { return env.QUICKBUILD == '1' }
}
agent {
dockerfile {
filename 'Dockerfile'
dir 'utils/docker'
label 'docker_runner'
additionalBuildArgs '--build-arg
[JIRA] (JENKINS-58604) Full Stage View only showing one
Title: Message Title Brian J Murrell commented on JENKINS-58604 Re: Full Stage View only showing one This only seems to happen while a job is in progress. Once the job completes, the older entries show up in the stage view. 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.200764.1563816065000.5515.1564670640358%40Atlassian.JIRA.
[JIRA] (JENKINS-58604) Full Stage View only showing one
Title: Message Title Brian J Murrell commented on JENKINS-58604 Re: Full Stage View only showing one Perhaps related, because maybe the stage view is actually only even finding the one single build and not all of them, but the Average stage times: are wrong. They are always the same as the only stage being shown. That tells me that this is not a display problem but a data access problem and that the stage view is showing all of the builds that it can find and it's only finding one. But why? 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.200764.1563816065000.4520.1564577460283%40Atlassian.JIRA.
[JIRA] (JENKINS-58683) Builds from untrusted source on Branch Indexing
Title: Message Title Brian J Murrell created an issue Jenkins / JENKINS-58683 Builds from untrusted source on Branch Indexing Issue Type: Bug Assignee: Unassigned Components: basic-branch-build-strategies-plugin Created: 2019-07-26 15:29 Environment: Same as JENKINS-58618 Priority: Critical Reporter: Brian J Murrell Using the same configuration as is detailed in JENKINS-58618, I am also finding that PRs that should not be built because they are from untrusted sources will get built during the Branch Indexing: Checking pull request #814 (not from a trusted source) 'Jenkinsfile' found Met criteria Changes detected: PR-814 (null → [redacted]) Connecting to https://api.github.com to check permissions of obtain list of [redacted] for [redacted]/[redacted] Loading trusted files from base branch master at [redacted] rather than [redacted] Scheduled build for branch: PR-814 You can see that it was determined to be untrusted and reverted to the Jenkinsfile from the origin instead of the PR, but shouldn't the setting in: https://issues.jenkins-ci.org/secure/attachment/48061/image-2019-07-23-10-30-22-210.png mean that it's not even run at all?
[JIRA] (JENKINS-58618) Only ignores PRs from untrusted sources "once"
Title: Message Title Brian J Murrell created an issue Jenkins / JENKINS-58618 Only ignores PRs from untrusted sources "once" Issue Type: Bug Assignee: Unassigned Attachments: image-2019-07-23-10-30-22-210.png Components: basic-branch-build-strategies-plugin Created: 2019-07-23 14:39 Environment: Jenkins ver. 2.176.2 Priority: Critical Reporter: Brian J Murrell Note: setting to Critical as this exposes serious security issues. The Ignore change requests flagged as originating from an untrusted source build strategy: seems to only work on the first commit to a PR from an untrusted source. If a somebody with the appropriate permissions executes a Build Now on that PR, presumably because they have done a code inspection looking for nefarious use of the build and test resources, any subsequent pushes to that PR, even from untrusted sources will get automatically built, without the need for somebody to again go execute a Build Now. This of course means that such a PR could introduce nefarious use, without review, after having it's first commit in the PR approved and built. Every new commit to a PR from an untrusted source needs to be prevented from building until somebody approves it with an explicit Build Now click. Otherwise this whole option becomes much less useful.
[JIRA] (JENKINS-53752) Block PRs from forks from untrusted users
Title: Message Title Brian J Murrell updated an issue Jenkins / JENKINS-53752 Block PRs from forks from untrusted users Change By: Brian J Murrell Attachment: image-2019-07-23-10-28-00-893.png 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.194259.1537809356000.18995.1563892140501%40Atlassian.JIRA.
[JIRA] (JENKINS-53752) Block PRs from forks from untrusted users
Title: Message Title Brian J Murrell commented on JENKINS-53752 Re: Block PRs from forks from untrusted users Isn't this option: supposed to achieve what is being asked for in this ticket? 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.194259.1537809356000.19002.1563892140587%40Atlassian.JIRA.
[JIRA] (JENKINS-58604) Full Stage View only showing one
Title: Message Title Brian J Murrell created an issue Jenkins / JENKINS-58604 Full Stage View only showing one Issue Type: Bug Assignee: Sam Van Oort Attachments: image-2019-07-22-13-20-32-346.png Components: pipeline-stage-view-plugin Created: 2019-07-22 17:21 Environment: Jenkins ver. 2.176.1 Priority: Major Reporter: Brian J Murrell The "Full Stage View" view only seems to ever be showing the currently building job any more: There was a time when I recall seeing lots of previous jobs, but not any more it seems. Add Comment
[JIRA] (JENKINS-56255) occasionally builds the branch for a PR also
Title: Message Title Brian J Murrell commented on JENKINS-56255 Re: occasionally builds the branch for a PR also But having to do branch filtering does not embrace the principle of least surprise. I am sure most people will find it surprising that the branch/PR race design is not more robust and that they have to employ branch filtering to augment it. On the other hand, I think a configuration item, right next to (or below) the selector for whether you want to build branches that are not PRs – for how long to delay a first-time branch build to decide if it's going to become a PR is really straightforward. I think most people would understand that delay is how Jenkins decides if branches are going to become PRs. Not having anything at all leaves people to not even consider the design problem and assuming that Jenkins will then just figure it out. And then it doesn't. 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.197825.1550941413000.14803.1563396720179%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56255) occasionally builds the branch for a PR also
Title: Message Title
Brian J Murrell edited a comment on JENKINS-56255
Re: occasionally builds the branch for a PR also
{quote}What about "Ignore change requests flagged as originating from an untrusted source"? It is in your image above.{quote}-My understanding of that option is that it doesn't actually prevent Jenkins from building from the untrusted source but rather just instructs Jenkins to ignore the {{Jenkinsfile}} such a change-request and use the {{Jenkinsfile}} from the project's master.- This The above was my confusing the new feature you are suggesting using with some previous functionality around PRs from untrusted sources.{quote}I agree, but my point was I think the problem is inherent in the feature. How would you redesign this to make it not flawed? Adding a delay would be mean that all branches wait a certain amount of time before they are built, which is generally not desirable.{quote}How frequent is creating new branches that are not backed by a PR in the real world? Because this delay should only really be required by new branches given that subsequent pushes to the branch already have the PR in place to tell Jenkins not to build the branch. And if it were configurable from 0 to whatever delay a Jenkins admin desires, then it's backward compatible with existing (flawed) behaviour of anyone wants to retain that. But it does allow fixing this behaviour for anyone who desires that.{quote}Let's get those gripers together and discuss how to address the problem. {quote}-The gripers are griping about a completely different issue to this issue so it's really quite orthogonal. They are griping about an issue that occurs when trying to employ your suggested "work-around". And the explanation of why your work-around cannot work in some situations is only use-case why that work-around doesn't work.- It could just plainly be that an organisation doesn't want PRs from forks for other organisational reasons.Ultimately any workarounds are just pussy-footing around the real issue of the branch/PR race that is inherent in any design which doesn't allow for a (configurable if you wish) delay to give the PR time to be submitted. So please, let's not get off into the weeds about why any particular work-around is not suitable and just fix the root issue?
Add Comment
[JIRA] (JENKINS-56255) occasionally builds the branch for a PR also
Title: Message Title
Brian J Murrell edited a comment on JENKINS-56255
Re: occasionally builds the branch for a PR also
{quote} What about "Ignore change requests flagged as originating from an untrusted source"? It is in your image above.{quote} - My understanding of that option is that it doesn't actually prevent Jenkins from building from the untrusted source but rather just instructs Jenkins to ignore the {{Jenkinsfile}} such a change-request and use the {{Jenkinsfile}} from the project's master. -This was confusing the new feature you are suggesting using with some previous functionality around PRs from untrusted sources. {quote} I agree, but my point was I think the problem is inherent in the feature. How would you redesign this to make it not flawed? Adding a delay would be mean that all branches wait a certain amount of time before they are built, which is generally not desirable.{quote} How frequent is creating new branches that are not backed by a PR in the real world? Because this delay should only really be required by new branches given that subsequent pushes to the branch already have the PR in place to tell Jenkins not to build the branch. And if it were configurable from 0 to whatever delay a Jenkins admin desires, then it's backward compatible with existing (flawed) behaviour of anyone wants to retain that. But it does allow fixing this behaviour for anyone who desires that. {quote} Let's get those gripers together and discuss how to address the problem. {quote} - The gripers are griping about a completely different issue to this issue so it's really quite orthogonal. They are griping about an issue that occurs when trying to employ your suggested "work-around". And the explanation of why your work-around cannot work in some situations is only use-case why that work-around doesn't work. - It could just plainly be that an organisation doesn't want PRs from forks for other organisational reasons.Ultimately any workarounds are just pussy-footing around the real issue of the branch/PR race that is inherent in any design which doesn't allow for a (configurable if you wish) delay to give the PR time to be submitted. So please, let's not get off into the weeds about why any particular work-around is not suitable and just fix the root issue?
Add Comment
[JIRA] (JENKINS-56255) occasionally builds the branch for a PR also
Title: Message Title Brian J Murrell commented on JENKINS-56255 Re: occasionally builds the branch for a PR also Liam Newman I tested your work-around, and have verified that the Ignore change requests flagged as originating from an untrusted source option (recently added I think) feature does as it seems and as such could be a valid work-around. But that doesn't make our current workflow any less valid[1] and it might be that I cannot convince all of my users to switch to submitting from forks now that they have gotten used to the branch-in-organisation workflow. [1] One redeeming feature of the workflow of using branches inside the main repo is that everyone can easily be aware of all of all WIP simply by inspecting the branches of repo. 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.197825.1550941413000.14562.1563379740123%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56255) occasionally builds the branch for a PR also
Title: Message Title Brian J Murrell commented on JENKINS-56255 Re: occasionally builds the branch for a PR also What about "Ignore change requests flagged as originating from an untrusted source"? It is in your image above. My understanding of that option is that it doesn't actually prevent Jenkins from building from the untrusted source but rather just instructs Jenkins to ignore the Jenkinsfile such a change-request and use the Jenkinsfile from the project's master. I agree, but my point was I think the problem is inherent in the feature. How would you redesign this to make it not flawed? Adding a delay would be mean that all branches wait a certain amount of time before they are built, which is generally not desirable. How frequent is creating new branches that are not backed by a PR in the real world? Because this delay should only really be required by new branches given that subsequent pushes to the branch already have the PR in place to tell Jenkins not to build the branch. And if it were configurable from 0 to whatever delay a Jenkins admin desires, then it's backward compatible with existing (flawed) behaviour of anyone wants to retain that. But it does allow fixing this behaviour for anyone who desires that. Let's get those gripers together and discuss how to address the problem.  The gripers are griping about a completely different issue to this issue so it's really quite orthogonal. They are griping about an issue that occurs when trying to employ your suggested "work-around". And the explanation of why your work-around cannot work in some situations is only use-case why that work-around doesn't work. It could just plainly be that an organisation doesn't want PRs from forks for other organisational reasons. Ultimately any workarounds are just pussy-footing around the real issue of the branch/PR race that is inherent in any design which doesn't allow for a (configurable if you wish) delay to give the PR time to be submitted. So please, let's not get off into the weeds about why any particular work-around is not suitable and just fix the root issue? Add Comment
[JIRA] (JENKINS-56255) occasionally builds the branch for a PR also
Title: Message Title Brian J Murrell commented on JENKINS-56255 Re: occasionally builds the branch for a PR also you're developer are pushing branches to the main repo and not to their own fork. That's correct. They are all organisation members so philosophically, the main repo is really their (shared) repo. But pragmatically (and primarily), it is done this way due to the inability to prevent Jenkins from processing PRs from untrusted sources. Jenkins can be told to refuse to process the Jenkinsfile from an untrusted source, but cannot be told to completely ignore PRs from untrusted source. But Jenkins can be told to ignore PRs from forks. So the proxy for "untrusted source" is any fork. having a delay of some sort would be useful So you are suggesting that there is in fact no delay? At all? I cannot see how that is ever going to work. The branch will always show up before the PR no matter how quickly the developer can get to turning a branch into a PR. I guess this is trying to rely on Jenkins being slower to notice the new branch than noticing the PR? Surely you can see how this is fatally flawed. how long should that delay be? Yes, this is a good question. Probably begs to be configurable. But even if not, some number of minutes seems reasonable. At least that way I can say to my users "you need to make sure you create your PR within ... of pushing your branch or you will get this ugly behaviour". Right now I cannot tell them anything other than that this is a nasty Jenkins bug and they have to just live with it. I'm think this issue should be closed as "By Design". Or left open as "Needs redesign"? Use forks and discover PRs from forks This simply cannot be done. There are a lot of people that agree with me on this. We are simply not allowed to just let any random stranger run whatever (perhaps nefarious) code they can push to a PR for to run on our Jenkins. The lack of this ability is griped about quite frequently. use "Filter by name (with wildcards)" or "Filter by name (with regex)" discovery strategies That might be workable. Funny enough, it's more or less the same solution as I coded up earlier this morning when I commented on this issue earlier.
[JIRA] (JENKINS-58442) Skip initial build on first branch indexing not working
Title: Message Title Brian J Murrell created an issue Jenkins / JENKINS-58442 Skip initial build on first branch indexing not working Issue Type: Bug Assignee: Unassigned Attachments: image-2019-07-11-09-50-46-349.png Components: basic-branch-build-strategies-plugin Created: 2019-07-11 13:52 Environment: Jenkins ver. 2.176.1 Basic Branch Build Strategies Plugin 1.3.2 Priority: Critical Reporter: Brian J Murrell We have enabled the Skip initial build on first branch indexing build strategy: as a workaround to JENKINS-56255 but it seems to also be not working. We are still getting the branch build from GitHub PRs happening when a new PR is pushed. Am I misunderstanding what this build strategy does? It did seem to work for a while, but maybe that was just the intermittent-ness of JENKINS-56255 on our side for a while.
[JIRA] (JENKINS-56255) occasionally builds the branch for a PR also
Title: Message Title Brian J Murrell commented on JENKINS-56255 Re: occasionally builds the branch for a PR also Was my previous comment what you were looking for? We are seeing this increasingly frequently and it's getting very confusing for our developers. 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.197825.1550941413000.7929.1562850840153%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-58359) Blue Ocean visualisation inaccurate while building
Title: Message Title Brian J Murrell created an issue Jenkins / JENKINS-58359 Blue Ocean visualisation inaccurate while building Issue Type: Bug Assignee: Unassigned Attachments: image-2019-07-05-07-36-26-336.png, image-2019-07-05-07-41-35-587.png Components: blueocean-plugin Created: 2019-07-05 11:42 Priority: Major Reporter: Brian J Murrell While running a pipeline, the Blue Ocean visualisation can be inaccurate. For example, at one point my pipeline looks like this: However, as you can see, when it has completed that stage that was running (Unit Test) and moves on to the next stage it looks like this: So why weren't the parallel Build stage steps showing in the first image above. They were most certainly complete at that point. Add Comment
[JIRA] (JENKINS-56255) occasionally builds the branch for a PR also
Title: Message Title Brian J Murrell commented on JENKINS-56255 Re: occasionally builds the branch for a PR also Hopefully this is what you are looking for: 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.197825.1550941413000.11635.1561722660129%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56255) occasionally builds the branch for a PR also
Title: Message Title Brian J Murrell updated an issue Jenkins / JENKINS-56255 occasionally builds the branch for a PR also Change By: Brian J Murrell Attachment: image-2019-06-28-07-49-51-334.png 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.197825.1550941413000.11633.1561722600143%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-57826) catchError(buildResult: hudson.model.Result.SUCCESS, stageResult: hudson.model.Result.FAILURE) doesn't set stage to FAILURE
Title: Message Title Brian J Murrell commented on JENKINS-57826 Re: catchError(buildResult: hudson.model.Result.SUCCESS, stageResult: hudson.model.Result.FAILURE) doesn't set stage to FAILURE (At the risk of preaching to the choir, but also not wanting to leave it unsaid) regardless of how it's achieved, having the post stages react and act according to the stage status set by catchError (and friends) is paramount because (again, to be obvious, but explicit,) having the post stages not act according to status of the stage I think is just going to add even more confusion to this already confusing big can of worms. Any estimate on the size/effort of fixing the post processing, since I think for many cases, the (excellent!, BTW) advancements made in the Pipeline Basic Steps plugin really get nullified by not being able to post based on the stage status that can now be set. I wouldn't imagine there are very many pipelines that don't do at least a minimal amount of post based on the result of the stage. But maybe I am wrong about that guesstimate. 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.199781.1559585434000.20682.1559652120135%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-57826) catchError(buildResult: hudson.model.Result.SUCCESS, stageResult: hudson.model.Result.FAILURE) doesn't set stage to FAILURE
Title: Message Title Brian J Murrell commented on JENKINS-57826 Re: catchError(buildResult: hudson.model.Result.SUCCESS, stageResult: hudson.model.Result.FAILURE) doesn't set stage to FAILURE Isn't the post for a stage supposed to be acting on the result of that stage? I'm wondering how/why any kind of combined result or overall job result is even a factor in assessing which post blocks to run for the stage when catchError is successfully setting the result for that stage. as a temporary workaround, if you are ok with marking the build and stage result as unstable That won't work unfortunately. UNSTABLE in our workflow specifically prevents landing since it's the result of having failed junit test results. So we can't live with marking the overall build result as UNSTABLE when only stages that are not supposed to block landing fail. break the way you are using buildResult: hudson.model.Result.SUCCESS That's fine. I am using it completely understanding that it's only temporary while I wait for JENKINS-57537 to be available. 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.199781.1559585434000.19948.1559587080102%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-45579) Step to set stage or parallel status
Title: Message Title Brian J Murrell commented on JENKINS-45579 Re: Step to set stage or parallel status Devin Nusbaum New issue filed about catchError(), and the post processing block, FWIW. 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.183763.1500306894000.19749.1559585583164%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-57826) catchError(buildResult: hudson.model.Result.SUCCESS, stageResult: hudson.model.Result.FAILURE) doesn't set stage to FAILURE
Title: Message Title
Brian J Murrell created an issue
Jenkins / JENKINS-57826
catchError(buildResult: hudson.model.Result.SUCCESS, stageResult: hudson.model.Result.FAILURE) doesn't set stage to FAILURE
Issue Type:
Bug
Assignee:
Unassigned
Components:
pipeline
Created:
2019-06-03 18:10
Environment:
Jenkins: 2.164.3 Pipeline: Basic Steps: 2.16
Priority:
Critical
Reporter:
Brian J Murrell
If I have a stage with a step in it:
...
catchError(buildResult: hudson.model.Result.SUCCESS,
message: 'RPM build failed, but allowing job to continue',
stageResult: hudson.model.Result.FAILURE) {
sh label: env.STAGE_NAME,
script: 'exit 2'
}
With a post block for the stage:
post {
always {
archiveArtifacts artifacts: 'artifacts/**'
}
success {
println "${env.STAGE_NAME}: SUCCESS"
}
unstable {
println "${env.STAGE_NAME}: UNSTABLE"
}
failure
[JIRA] (JENKINS-45579) Step to set stage or parallel status
Title: Message Title Brian J Murrell commented on JENKINS-45579 Re: Step to set stage or parallel status Devin Nusbaum Oh, this is a pity. catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') was going to solve exactly the problem I newly have on hand today, which is how to let a step fail, mark it's stage as failed but not fail the overall job. I'm really loathed to make the step and stage look like it succeeded (because it will mask failures that need investigating) just so that the rest of the stages get run and overall job passes. 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.183763.1500306894000.19376.1559573163199%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-45579) Step to set stage or parallel status
Title: Message Title
Brian J Murrell edited a comment on JENKINS-45579
Re: Step to set stage or parallel status
I used the Pipeline Syntax snippet generator to generate me a {{catchError}} step and it produced:{noformat}catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') { // some block}{noformat}which then chokes Jenkins with:{noformat}WorkflowScript: 147: Expecting "class hudson.model.Result" for parameter "buildResult" but got "SUCCESS" of type class java.lang.String instead @ line 147, column 49. catchError(buildResult: 'SUCCESS', ^{noformat} Removing the single quotes surrounding the {{SUCCESS}} and {{FAILURE}} values seems to at least keep the linter happy and the pipeline at least runs. Still waiting to see if these new values have the desired effect though. :-)
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.183763.1500306894000.19180.1559571784312%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-45579) Step to set stage or parallel status
Title: Message Title
Brian J Murrell commented on JENKINS-45579
Re: Step to set stage or parallel status
I used the Pipeline Syntax snippet generator to generate me a catchError step and it produced:
catchError(buildResult: 'SUCCESS', stageResult: 'FAILURE') {
// some block
}
which then chokes Jenkins with:
WorkflowScript: 147: Expecting "class hudson.model.Result" for parameter "buildResult" but got "SUCCESS" of type class java.lang.String instead @ line 147, column 49.
catchError(buildResult: 'SUCCESS',
^
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.183763.1500306894000.18999.1559571612693%40Atlassian.JIRA.
For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56255) occasionally builds the branch for a PR also
Title: Message Title Brian J Murrell commented on JENKINS-56255 Re: occasionally builds the branch for a PR also Liam Newman Is there any pattern to when this happens? I have not been able to determine any pattern, no. My guess is this is a race condition related to scanning, but we'll see. Indeed, that is my guess also. Can you describe the algorithm that the plugin is using to decide when a branch is not a branch but is a PR? What is the config for your multibranch pipeline? What is the best way to convey that to you? 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.197825.1550941413000.17397.1559304121405%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56973) access builds by displayname
Title: Message Title Brian J Murrell created an issue Jenkins / JENKINS-56973 access builds by displayname Issue Type: Improvement Assignee: Unassigned Components: core Created: 2019-04-11 13:07 Priority: Major Reporter: Brian J Murrell The ability to change the display name for a build of a job from it's number to an arbitrary string is nice. But what would complement that nicely would be being able to use that display name as a substitute for the build number in URLs for the job similar to the way lastSuccessfulBuild works. This could even be implemented as simply as lastSuccessfulBuild is with a symlink in the filesystem from the displayname to the build number. Add Comment
[JIRA] (JENKINS-39203) All stages show up as UNSTABLE when only one stage should
Title: Message Title Brian J Murrell edited a comment on JENKINS-39203 Re: All stages show up as UNSTABLE when only one stage should Completely agree with [~borisivan]. To the extent even that I have written Blue Ocean off. It causes more questions and confusion that it adds value.Instead, I tell my users that GitHub's commit statuses are the point of truth and to that end provide a status for every pipeline stage complete with a URL to (non-Blue Ocean) stage results in the Details link of each GitHub status posted. That this issue has gone on as long as it has with no explanation or status updates on this ticket lately actually makes me wonder what the commitment to Blue Ocean, Pipeline and Jenkins in general is for the future.I see news stories about Jenkins "[reinventing itself|https://www.infoworld.com/article/3366428/jenkins-tries-to-reinvent-itself-as-cloud-native-for-kubernetes.html] and wonder what impact that has on or means for issues like this and others I have opened or commented on with no comments or even a triage in the case of new tickets from any Jenkins developers. 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-39203) All stages show up as UNSTABLE when only one stage should
Title: Message Title Brian J Murrell commented on JENKINS-39203 Re: All stages show up as UNSTABLE when only one stage should Completely agree with boris ivan. To the extent even that I have written Blue Ocean off. It causes more questions and confusion that it adds value. Instead, I tell my users that GitHub's commit statuses are the point of truth and to that end provide a status for every pipeline stage complete with a URL to (non-Blue Ocean) stage results in the Details link of each GitHub status posted. That this issue has gone on as long as it has with no explanation or status updates on this ticket lately actually makes me wonder what the commitment to Blue Ocean, Pipeline and Jenkins in general is for the future. I see news stories about Jenkins "reinventing itself and wonder what impact that has on or means for issues like this and others I have opened or commented on with no comments or even a triage in the case of new tickets from any Jenkins developers. 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-56586) Parallel stages or branches can only be included in a top-level stage
Title: Message Title
Brian J Murrell created an issue
Jenkins / JENKINS-56586
Parallel stages or branches can only be included in a top-level stage
Issue Type:
Improvement
Assignee:
Unassigned
Components:
pipeline, workflow-basic-steps-plugin
Created:
2019-03-15 15:02
Priority:
Critical
Reporter:
Brian J Murrell
When I try to use nested parallel statements in a declarative pipeline as such:
pipeline {
agent none
stages {
stage('Cancel Previous Builds') { steps { echo "Cancel Previous Builds" } }
stage('Pre-build') { steps { echo "Pre-build" } }
stage("Build and Test") {
parallel {
stage('Build and Test') {
stages {
stage('Build Platform 1') { steps { echo "Build Platform 1" } }
stage('Test Platform 1') {
parallel {
stage('Test 1') { steps { echo "Test 1" } }
stage('Test 2') { steps { echo "Test 2" } }
stage('Test 3') { steps { echo "Test 3" } }
}
}
}
}
stage('Build Platform 2') { steps { echo "Build Platform 2" } }
stage('Build Platform 3') { steps { echo "Build Platform 3" } }
}
}
}
}
I get an error:
WorkflowScript: 25: Parallel stages or branches can only be included in a top-level stage. @ line 25,
[JIRA] (JENKINS-56255) occasionally builds the branch for a PR also
Title: Message Title Brian J Murrell commented on JENKINS-56255 Re: occasionally builds the branch for a PR also This is starting to happen more frequently and is wreaking havoc in our CI system. Users are constantly confused about failed continuous-integration/jenkins/branch commit statuses in their GitHub PRs and some of these branch builds are overwriting statuses of the PR build. I wonder why there hasn't been any response to my queries about this bug. Have I done something wrong in the way I filed this issue in so much as it's being ignored? 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-56255) occasionally builds the branch for a PR also
Title: Message Title Brian J Murrell updated an issue Jenkins / JENKINS-56255 occasionally builds the branch for a PR also Change By: Brian J Murrell Priority: Major Critical 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-55420) local variables in shared-library global vars being treated globally
Title: Message Title Brian J Murrell resolved as Not A Defect Jenkins / JENKINS-55420 local variables in shared-library global vars being treated globally Change By: Brian J Murrell Status: Open Resolved Resolution: Not A Defect 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-55420) local variables in shared-library global vars being treated globally
Title: Message Title Brian J Murrell commented on JENKINS-55420 Re: local variables in shared-library global vars being treated globally Stefan Maurer I'm not sure that code snippets is needed. The solution is to quite simply add def in front of your variables to make them local. 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-55420) local variables in shared-library global vars being treated globally
Title: Message Title
Brian J Murrell edited a comment on JENKINS-55420
Re: local variables in shared-library global vars being treated globally
Not sure if what is described in the description of this ticket is the expected behaviour and if my solution is the expected solution, so I will leave this open for somebody else to decide and resolve if so.What resolved this for me was to {{def}}ine my variables in my {{provisionNodes}} "global variable" (i.e. {{vars/provisionNodes}}). That made them act local to {{provisionNodes}}.
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-52158) Conditional parallel failfast
Title: Message Title Brian J Murrell commented on JENKINS-52158 Re: Conditional parallel failfast Did anything come of this idea? It's something we'd like to see also. 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-56395) Expose "trusted" attribute of a PR to the Pipeline
Title: Message Title Brian J Murrell created an issue Jenkins / JENKINS-56395 Expose "trusted" attribute of a PR to the Pipeline Issue Type: Improvement Assignee: Unassigned Components: github-branch-source-plugin Created: 2019-03-04 19:44 Priority: Major Reporter: Brian J Murrell It would be very useful in a Pipeline job to be able to know the value of the Trusted attribute for a PR so that the Pipeline could handle it differently based on whether it came from a trusted source or not. Add Comment
[JIRA] (JENKINS-56255) occasionally builds the branch for a PR also
Title: Message Title Brian J Murrell commented on JENKINS-56255 Re: occasionally builds the branch for a PR also Any response here? Having the branch build for PRs that are opened within a very small number of seconds of pushing the branch is quite annoying at best and frequently confusing for users who don't understand the workings of the github-branch-source-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. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56385) allow setting of env. variables or parameters in triggered runs
Title: Message Title Brian J Murrell created an issue Jenkins / JENKINS-56385 allow setting of env. variables or parameters in triggered runs Issue Type: Bug Assignee: Unassigned Components: pipeline Created: 2019-03-04 13:52 Priority: Major Reporter: Brian J Murrell While it's useful to be able to trigger a pipeline run based on a cron schedule, it would be even more useful, if along with the cron schedule, parameters or environment variables could be defined so that one could define different run models with the triggers. Probably a common example of this would be to run different sets of testing at pre-defined times, such as running more comprehensive (and resource intensive) testing on weekends when resource contention is low. Add Comment
[JIRA] (JENKINS-56255) occasionally builds the branch for a PR also
Title: Message Title Brian J Murrell commented on JENKINS-56255 Re: occasionally builds the branch for a PR also The other possibility for this issue is to have a whiltelist filter of branches to build and ignore the rest assuming they will eventually become a PR. 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-56255) occasionally builds the branch for a PR also
Title: Message Title Brian J Murrell created an issue Jenkins / JENKINS-56255 occasionally builds the branch for a PR also Issue Type: Bug Assignee: Unassigned Components: github-branch-source-plugin Created: 2019-02-23 17:03 Environment: Jenkins ver. 2.150.3 GitHub Branch Source Plugin 2.4.2 Priority: Major Reporter: Brian J Murrell I have a GitHub Organisation configured and it is operating fairly satisfactorily. It finds PRs when they are opened and builds them, and so on, quite successfully. But every now and then it will build not only the PR but also the branch that the PR is on, adding a continuous-integration/jenkins/branch commit status to the PR. This is wasteful in the least a can be confusing to the PR submitters about why they have this strange new commit status occasionally. I suppose this could happen legitimately if there is latency between pushing to a new branch on GitHub and opening the PR for it. Is there any delay on building new branches to account for this sort of behaviour? If not, perhaps there should be?
[JIRA] (JENKINS-44611) Any way to restrict build for non-whitelisted users?
Title: Message Title Brian J Murrell commented on JENKINS-44611 Re: Any way to restrict build for non-whitelisted users? Stephen Connolly Your workaround suggestion in the first comment along with Jenkinsfile's input step could lead to a more useful workaround. The only thing that is missing is the ability for a Jenkinsfile to determine the "trust"ability of the PR. Is that at all possible? 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-49045) Support a trusted list of fork authors in GitHub Branch Source Plugin
Title: Message Title Brian J Murrell commented on JENKINS-49045 Re: Support a trusted list of fork authors in GitHub Branch Source Plugin Should this be closed/resolved given the comments on the PR? 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-39203) All stages show up as UNSTABLE when only one stage should
Title: Message Title
Brian J Murrell edited a comment on JENKINS-39203
Re: All stages show up as UNSTABLE when only one stage should
This ticket has added 26 more votes and 20 more watchers in just a hair over a month for a total of 175 and 189, respectively.Could somebody please provide an update on the status of this issue to those 189 watchers please? Is this *+really+* (after all of this time and attention) still just in the {color:#4c9aff}Planned{color} state that the [Blue Ocean Roadmap|https://jenkins.io/projects/blueocean/roadmap/] indicates?
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-39203) All stages show up as UNSTABLE when only one stage should
Title: Message Title Brian J Murrell commented on JENKINS-39203 Re: All stages show up as UNSTABLE when only one stage should This ticket has added 26 more votes and 20 more watchers in just a hair over a month for a total of 175 and 189, respectively. Could somebody please provide an update on the status of this issue to those 189 watchers please? 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.
