• 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

          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.

          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.

          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 added a comment -

          Since you reopened the issue, I assume that means you intend to persuade some other maintainer of the git plugin to implement the feature or you intend to implement the feature yourself and persuade some other maintainer of the git plugin to merge the feature. I don't plan to implement this feature and I don't plan to approve a pull request that includes this feature.

          Mark Waite added a comment - Since you reopened the issue, I assume that means you intend to persuade some other maintainer of the git plugin to implement the feature or you intend to implement the feature yourself and persuade some other maintainer of the git plugin to merge the feature. I don't plan to implement this feature and I don't plan to approve a pull request that includes this feature.

          Mahyar added a comment -

          I don't agree with your firm stance against this addition. How is an administrator enabling shallow cloning on all jobs any different than an administrator enabling shallow cloning globally?

          In the example that you provided, I've never come across this particular workflow of merging within a job.

          > Since you reopened the issue, I assume that means you intend to persuade some other maintainer of the git plugin to implement the feature or you intend to implement the feature yourself and persuade some other maintainer of the git plugin to merge the feature. I don't plan to implement this feature and I don't plan to approve a pull request that includes this feature.

          You're correct there, but I hope that means that also means that you are not intending to decline a pull request that includes this feature.

          Mahyar added a comment - I don't agree with your firm stance against this addition. How is an administrator enabling shallow cloning on all jobs any different than an administrator enabling shallow cloning globally? In the example that you provided, I've never come across this particular workflow of merging within a job. > Since you reopened the issue, I assume that means you intend to persuade some other maintainer of the git plugin to implement the feature or you intend to implement the feature yourself and persuade some other maintainer of the git plugin to merge the feature. I don't plan to implement this feature and I don't plan to approve a pull request that includes this feature. You're correct there, but I hope that means that also means that you are not intending to decline a pull request that includes this feature.

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

              Created:
              Updated: