Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-45502

Add concept of "interesting" to SCMHead and SCMRevision

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      There are a number of use cases that require the ability to define branches as being interesting as well as the ability to define specific revisions as being interesting

      The general idea is that when a branch or revision is not interesting (or if interesting is a scalar rather than a boolean then if the interesting scalar is less than some cut-off) then branch-api would not automatically build the branch / revision. The Build button would still be available from within the Jenkins UI so that users could still manually request builds, but Jenkins would only automatically build the interesting things (and if interesting is a scalar it could even prioritise building more interesting things first) 

      • Some people would like to discover origin branches and origin PRs, when the origin PR is created from the origin branch - for example when the origin branch is a long lived branch and they use periodic pull requests to review synchronization between branches - then they would want the origin branch job to be retained... but that origin branch job (which is effectively building PR-head) is not as interesting as the PR-merge branch job.

      Currently, you could prevent building the branch twice (or three times if building PR-merge and PR-head) by only discovering origin branches that are not also filed as PRs... but in that case you are relying on the orphaned branch strategy not deleting your origin branch before merging the PR.

      With the concept of interesting branches we could say that the origin branch is not as interesting as the PR-merge or the PR-head branches.

      • Adding Tag support will be easier if we consider old Tags as non-interesting by default. Whether new tags are considered interesting would be something that users could configure using traits.

      Another use case is where people want to prevent automatic building of revisions until specific criteria have been met:

      • Only automatically build revisions that have been flagged as OK to build. This is somewhat similar to trusted revisions, but a different concern as you could have interesting but not trusted as well as trusted but not interesting.
      • Flag specific revisions as non-interesting based on the commit comment or perhaps even based on the files modified

      This is not an exhaustive list of the utility of the "interesting" concept.

        Attachments

          Issue Links

            Activity

            Hide
            jamesdumay James Dumay added a comment -

            Note to self: Stephen Connolly mentioned this was an important future enhancement

            Show
            jamesdumay James Dumay added a comment - Note to self: Stephen Connolly mentioned this was an important future enhancement
            Hide
            witokondoria Javier Delgado added a comment -

            I would add to the non exhaustive list of the "interesting" concept another item:

            • Branches unmodified since a defined threshold (days?)

            This way, a newly created branch-source-plugin would run just a subset of branches, leavin old ones.

            Show
            witokondoria Javier Delgado added a comment - I would add to the non exhaustive list of the "interesting" concept another item: Branches unmodified since a defined threshold (days?) This way, a newly created branch-source-plugin would run just a subset of branches, leavin old ones.
            Hide
            nfalco Nikolas Falco added a comment -

            Stephen Connolly I'm interessed about you idea of scalar instead of boolean returned from a possible new API SCMSourceContext.skipEvent (or <skip|trigger>Build). In case of scalar the people that configure a job how could know which are value contributed by each SCMEventFilter and how this impact the final value of the scalar to match against the cute-off?

            I'm asking because recently I had implement release as pipeline and to avoid trigger multiple builds with something similar of JENKINS-41048 (here) I skip some kinds of events (more details here) but this marks the branch (master) to remove.

            This feature is required for our organisation and seems froosen from long time. I have budget to implement this and I would some clarification to propose something of acceptable.

            Show
            nfalco Nikolas Falco added a comment - Stephen Connolly I'm interessed about you idea of scalar instead of boolean returned from a possible new API SCMSourceContext.skipEvent (or <skip|trigger>Build). In case of scalar the people that configure a job how could know which are value contributed by each SCMEventFilter and how this impact the final value of the scalar to match against the cute-off? I'm asking because recently I had implement release as pipeline and to avoid trigger multiple builds with something similar of JENKINS-41048 ( here ) I skip some kinds of events (more details here ) but this marks the branch (master) to remove. This feature is required for our organisation and seems froosen from long time. I have budget to implement this and I would some clarification to propose something of acceptable.

              People

              • Assignee:
                Unassigned
                Reporter:
                stephenconnolly Stephen Connolly
              • Votes:
                10 Vote for this issue
                Watchers:
                13 Start watching this issue

                Dates

                • Created:
                  Updated: