Why "clone: false" is not only controlling the repo cloning but also availability of artifacts?

[Alexander Arendar]

When me, as a new user of Bitbucket pipelines, see a step option "clone: false" I suggest that this should control if that particular step clones the repo. In now way it suggests/hints that this also could mean that artifacts from previous steps will not be available. But in reality the semantics is that it will make that step unable to have those artifacts.
My question is simple: why is that designed in that way?

I have a pipeline with some steps that actually don't need my repo files, but they do need some of produces by previous steps files, namely test reports. I was curious if I can somehow optimize the pipeline time. So naturally I thought "ok, the step which uploads my test report to the S3 does not actually need the repo". Ok, then I found that there is an option "clone: false". I thought "great, that will do". And then I realized that my test reports, which are not part of my repo, and which are passed as artifacts, are not available if i add "clone: false" to my S3 upload step.

Maybe I am not experienced enough but that design choice looks a bit weird to me. Cloning the repo is one thing, and artifacts is another thing.

Would be great to hear from the community.

[Syahrul]

Hey @Alexander Arendar 

Welcome to the community!

The reason artifacts aren’t available when you use clone: false is that Bitbucket Pipelines creates the build directory (where artifacts are stored and restored) as part of the repo cloning process. If you skip cloning with clone: false, that directory isn’t setup, so artifacts from previous steps can’t be accessed.

In short, artifact availability is tightly coupled with the repo clone step, which is why disabling cloning also disables artifacts for that step. It's typically use for steps that don’t need the source code, such as sending notifications, uploading files, or running external scripts.

I hope this clarifies.

Regards,
Syahrul

[Alexander Arendar]

Thanks Syahrul,

You mentioned the "uploading files". But precisely this will not work since usually you want to upload some files you prepared in one of previous steps and the only way to access them is from the artifacts, right? But as you already mentioned the artifacts will not be available for "upload files" step whith "clone: false" flag :)

[Syahrul]

Hey @Alexander Arendar 

That's true, it depends on perspective and the use case. For some, uploading files without cloning the repository can be done with specific methods, while others require artifacts, etc.

That said, if you have a particular reason for needing this feature, I can help you submit a feature request.

Regards,
Syahrul

[Derick Downey]

Hmmm I am also using `clone: false` in my YML file and just doing things in a designated folder on the runner, not in the build container that's created/destroyed for each step. I always navigate out of the build container immediately. Then at the end of my step, I move all of my files that I want as "artifacts" from the designated folder on the runner back into the build container, into the "artifacts" folder location that I called out in the YML file. I am only doing one step, so I do not know if it is passing the artifacts to the next step/runner, but I do know that I can download them from the pipeline's results page:

Here's an example of how my YML file starts:

clone:
enabled: false


definitions:
steps:

- step: &build-test
name: Build Test
runs-on:
- self.hosted
- windows
script:
- . $Env:RUNNER_PIPELINES_ROOT\steps\buildTest.ps1
artifacts:
- BuildErrors\**
- BuildLogs\**
- BuildOutput\**
- PipelineLog\**

In order to find the "BuildErrors" artifacts folder I do something like this in PowerShell:

"${Env:BITBUCKET_CLONE_DIR}\BuildErrors"