[JIRA] (JENKINS-51225) Support for GitHub Checks API
Title: Message Title
Jon-Paul Sullivan commented on JENKINS-51225
Re: Support for GitHub Checks API
For interacting with the GitHub API, there are a number of libraries to help with this in a number of languages: https://developer.github.com/v3/libraries/ Typically if credentials are supplied by a credentials binding, they would be available in the environment. You might find that the libraries expect particular environment variables (similar to how AWS' boto3 library can work), and as such you might just need a withCredentials() {} wrapper around the build step with the correct definitions. It really feels like this needs to be an update tot he actual GitHub status notification plugin though, or a new plugin that can be used as an alternative, as great as a build step would be, it would become incumbent on folks to use it correctly in both happy-path and failure-paths of their Jenkinsfiles.
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.190545.1525878773000.9021.1576518181096%40Atlassian.JIRA.
[JIRA] (JENKINS-43749) Support multiple Jenkinsfiles from the same repository
Title: Message Title Jon-Paul Sullivan commented on JENKINS-43749 Re: Support multiple Jenkinsfiles from the same repository When creating multiple jobs off the same GitHub repository, I found we required this plugin to get sane PR checking: https://plugins.jenkins.io/github-scm-trait-notification-context Default behaviour can play havoc with CI pipelines. 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.181165.1492753177000.12924.1561980962001%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-55726) GitHub commit status context not unique enough or configurable - jobs always overwrite each other
Title: Message Title Jon-Paul Sullivan commented on JENKINS-55726 Re: GitHub commit status context not unique enough or configurable - jobs always overwrite each other Nozomu Honda - as you changed the status to in progress, could you answer Liam Newman’s question 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. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-issues/JIRA.196920.154815684.19571.1559574841553%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-55726) GitHub commit status context not unique enough or configurable - jobs always overwrite each other
Title: Message Title Jon-Paul Sullivan commented on JENKINS-55726 Re: GitHub commit status context not unique enough or configurable - jobs always overwrite each other Liam Newman, I did not change it, but I do think that the default behaviour of the plugin should not be one that allows information loss. 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.196920.154815684.16792.1559236560266%40Atlassian.JIRA. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-55726) GitHub can incorrectly flag PRs as passing checks if multiple jobs run against the same repository
Title: Message Title Jon-Paul Sullivan commented on JENKINS-55726 Re: GitHub can incorrectly flag PRs as passing checks if multiple jobs run against the same repository My reading was that the changing name returned from a PR branch build broke things because you need a fixed string for a single job. I didn't read that as requiring a fixed string for every status reported by Jenkins ever. So ci/jenkins/repo/PR-1, ci/jenkins/repo/PR-2 == broken status reporting, but ci/jenkins/repo would not change between Pull Requests and therefore satisfies the requirements of the previous bug report, as I read it. If there is no desire to change the current default behaviour, I would still like a convenient way to change that default behaviour to something more useful to my use case, where multiple jobs need to accurately report status to GitHub without overwriting the reported status of a different job, which I think is a bug, even if the code is working as designed. I think this is a bug because it allows for incorrect changing of data in GitHub - different jobs reporting to the same context looks to me like avoiding the whole point of the context string in the first place. So I would interpret the Jenkins intention is to have 1 job per commit, but that is not a model enforced by a number of other Jenkins<->SCM reporting tools, for example Gerrit and Jenkins allows for multiple jobs reporting status and correctly gates across multiple jobs. Requiring me to remember to change the context every time I create a uniquely named job seems like at best a poor user experience, and similarly requiring code in every Jenkinsfiles I write to correctly report back is again poor user experience. The additions need every time a job is created becomes tribal knowledge that needs to be remembered, and is going to be a source of bug in pipelines for our software delivery. Can I get pointers to the existing elements you mention though please? They may show a template for creating a plugin that modifies the default behaviour? Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)
[JIRA] (JENKINS-55726) GitHub can incorrectly flag PRs as passing checks if multiple jobs run against the same repository
Title: Message Title
Jon-Paul Sullivan commented on JENKINS-55726
Re: GitHub can incorrectly flag PRs as passing checks if multiple jobs run against the same repository
Related to JENKINS-37100 and JENKINS-36574 - I think the latter may be the genesis for the current situation, which may have been a fix by Jesse Glick? I read through those bugs and can definitely see why the code is as it currently is, but I think an improvement can be made to satisfy both the current use case and also improve the situation where multiple Jenkins jobs are reporting to the single repository. I saw this mentioned but no discussion as to why it was ultimately not followed, so if there are issues then please do explain. The prime requirements for blocking merges is that there is a single string that any PR presents to GitHub so the repository settings can indicate the status of that context must be success prior to merge. This is currently set to "continuous-integration/jenkins/pr-merge".
public String getDefaultContext(TaskListener listener) {
if (head instanceof PullRequestSCMHead) {
if (((PullRequestSCMHead) head).isMerge()) {
return "continuous-integration/jenkins/pr-merge";
} else {
return "continuous-integration/jenkins/pr-head";
}
} else {
return "continuous-integration/jenkins/branch";
}
}
The issue is that every Jenkins job returns that same context. In the case of a Multibranch configuration using GitHub, we will have a job whose name is [/]*/ where is either a branch or a special branch representing a Pull Request. The branch string changes each time a new branch or pull request is created, and this makes it unsuitable to be used as a merge gate for GitHub. I would state that the enclosing job name is perfectly viable to use as a status context though, as that is unchanging across multiple Pull Requests. So the above code would become something like:
public String getDefaultContext(TaskListener listener) {
if (head instanceof PullRequestSCMHead) {
if (((PullRequestSCMHead) head).isMerge()) {
return "continuous-integration/jenkins/" + job.getParent() + "/pr-merge";
} else {
return "continuous-integration/jenkins/" + job.getParent() + "/pr-head";
}
} else {
return "continuous-integration/jenkins/" + job.getParent() + "/branch";
}
}
[JIRA] (JENKINS-56901) Run parameter requires existing job or will throw a null pointer exception
Title: Message Title Jon-Paul Sullivan created an issue Jenkins / JENKINS-56901 Run parameter requires existing job or will throw a null pointer exception Issue Type: Bug Assignee: Unassigned Components: core Created: 2019-04-05 09:05 Priority: Minor Reporter: Jon-Paul Sullivan Writing a Jenkinsfile job that is to be called as a downstream from many different jobs. As such, the hard-coded projectName for the run parameter doesn't make sense. Attempts to leave it blank or populate it with a fake string result in the null pointer exception. java.lang.NullPointerException at hudson.model.RunParameterDefinition.getDefaultParameterValue(RunParameterDefinition.java:180) at org.jenkinsci.plugins.workflow.cps.ParamsVariable.getValue(ParamsVariable.java:73) at org.jenkinsci.plugins.workflow.cps.CpsScript.getProperty(CpsScript.java:121) at org.codehaus.groovy.runtime.InvokerHelper.getProperty(InvokerHelper.java:174) at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.getProperty(ScriptBytecodeAdapter.java:456) at org.kohsuke.groovy.sandbox.impl.Checker$6.call(Checker.java:290) at org.kohsuke.groovy.sandbox.GroovyInterceptor.onGetProperty(GroovyInterceptor.java:68) at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onGetProperty(SandboxInterceptor.java:326) at org.kohsuke.groovy.sandbox.impl.Checker$6.call(Checker.java:288) at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:292) at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:268) at org.kohsuke.groovy.sandbox.impl.Checker.checkedGetProperty(Checker.java:268) at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.getProperty(SandboxInvoker.java:29) at com.cloudbees.groovy.cps.impl.PropertyAccessBlock.rawGet(PropertyAccessBlock.java:20) at WorkflowScript.run(WorkflowScript:38)
[JIRA] (JENKINS-55726) GitHub can incorrectly flag PRs as passing checks if multiple jobs run against the same repository
Title: Message Title Jon-Paul Sullivan created an issue Jenkins / JENKINS-55726 GitHub can incorrectly flag PRs as passing checks if multiple jobs run against the same repository Issue Type: Bug Assignee: Unassigned Components: github-api-plugin, github-branch-source-plugin Created: 2019-01-22 11:34 Environment: CloudBees Jenkins Enterprise 2.107.34.0.1-fixed GitHub API Plugin 1.90 GitHub Branch Source Plugin 2.3.5 Priority: Critical Reporter: Jon-Paul Sullivan Multiple jobs configured against the same source repo will incorrectly set all checks successful if the last completed check is successful. In my opinion, if there is no mechanism to define mandatory and optional checks, then the worst status check should provide the overall result. This could be a check prior to submitting status that validates the prior status is not unsuccessful, and it is the same git sha1, and it is a different job name. The secondary issue here is that only a single link is added to the PR, and so there is no indication on the GitHub PR how many jobs ran.
[JIRA] (JENKINS-45260) NPE: configuring shared library validateVersion(SCMSourceRetriever.java:124)
Title: Message Title Jon-Paul Sullivan commented on JENKINS-45260 Re: NPE: configuring shared library validateVersion(SCMSourceRetriever.java:124) I see something similar to this. A Jenkins server has a global shared library at the system level. I try to configure a shared library at the folder level, and if I need to specify any authentication credentials it will fail. The same config with a publicly available repository succeeds. Add Comment This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [build-pipeline] (JENKINS-16748) Build Pipeline Plugin views are not filtered
Jon-Paul Sullivan
commented on JENKINS-16748
Build Pipeline Plugin views are not filtered
From my reading of this: https://github.com/jenkinsci/jenkins/commit/85e13303f8cfbebeb7dab347fda8ccf4069070b6 (from https://issues.jenkins-ci.org/browse/JENKINS-3681)
The getItems() call must not be returning an empty collection for a user that does not have permissions on the jobs used in the pipeline, and the getItems() call for a build pipeline view is (https://github.com/jenkinsci/build-pipeline-plugin/blob/master/src/main/java/au/com/centrumsystems/hudson/plugin/buildpipeline/BuildPipelineView.java)
@Override
public CollectionTopLevelItem getItems() {
return Hudson.getInstance().getItems();
}
Jenkins internals aren't my strongest skills, but I wonder would the following change help with this?
Change BuildPipelineView.getItems() to:
@Override
public CollectionTopLevelItem getItems() {
return this.gridBuilder.getFirstJob(this).getItems();
}
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
