• Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • branch-api-plugin
    • None

      Adding the event object that triggered the build will expose more information. E.g in case of BitbucketServerPullRequestEvent it will allow to know within the pipeline what are the source and target branch without querying Bitbucket 

          [JENKINS-49051] Add event field to BranchEventCause

          Yuri Goikhman added a comment - - edited

          Yuri Goikhman added a comment - - edited stephenconnolly I've created a PR https://github.com/jenkinsci/branch-api-plugin/pull/124   please take a look 

          Removing myself as assignee. My current work assignments do not provide sufficient bandwidth to review these issues and in the majority of cases I am only assigned by virtue of being the default assignee. For the credentials-api and scm-api related plugins I have permission to allocate time reviewing changes to these APIs themselves to ensure these APIs remain cohesive, but that can be handled through PR reviews rather than assigning issues in JIRA

          Stephen Connolly added a comment - Removing myself as assignee. My current work assignments do not provide sufficient bandwidth to review these issues and in the majority of cases I am only assigned by virtue of being the default assignee. For the credentials-api and scm-api related plugins I have permission to allocate time reviewing changes to these APIs themselves to ensure these APIs remain cohesive, but that can be handled through PR reviews rather than assigning issues in JIRA

          Liam Newman added a comment -

          yurigo79
          This point of this would be to reduce network bandwidth right?
          Network connection would still be needed for some data sooner or later.

          This change will require additional changes to derived classes to make it useful.

          You mention the bitbucket plugin. Have you considered implementing the desired changes locally there to see how they go? I understand this change would have benefits for other scm plugins, but it might be worth it to workout the kinks within the context of a single plugin before changing the upstream classes/apis.

          Liam Newman added a comment - yurigo79 This point of this would be to reduce network bandwidth right? Network connection would still be needed for some data sooner or later. This change will require additional changes to derived classes to make it useful. You mention the bitbucket plugin. Have you considered implementing the desired changes locally there to see how they go? I understand this change would have benefits for other scm plugins, but it might be worth it to workout the kinks within the context of a single plugin before changing the upstream classes/apis.

          We have an other use case, where the source event would be interesting: to determine if a PR build is started due to a change in the target branch or in the origin branch.

          In the case of the bitbucket-branch-source plugin, the information is contained in the received notification but it get lost when creating a BranchEventCause.

          Marc Guillemot added a comment - We have an other use case, where the source event would be interesting: to determine if a PR build is started due to a change in the target branch or in the origin branch. In the case of the bitbucket-branch-source plugin, the information is contained in the received notification but it get lost when creating a BranchEventCause.

            Unassigned Unassigned
            yurigo79 Yuri Goikhman
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: