Sometimes you don't want to have CI build every time you push, especially if the build takes a long time or uses many executors.
      It would be nice if it was possible to define criteria to skip building commits, for example, if the commit message contains the string "skip ci" or matches a user-definable regex.
      Temporarily removing or renaming the Jenkinsfile is, of course, a workaround, but not a particularly elegant one.

          [JENKINS-41048] Allow to not build commits of a PR

          Probably a better approach would be to have the first step of the Jenkinsfile check the commit log vs the last build commit and if the all commits since the last build match a regex, then record the build as whatever the last build status was / user configurable.

          If the branch source hid branches where the last commit matched a regex, then you would end up deleting the branch job - which is not what you want.

          We don't know the changelog until the build is started and it would be costly to constantly check the changelog (requiring a full git clone for some repository hosting providers)

          It would be - to my mind - relatively simple to have a pipeline step that checks the changelog against a regex and stops the build early if all commits since last build match the supplied regex.

          Would that be an acceptable solution?

          Stephen Connolly added a comment - Probably a better approach would be to have the first step of the Jenkinsfile check the commit log vs the last build commit and if the all commits since the last build match a regex, then record the build as whatever the last build status was / user configurable. If the branch source hid branches where the last commit matched a regex, then you would end up deleting the branch job - which is not what you want. We don't know the changelog until the build is started and it would be costly to constantly check the changelog (requiring a full git clone for some repository hosting providers) It would be - to my mind - relatively simple to have a pipeline step that checks the changelog against a regex and stops the build early if all commits since last build match the supplied regex. Would that be an acceptable solution?

          emanuelez added a comment -

          It would if it was possible to perform this check before the "build started" status was sent to Github. I'm not sure when such message is sent right now.

          emanuelez added a comment - It would if it was possible to perform this check before the "build started" status was sent to Github. I'm not sure when such message is sent right now.

          Sean Flanigan added a comment -

           

          If the branch source hid branches where the last commit matched a regex, then you would end up deleting the branch job - which is not what you want.

          This could be alleviated to some extent by setting "Days to keep old items" under Orphaned Item Strategy.

          It would also be handy to skip some pull requests entirely (not even creating a job branch for them), for instance when the PR description contains "skip ci" or other regex specified in the job configuration.

          That's not something you could do inside the Jenkinsfile at present, as I understand it.  Also, it sidesteps the whole "scanning the changelog" problem, because the PR description can be fetched from the GitHub API (and it's part of the webhook payload, if you're using webhooks).

          Sean Flanigan added a comment -   If the branch source hid branches where the last commit matched a regex, then you would end up deleting the branch job - which is not what you want. This could be alleviated to some extent by setting "Days to keep old items" under Orphaned Item Strategy. It would also be handy to skip some pull requests entirely (not even creating a job branch for them), for instance when the PR description contains "skip ci" or other regex specified in the job configuration. That's not something you could do inside the Jenkinsfile at present, as I understand it.  Also, it sidesteps the whole "scanning the changelog" problem, because the PR description can be fetched from the GitHub API (and it's part of the webhook payload, if you're using webhooks).

            kohsuke Kohsuke Kawaguchi
            emanuelez emanuelez
            Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated: