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

Git Web Hook doesn't exclude changes when using docker plugin (no persistent workspace)

    Details

    • Similar Issues:

      Description

      I have a GitHub repo setup with a Webhook Service (specifically "Jenkins (Git Plugin)") pointed to my Jenkins instance. My job is restricted to only run using a Docker container as setup using the Docker Plugin . It also has Git SCM set up to look at the aforementioned repo, but is set up with "Polling ignores commits from certain users".

      I have tried all combinations of the following examples as the excluded users:

      Jake Romigh
      "Jake Romigh"
      jromigh
      jromigh@email.com
      Jake Romigh <jromigh@email.com>
      "Jake Romigh <jromigh@email.com>"

      When I make a change to my Git repo, my job will always build in spite of my excluded users list. My expected behavior is that Git would not build changes made by an excluded user.

      I have also tried using the "Polling ignores commits with certain messages" to no avail.

      When I take a look at the resulting runs, this is the Changes log:

      Started on Jul 7, 2015 6:47:13 PM
      Workspace is offline.
      Scheduling a new build to get a workspace. (nonexisting_workspace)
      Done. Took 1 ms
      Changes found

      I have found the following related issues:

      None of the workarounds in the comments of those issues work in this situation, including "Force polling using workspace". I believe the core of the issue is that no persistent workspace exists for the docker-plugin jobs.

      The result is that we have users building with the maven-release-plugin that have jobs constantly building over and over with no real changes because we can't exclude the service account. We can't have a dummy trigger workspace for each one of these jobs because that solution simply doesn't scale.

      Using Plugins:
      Docker Plugin 0.10.0
      Git Plugin 2.3.5
      Git Client Plugin 1.17.1
      GitHub Plugin 1.11.3
      GitHub API plugin 1.68

      Using Software:
      Jenkins 1.617
      GitHub Enterprise 2.1.6

        Attachments

          Activity

          Hide
          markewaite Mark Waite added a comment -

          As far as I know, there is no way to exclude users without a workspace for polling. The call which checks for remote changes ("git ls-remote") only receives a list of branch names and SHA1 hashes, so it cannot determine the user who committed the change without a workspace.

          You might experiment with a work around using a multi-configuration job which is configured to execute on only a single machine. The multi-configuration job will clone the repository in a "flyweight executor" on one of the existing nodes, then it will clone again on your docker node. The clone made to the flyweight executor may be enough to allow the git plugin to have the workspace it needs for user exclusions.

          Show
          markewaite Mark Waite added a comment - As far as I know, there is no way to exclude users without a workspace for polling. The call which checks for remote changes ("git ls-remote") only receives a list of branch names and SHA1 hashes, so it cannot determine the user who committed the change without a workspace. You might experiment with a work around using a multi-configuration job which is configured to execute on only a single machine. The multi-configuration job will clone the repository in a "flyweight executor" on one of the existing nodes, then it will clone again on your docker node. The clone made to the flyweight executor may be enough to allow the git plugin to have the workspace it needs for user exclusions.
          Hide
          maxfields2000 Maxfield Stewart added a comment -

          I'm not sure that's true. If you use a github webhook you get a /mountain/ of information in JSON and XML format back, with all the data you'd want from the hook itself.

          The JSON spec includes the refs, before/after revisions as well as a list of commits. It also has pusher identification and login info. Everything you'd need to use an exclusion list.

          You would just need to pull this information from the data sent via the hook /not/ using local git commands in the repo. That seems to be a legit way to do it (and until I understood this problem better how I thought hooks were working). It would appear though that Jenkins just ignores all the data that comes in the hook and /just/ runs the build jobs settings instead.

          Show
          maxfields2000 Maxfield Stewart added a comment - I'm not sure that's true. If you use a github webhook you get a /mountain/ of information in JSON and XML format back, with all the data you'd want from the hook itself. The JSON spec includes the refs, before/after revisions as well as a list of commits. It also has pusher identification and login info. Everything you'd need to use an exclusion list. You would just need to pull this information from the data sent via the hook /not/ using local git commands in the repo. That seems to be a legit way to do it (and until I understood this problem better how I thought hooks were working). It would appear though that Jenkins just ignores all the data that comes in the hook and /just/ runs the build jobs settings instead.
          Hide
          maxfields2000 Maxfield Stewart added a comment -

          Conversly is there some way to /not/ trigger a build if the only event was a git TAG? Git seems to treat tags as "events. But in the use case where you say, build a maven project on commit, then that does a release and tags the repo with a git tag, that tag event then causes another build... the cycle continues ad naseum. We're using the exclude users list as a way to stop the build because only an automated agent does the git tag so it's an easy filter.

          Show
          maxfields2000 Maxfield Stewart added a comment - Conversly is there some way to /not/ trigger a build if the only event was a git TAG? Git seems to treat tags as "events. But in the use case where you say, build a maven project on commit, then that does a release and tags the repo with a git tag, that tag event then causes another build... the cycle continues ad naseum. We're using the exclude users list as a way to stop the build because only an automated agent does the git tag so it's an easy filter.
          Hide
          markewaite Mark Waite added a comment - - edited

          Maxfield Stewart I am not familiar with what information from the GitHub webhook data is available to the git plugin, but I have seen no code to extract information from webhook data in any of my work with the git plugin or the git client plugin.

          I believe the Jenkins notifyCommit facility intentionally ignores most data from the webhook (for security reasons), based on Kohsuke's comment in his "polling must die" blog posting. In that posting, he says:

          Finally, this URL doesn’t require authentication even for secured Jenkins, because the server doesn’t directly use anything that the client is sending. It runs polling to verify that there is a change, before it actually starts a build.

          I'm not aware of any way to not trigger a build on a change to the repository. I'm accustomed to the maven release plugin tagging the most recent commit, creating a new commit, and needing to push that new commit to the central repository so that development can continue on the new SNAPSHOT version.

          Show
          markewaite Mark Waite added a comment - - edited Maxfield Stewart I am not familiar with what information from the GitHub webhook data is available to the git plugin, but I have seen no code to extract information from webhook data in any of my work with the git plugin or the git client plugin. I believe the Jenkins notifyCommit facility intentionally ignores most data from the webhook (for security reasons), based on Kohsuke's comment in his " polling must die " blog posting. In that posting, he says: Finally, this URL doesn’t require authentication even for secured Jenkins, because the server doesn’t directly use anything that the client is sending. It runs polling to verify that there is a change, before it actually starts a build. I'm not aware of any way to not trigger a build on a change to the repository. I'm accustomed to the maven release plugin tagging the most recent commit, creating a new commit, and needing to push that new commit to the central repository so that development can continue on the new SNAPSHOT version.
          Hide
          maxfields2000 Maxfield Stewart added a comment -

          That seems reasonable, this is just a case of me learning how things actually work over how I assumed they worked. I'm still unclear how people avoid triggering builds when all you to do is add a git tag. Your explanation at the end seems to imply that the cycle you describe somehow doesn't result in never ending build chains. If you're not excluding users, tagging the git branch will just trigger a build because there's no clean way I can see to ignore commits that are just "tags" (Git doesn't seem to differentiate, that's not the plugin's fault)

          I'm going to assume most people use exclude users and don't deal with situations where there is no workspace, something that is only common if you deal with ephemeral build environments, which perhaps Jenkins, Git and the git plugin just aren't suited to the use case.

          It is unfortunate that Github sends a wealth of information in the body of the webhook call that is just ignored and unavailable to the job or Jenkins but I get that having an unauthenticated end point that triggers jobs based on the data it sends could present complications to security. Perhaps the way out is for us to design a plugin that accepts custom webhooks that use token capabilities and can parse the data.

          For now our work around spins up the entire build environment just so that the workspace can be created, it then checks the commit data itself as the build job starts and aborts the build cleanly. It's a waste of executors, resources, and pollutes the build history but it works.

          Show
          maxfields2000 Maxfield Stewart added a comment - That seems reasonable, this is just a case of me learning how things actually work over how I assumed they worked. I'm still unclear how people avoid triggering builds when all you to do is add a git tag. Your explanation at the end seems to imply that the cycle you describe somehow doesn't result in never ending build chains. If you're not excluding users, tagging the git branch will just trigger a build because there's no clean way I can see to ignore commits that are just "tags" (Git doesn't seem to differentiate, that's not the plugin's fault) I'm going to assume most people use exclude users and don't deal with situations where there is no workspace, something that is only common if you deal with ephemeral build environments, which perhaps Jenkins, Git and the git plugin just aren't suited to the use case. It is unfortunate that Github sends a wealth of information in the body of the webhook call that is just ignored and unavailable to the job or Jenkins but I get that having an unauthenticated end point that triggers jobs based on the data it sends could present complications to security. Perhaps the way out is for us to design a plugin that accepts custom webhooks that use token capabilities and can parse the data. For now our work around spins up the entire build environment just so that the workspace can be created, it then checks the commit data itself as the build job starts and aborts the build cleanly. It's a waste of executors, resources, and pollutes the build history but it works.

            People

            • Assignee:
              ndeloof Nicolas De Loof
              Reporter:
              jromigh Jake Romigh
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: