We use several multibranch jobs for one repository. And the statuses of PR in github from different jobs are mixed. The context for github status hardcoded and can't be changed. It would be very convinient keep job name in context string.

          [JENKINS-46119] Use the job name in context string

          Jesse Glick added a comment -

          A naïve fix will regress JENKINS-36574.

          Jesse Glick added a comment - A naïve fix will regress  JENKINS-36574 .

          Then maybe it makes sense to add the ability to configure the context from the pipeline?

          Viacheslav Dubrovskyi added a comment - Then maybe it makes sense to add the ability to configure the context from the pipeline?

          Jesse Glick added a comment -

          More likely from the multibranch / organization folder. Fine so long as the default remains a fixed string (per job type, at any rate), and the inline help clearly explains why you might run into trouble customizing that.

          Jesse Glick added a comment - More likely from the multibranch / organization folder. Fine so long as the default remains a fixed string (per job type, at any rate), and the inline help clearly explains why you might run into trouble customizing that.

          Fabian Holler added a comment -

          When you run multiple Jenkins job per Github PR you currently end up with having several "continuous-integration/jenkins/" status messages.
          It's unclear which status refers to which CI job (build, test, etc).

          Alternatively being able to disable posting the status to github from the plugin at all would help.
          Then I could post the status myself with a script with the information I want.
          When I currently do this, I end up with multiple status messages for the same job run in github.

          Fabian Holler added a comment - When you run multiple Jenkins job per Github PR you currently end up with having several "continuous-integration/jenkins/" status messages. It's unclear which status refers to which CI job (build, test, etc). Alternatively being able to disable posting the status to github from the plugin at all would help. Then I could post the status myself with a script with the information I want. When I currently do this, I end up with multiple status messages for the same job run in github.

          Yo-An Lin added a comment -

          This is really annoying. the build commit status will be overwritten if you have more than 1 jobs triggered by a single commit because they are using the same context label. job name should be used for the context.

          Yo-An Lin added a comment - This is really annoying. the build commit status will be overwritten if you have more than 1 jobs triggered by a single commit because they are using the same context label. job name should be used for the context.

          Yo-An Lin added a comment -

          Is there a way to customize the context name via the pipeline api or jenkins api ?

          Yo-An Lin added a comment - Is there a way to customize the context name via the pipeline api or jenkins api ?

          Yo-An Lin added a comment -

          Do not do this. There was an issue specifically requesting that the context string not include details like a job name, and that was fixed. The reason is that GitHub has features whereby you can control various workflows by specifying approved status context strings, and they need to be an exact match.

          quote from a comment of the closed PR.

          Yo-An Lin added a comment - Do not do this. There was an issue specifically requesting that the context string not include details like a job name, and that was fixed. The reason is that GitHub has features whereby you can control various workflows by specifying approved status context strings, and they need to be an exact match. quote from a comment of the closed PR.

          Yo-An Lin added a comment -

          jglick how about using pipeline property to define the context ? so that users can customize the context from their own pipeline script

          Yo-An Lin added a comment - jglick how about using pipeline property to define the context ? so that users can customize the context from their own pipeline script

          Viacheslav Dubrovskyi added a comment - IMHO the issue can be closed, because it's possible to set context with https://github.com/steven-foster/github-scm-trait-notification-context How to use it look to  https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/jenkinsci-users/uS8qhyDLDWs/5KKSN1uTBwAJ

          And where will this be documented? Why is the resolution not to roll this override functionality into the plugin? Do we expect that people who run afoul of this will locate this bug, and hopefully that repo and google group will be accessible to them?

          Robert Rodrigues added a comment - And where will this be documented? Why is the resolution not to roll this override functionality into the plugin? Do we expect that people who run afoul of this will locate this bug, and hopefully that repo and google group will be accessible to them?

          Note that the url in the pom.xml does not resolve.
          https://wiki.jenkins-ci.org/display/JENKINS/Github+Custom+Notification+Context+SCM+Behaviour

          However, further searching found this: https://plugins.jenkins.io/github-scm-trait-notification-context

          So, is installing that plugin the correct way to resolve this?

          Robert Rodrigues added a comment - Note that the url in the pom.xml does not resolve. https://wiki.jenkins-ci.org/display/JENKINS/Github+Custom+Notification+Context+SCM+Behaviour However, further searching found this: https://plugins.jenkins.io/github-scm-trait-notification-context So, is installing that plugin the correct way to resolve this?

          Yo-An Lin added a comment -

          dubrsl why is this closed? I don't think this issue should be resolved by installing a plugin. the context customization feature should be self-contained since IT IS THE GitHub Source Plugin.

          Yo-An Lin added a comment - dubrsl why is this closed? I don't think this issue should be resolved by installing a plugin. the context customization feature should be self-contained since IT IS THE GitHub Source Plugin.

          c9s I made this issue because there was no solution. Now solution exist. So I decided to close it. Feel free to reopen it.

          Viacheslav Dubrovskyi added a comment - c9s  I made this issue because there was no solution. Now solution exist. So I decided to close it. Feel free to reopen it.

          Fabian Holler added a comment -

          Reopening the issue, it's not fixed,
          the Github Source plugin should support to customize the context string

          Fabian Holler added a comment - Reopening the issue, it's not fixed, the Github Source plugin should support to customize the context string

          Yo-An Lin added a comment -

          Yo-An Lin added a comment - I sent a PR for the property support https://github.com/jenkinsci/github-branch-source-plugin/pull/206

          Liam Newman added a comment -

          Liam Newman added a comment - Turns out this is implemented here: https://github.com/jenkinsci/github-scm-trait-notification-context-plugin

            Unassigned Unassigned
            dubrsl Viacheslav Dubrovskyi
            Votes:
            5 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: