Configure whether step performs git clone

Issue #16628 open
created an issue

We don't need to perform a git clone of the repo at every single step of our pipeline, files we need between steps can be persisted with artifacts.

I suggest you move the logic for the following into (b)ash functions:

  • git clone (int depth)
  • artifact restore (string step_name)

that way users can run the clone or the artifact restore when and how they want.

At the moment it's costing us 55secs for each step, when we only need it on one step per pipeline.

Comments (12)

  1. Aneita Yang staff
    • changed status to open

    Hi @ZenobiusJ,

    Thanks for reaching out and for the suggestion - I can definitely see why having the ability to specify whether a step clones the repo will be beneficial to you.

    We currently don't have any plans to implement this functionality; however, I'll open this issue to see whether other users are interested in seeing the same thing. We revisit our open issues on a regular basis so this may be something that we consider in future.


  2. Victor van den Bosch

    Cannot wait for this becoming a feature. It should be even though it might not seem like many people have an issue with the current functionality.

    • Issue #17819 describes one of our exact use cases, Atlassian/Pipelines uses k8s too, so internally you should have similar use cases right?
    • The fix suggested by Mathias is exactly what I tried as well and I would like it to 'just work'.

    Clone depth is about how much of the history you want to retain, not about whether or not to clone, but it could feature as such even though 0 it is not an accepted value in the git clone command itself. Maybe it seems deceptively simple, but I'd imagine validating the clone depth value as a positive int and then modifying the pipelines startup to simply not run the git clone logic if the value is exactly 0 should be simple enough.

    I can't believe this was not a use case from the beginning of Deployments at least. Rebuilding artifacts for different environments is considered bad practice, mostly, and thus cloning the whole repo when not needed is just wasteful. For us it means we cannot use Deployments/Pipelines at all for our largest repos of 1GB+ in git and more in LFS.

  3. Jordan Mele

    This has a significant impact on pipelines with multiple build steps, particularly when each individual step is quite fast on its own (5 second fast for example). End result is releases taking longer to complete and when doing any development that depends on pipeline results, facing a longer debug loop (which quickly compounds resulting in tedious tasks taking significantly longer to complete).

  4. Log in to comment