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

Add concept of "interesting" to SCMHead and SCMRevision

      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.

          [JENKINS-45502] Add concept of "interesting" to SCMHead and SCMRevision

          James Dumay added a comment -

          Note to self: stephenconnolly mentioned this was an important future enhancement

          James Dumay added a comment - Note to self: stephenconnolly mentioned this was an important future enhancement

          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.

          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.

          Nikolas Falco added a comment -

          stephenconnolly 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.

          Nikolas Falco added a comment - stephenconnolly 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.

            Unassigned Unassigned
            stephenconnolly Stephen Connolly
            Votes:
            13 Vote for this issue
            Watchers:
            16 Start watching this issue

              Created:
              Updated: