• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • None

      Another field in the global configuration to set shallow cloning as a default value. This makes sense for most people and builds.

          [JENKINS-73901] Global Configuration for Shallow Clone

          Mahyar created issue -
          Mark Waite made changes -
          Assignee Original: Mark Waite [ markewaite ]

          Mark Waite added a comment -

          I don't intend to add global configuration options like this.

          Mark Waite added a comment - I don't intend to add global configuration options like this.
          Mark Waite made changes -
          Resolution New: Won't Do [ 10001 ]
          Status Original: Open [ 1 ] New: Resolved [ 5 ]

          Mahyar added a comment -

          markewaite Could you clarify your position why?

          What alternative other than manually modifying over 500 active jobs does this answer provide? Shallow cloning is an extremely common tactic for building servers to lower bandwidth and speed up builds.

          Mahyar added a comment - markewaite Could you clarify your position why? What alternative other than manually modifying over 500 active jobs does this answer provide? Shallow cloning is an extremely common tactic for building servers to lower bandwidth and speed up builds.
          Mahyar made changes -
          Resolution Original: Won't Do [ 10001 ]
          Status Original: Resolved [ 5 ] New: Reopened [ 4 ]

          Mark Waite added a comment - - edited

          Adding global options increases the likelihood of unexpected interactions for users and increases the likelihood of unexpected bugs for maintainers.

          If you are using Jenkins Pipeline, then you can modify the job definitions with your usual source code editor.

          If you are using Jenkins freestyle jobs, you can modify job definitions with the configuration slicing plugin. Alternately, you can modify job definitions by editing the XML configuration files.

          Mark Waite added a comment - - edited Adding global options increases the likelihood of unexpected interactions for users and increases the likelihood of unexpected bugs for maintainers. If you are using Jenkins Pipeline, then you can modify the job definitions with your usual source code editor. If you are using Jenkins freestyle jobs, you can modify job definitions with the configuration slicing plugin. Alternately, you can modify job definitions by editing the XML configuration files.

          Mahyar added a comment -

          While I do agree with your thesis that global options increase likelihood of unexpected interactions, I would strongly emphasize this is not one of them.

          In nearly all builds, aside from those running Git history commands like `git rev-parse`, no builds would be affected by this change. For those who are using such a complicated command, the error output would be straightforward enough that they could disable shallow cloning for their pipeline.

          The impact of this global action is also pretty obvious for a system administrator who could alleviate burden from maintainers on this project. It can also be disabled by default so that users have to opt-in.

          I'll also add that you already have global options for things like `Add git tag action to jobs`. Surely, this is less cryptic and less error-prone than this existing global configuration.

          Mahyar added a comment - While I do agree with your thesis that global options increase likelihood of unexpected interactions, I would strongly emphasize this is not one of them. In nearly all builds, aside from those running Git history commands like `git rev-parse`, no builds would be affected by this change. For those who are using such a complicated command, the error output would be straightforward enough that they could disable shallow cloning for their pipeline. The impact of this global action is also pretty obvious for a system administrator who could alleviate burden from maintainers on this project. It can also be disabled by default so that users have to opt-in. I'll also add that you already have global options for things like `Add git tag action to jobs`. Surely, this is less cryptic and less error-prone than this existing global configuration.

          Mark Waite added a comment -

          While I do agree with your thesis that global options increase likelihood of unexpected interactions, I would strongly emphasize this is not one of them.

          A global shallow clone option will have unexpected interactions. There are versions of command line git that fail a merge when the repository has been shallow cloned. Users that expect to perform a merge with those git versions will be surprised when merge operations fail because the administrator enabled shallow clone. The results from git log are often very different with a shallow clone.

          Mark Waite added a comment - While I do agree with your thesis that global options increase likelihood of unexpected interactions, I would strongly emphasize this is not one of them. A global shallow clone option will have unexpected interactions. There are versions of command line git that fail a merge when the repository has been shallow cloned. Users that expect to perform a merge with those git versions will be surprised when merge operations fail because the administrator enabled shallow clone. The results from git log are often very different with a shallow clone.
          Mark Waite made changes -
          Status Original: Reopened [ 4 ] New: Open [ 1 ]

            Unassigned Unassigned
            mahmirrjca Mahyar
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated: