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

Allow [ci skip] to work for non-pull request changes

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      the README for version 0.1.1 of https://plugins.jenkins.io/bitbucket-scm-trait-commit-skip indicates, in the Description, that "The filtering is only performed at change requests events, so push events to non-pull requests will be always run."

      it would be totally amazing and make my day if this functionality applied equally to non-pull request changes (we never build pull requests).

      i assigned it to you, javier, just to make sure you'd see it. please feel free to detach yourself.

        Attachments

          Issue Links

            Activity

            kburnett Kevin Burnett created issue -
            Hide
            witokondoria Javier Delgado added a comment -

            There is a potential huge risk of skipping events for non pull request events. As of current implementation, the filtering is made via the isExcuded overriden method. As a collateral hiccup, the job is marked as disabled (and would be eventually be wiped with a configured Orphaned Item Strategy)

            As per Stephen Connolly comment at a GitHub PR;

            The commit message "filter" should actually be using https://issues.jenkins-ci.org/browse/JENKINS-45502 longer term
            

            That ticket would (hopefully) erase the drawbacks of the current implementation.

            In the mean time, if you are fully aware of the current risk (or not using any Orphaned Item Strategy), I could work on it. What are your thoughts Kevin Burnett?

            Again: Implementing this feature could cause a job to become erased, losing all of its run history

            Show
            witokondoria Javier Delgado added a comment - There is a potential huge risk of skipping events for non pull request events. As of current implementation, the filtering is made via the isExcuded overriden method. As a collateral hiccup, the job is marked as disabled (and would be eventually be wiped with a configured Orphaned Item Strategy) As per Stephen Connolly comment at a GitHub PR ; The commit message "filter" should actually be using https: //issues.jenkins-ci.org/browse/JENKINS-45502 longer term That ticket would (hopefully) erase the drawbacks of the current implementation. In the mean time, if you are fully aware of the current risk (or not using any Orphaned Item Strategy), I could work on it. What are your thoughts Kevin Burnett ? Again: Implementing this feature could cause a job to become erased, losing all of its run history
            witokondoria Javier Delgado made changes -
            Field Original Value New Value
            Status Open [ 1 ] In Progress [ 3 ]
            witokondoria Javier Delgado made changes -
            Link This issue is related to JENKINS-45502 [ JENKINS-45502 ]
            Hide
            kburnett Kevin Burnett added a comment -

            I upvoted JENKINS-45502. i don't fully understand the issue. i defer to your best judgement, unless Stephen Connolly wants to weigh in.

            Show
            kburnett Kevin Burnett added a comment - I upvoted JENKINS-45502 . i don't fully understand the issue. i defer to your best judgement, unless Stephen Connolly wants to weigh in.
            Hide
            witokondoria Javier Delgado added a comment -

            Let me futher explain that risk, supposiong:

            • You have a GitHub Organization or Bitbucket Team/Project job
            • You have a X branch, with a Jenkinsfile
            • You have an Orphaned Item Strategy, discarding disabled jobs
            • You have a Scan Organization Triggers, set with an interval Y
            • This feature is implemented to "skip" executions from branches
            • You push one commit with [skip ci] in it message to that X branch

            Whenever the event gets processed, the master branch would be tagged as excluded. Y time after, the Scan Organization Triggers will kick a full repo scan and the Orphaned Item Strategy will delete the Jenkinns job associated to that master branch, so you will end losing the whole master job history.

            Show
            witokondoria Javier Delgado added a comment - Let me futher explain that risk, supposiong: You have a GitHub Organization or Bitbucket Team/Project job You have a X branch, with a Jenkinsfile You have an Orphaned Item Strategy , discarding disabled jobs You have a Scan Organization Triggers , set with an interval Y This feature is implemented to "skip" executions from branches You push one commit with [skip ci] in it message to that X branch Whenever the event gets processed, the master branch would be tagged as excluded. Y time after, the Scan Organization Triggers will kick a full repo scan and the Orphaned Item Strategy will delete the Jenkinns job associated to that master branch, so you will end losing the whole master job history.
            Hide
            dbsanfte David Sanftenberg added a comment - - edited

            This seems like an edge case. Nobody should be relying on Jenkins to keep their entire build history, it's not an archival platform. And if they are by some chance, they shouldn't be using that Orphaned Item Strategy.

            Please implement this feature.

            Show
            dbsanfte David Sanftenberg added a comment - - edited This seems like an edge case. Nobody should be relying on Jenkins to keep their entire build history, it's not an archival platform. And if they are by some chance, they shouldn't be using that Orphaned Item Strategy. Please implement this feature.
            Hide
            witokondoria Javier Delgado added a comment -

            Will try my best to add the feature this week, but (un)fortunately i have become pretty occupied, so there wont be any guarantees

            Show
            witokondoria Javier Delgado added a comment - Will try my best to add the feature this week, but (un)fortunately i have become pretty occupied, so there wont be any guarantees
            Hide
            marbon marbon added a comment -

            Any update on this issue? We are very interested in using "[ci skip]" to skip maven release commits for example.

            Show
            marbon marbon added a comment - Any update on this issue? We are very interested in using " [ci skip] " to skip maven release commits for example.
            Hide
            witokondoria Javier Delgado added a comment -

            Just for the record: I have finally started working on it.
            Still untested, Github associated feature seems to be easy, from the provided API, to implement. OTOH, BitBucket API seems its missing some bolts (so might slow everything a bit)

            Show
            witokondoria Javier Delgado added a comment - Just for the record: I have finally started working on it. Still untested, Github associated feature seems to be easy, from the provided API, to implement. OTOH, BitBucket API seems its missing some bolts (so might slow everything a bit)
            Hide
            kburnett Kevin Burnett added a comment -

            you are a hero.

            Show
            kburnett Kevin Burnett added a comment - you are a hero.
            Hide
            witokondoria Javier Delgado added a comment -

            Kevin Burnett, marbon and David Sanftenberg, could you test the opened pull request artifacts? Both hpi files found at https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fscm-trait-commit-skip-plugin/detail/feature%2FskippingBranches/1/artifacts (github and bitbucket) implement filtering branches on both [skip-ci] and [ci-skip] committed messages

            Show
            witokondoria Javier Delgado added a comment - Kevin Burnett , marbon and David Sanftenberg , could you test the opened pull request artifacts? Both hpi files found at https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fscm-trait-commit-skip-plugin/detail/feature%2FskippingBranches/1/artifacts (github and bitbucket) implement filtering branches on both [skip-ci] and [ci-skip] committed messages
            kburnett Kevin Burnett made changes -
            Attachment cannot-load.png [ 44772 ]
            Hide
            witokondoria Javier Delgado added a comment -

            Forgot to say that for testing this on bitbucket, another incrementals dependency must be manually installed (hpi from https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fbitbucket-branch-source-plugin/detail/PR-145/7/artifacts)

            Needless to say that these are developments versions ans should be installed (desireably) on a test Jenkins instance

            Show
            witokondoria Javier Delgado added a comment - Forgot to say that for testing this on bitbucket, another incrementals dependency must be manually installed (hpi from https://ci.jenkins.io/blue/organizations/jenkins/Plugins%2Fbitbucket-branch-source-plugin/detail/PR-145/7/artifacts ) Needless to say that these are developments versions ans should be installed (desireably) on a test Jenkins instance
            kburnett Kevin Burnett made changes -
            Attachment duplicate-name-in-config.png [ 44786 ]
            Hide
            kburnett Kevin Burnett added a comment -

            i got the dependent plugin from https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/cloudbees-bitbucket-branch-source/2.2.13-rc440.a1f1e6c1d925/, tested it out with Jason Lantz, and it works as designed. in our context, the fact that the branch is tagged excluded and therefore deleted by the orphaned item strategy (exactly as Javier Delgado said it would be) actually is a dealbreaker. we are very excited about this feature, but i think we need to wait for JENKINS-45502 to be implemented so that "ci skip" can be implemented without this side effect (FYI, Stephen Connolly / James Dumay).

            two additional notes:

            • you need to specify "ci skip" without the hyphen
            • when you specify behaviours, there are now two called "Commit message filtering behaviour" (one for pull requests and one for branches). they should probably have different names. see screenshot below.

            thanks a ton, Javier Delgado.

            Show
            kburnett Kevin Burnett added a comment - i got the dependent plugin from https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/cloudbees-bitbucket-branch-source/2.2.13-rc440.a1f1e6c1d925/ , tested it out with Jason Lantz , and it works as designed. in our context, the fact that the branch is tagged excluded and therefore deleted by the orphaned item strategy (exactly as Javier Delgado said it would be) actually is a dealbreaker. we are very excited about this feature, but i think we need to wait for JENKINS-45502 to be implemented so that "ci skip" can be implemented without this side effect (FYI, Stephen Connolly / James Dumay ). two additional notes: you need to specify "ci skip" without the hyphen when you specify behaviours, there are now two called "Commit message filtering behaviour" (one for pull requests and one for branches). they should probably have different names. see screenshot below. thanks a ton, Javier Delgado .
            Hide
            witokondoria Javier Delgado added a comment -

            Certainly, the expected tokens doesnt contain hypens (á la circleci - https://circleci.com/docs/2.0/skip-build/)
            There is another PR, still unreviewed, to allow a regexp (instead of such fixed tokens).
            Will fix the behaviour names so they differ
            The outcome of JENKINS-45502 will indeed alter how the skipping is performed. Nevertheless, giving the ticket priority and activity, I wouldnt foresee it to receive work mid-term.

            Show
            witokondoria Javier Delgado added a comment - Certainly, the expected tokens doesnt contain hypens (á la circleci - https://circleci.com/docs/2.0/skip-build/ ) There is another PR, still unreviewed, to allow a regexp (instead of such fixed tokens). Will fix the behaviour names so they differ The outcome of JENKINS-45502 will indeed alter how the skipping is performed. Nevertheless, giving the ticket priority and activity, I wouldnt foresee it to receive work mid-term.
            Hide
            shamil Alex Simenduev added a comment -

            Javier Delgado any updates on this. We are really looking forward to this feature...

            Show
            shamil Alex Simenduev added a comment - Javier Delgado any updates on this. We are really looking forward to this feature...
            Hide
            witokondoria Javier Delgado added a comment -

            This should be included on the 0.2.0 released plugin. Should appear at the update center shortly.

            Could you provide feedback, in order to close this ticket?

            Show
            witokondoria Javier Delgado added a comment - This should be included on the 0.2.0 released plugin. Should appear at the update center shortly. Could you provide feedback, in order to close this ticket?
            Hide
            shamil Alex Simenduev added a comment -

            Thanks a lot Javier Delgado. Works as expected!

            Show
            shamil Alex Simenduev added a comment - Thanks a lot Javier Delgado . Works as expected!
            witokondoria Javier Delgado made changes -
            Status In Progress [ 3 ] In Review [ 10005 ]
            witokondoria Javier Delgado made changes -
            Resolution Fixed [ 1 ]
            Status In Review [ 10005 ] Resolved [ 5 ]
            Hide
            kiemes Tom Kiemes added a comment -

            Javier Delgado sorry to bother, but was this developed just for Bitbucket or also for GitHub?

            I am using version 0.4.0 of "GitHub Commit Skip SCM Behaviour" plugin on a Jenkins connected to GitHub Enterprise and my configuration looks as follows:

            • GitHub Organisation project
            • Build strategies (in this order; not sure if the order is important here):
              • Change requests
              • Regular branches
              • Skip build trigger if commit message contains
                • Pattern : skip

            The documentation still states, that "The filtering is only performed for change request events, so push events to non-pull requests will be always run". But the same sentence is still in the doc for BitBucket and as far as I understand the discussion, this is working?

            Any help would be appreciated.

            Best regards, Tom

            Show
            kiemes Tom Kiemes added a comment - Javier Delgado sorry to bother, but was this developed just for Bitbucket or also for GitHub? I am using version 0.4.0 of "GitHub Commit Skip SCM Behaviour" plugin on a Jenkins connected to GitHub Enterprise and my configuration looks as follows: GitHub Organisation project Build strategies (in this order; not sure if the order is important here): Change requests Regular branches Skip build trigger if commit message contains Pattern : skip The documentation still states, that "The filtering is only performed for change request events, so push events to non-pull requests will be always run". But the same sentence is still in the doc for BitBucket and as far as I understand the discussion, this is working? Any help would be appreciated. Best regards, Tom

              People

              Assignee:
              witokondoria Javier Delgado
              Reporter:
              kburnett Kevin Burnett
              Votes:
              6 Vote for this issue
              Watchers:
              8 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: