Currently, when used within the context of a GiHub Branch Source hierarchy, all this plugin can do is let me set a custom but hardcoded notification context. (Since it is configured once for all jobs in the hierarchy)
It would be useful to be able to dynamically set a custom (different) context for all jobs in the whole branch source hierarchy. For example, I could resolve JENKINS-55726 when opening daggy fix PRs (same origin branch) by setting a custom context like this (hypothetical variable):
jenkins/${JOB_NAME}
Then I wouldn't have each job marking multiple PRs passed or failed. This is just one use case.
With my changes and context set to xxxx-${JOB_NAME}, the check contexts are unique, but they all show up on all daggy PRs for the same source branch (see screenshot). Still, it's better than randomly and incorrectly marking related PRs.
Side Note: This is a Jenkins issue. When building the same github PRs using Azure DevOps, daggy PR build result is logged correctly (one job to one PR, even though they share a destination branch).
Alexander Komarov
added a comment - - edited With my changes and context set to xxxx-${JOB_NAME} , the check contexts are unique, but they all show up on all daggy PRs for the same source branch (see screenshot). Still, it's better than randomly and incorrectly marking related PRs.
Side Note: This is a Jenkins issue. When building the same github PRs using Azure DevOps, daggy PR build result is logged correctly (one job to one PR, even though they share a destination branch).
Steven Foster
Alexander Komarov
Votes:
0Vote for this issue
Watchers:
1Start watching this issue
Created:
Updated:
{"errorMessages":["jqlTooComplex"],"errors":{}}
[{"id":-1,"name":"My open issues","jql":"assignee = currentUser() AND resolution = Unresolved order by updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":true},{"id":-2,"name":"Reported by me","jql":"reporter = currentUser() order by created DESC","isSystem":true,"sharePermissions":[],"requiresLogin":true},{"id":-4,"name":"All issues","jql":"order by created DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-5,"name":"Open issues","jql":"resolution = Unresolved order by priority DESC,updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-9,"name":"Done issues","jql":"statusCategory = Done order by updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-3,"name":"Viewed recently","jql":"issuekey in issueHistory() order by lastViewed DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-6,"name":"Created recently","jql":"created >= -1w order by created DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-7,"name":"Resolved recently","jql":"resolutiondate >= -1w order by updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false},{"id":-8,"name":"Updated recently","jql":"updated >= -1w order by updated DESC","isSystem":true,"sharePermissions":[],"requiresLogin":false}]
With my changes and context set to xxxx-${JOB_NAME}, the check contexts are unique, but they all show up on all daggy PRs for the same source branch (see screenshot). Still, it's better than randomly and incorrectly marking related PRs.
Side Note: This is a Jenkins issue. When building the same github PRs using Azure DevOps, daggy PR build result is logged correctly (one job to one PR, even though they share a destination branch).