How to skip custom clone step for drone exec

Drone Support
1

drone: 1.1.0

Our repo disabled default clone and added a custom step named ‘clone’.

clone:
  disable: true

steps:
  clone:
    ...

But when I tried to run drone exec --exclude clone to test locally, the clone step still ran. Am I doing anything wrong?

2

I’m having this same issue using 1.2.0, FWIW. This is a problem since we keep the secrets to clone the repository in our Drone server, and we don’t particularly want to replicate them on the local client since it’s already cloned. I suspect it’s probably a bug where the custom clone step is added after the steps are excluded, I’ll poke through the source and see if it makes sense to file a PR.

3

I suspect we could work around this by defining different “feeder” pipelines to the main build pipeline, one of which includes the custom clone and one which doesn’t, but that seems like a really gross hack to work around what’s probably a bug.

4

The default clone step is automatically disabled by the CLI when run locally:

Using the following yaml:

kind: pipeline
type: docker
name: default

steps:
- name: greeting
  image: alpine:3.4
  commands:
  - echo hello

We see the clone does not execute:

$ drone exec
[greeting:0] + echo hello
[greeting:1] hello

We can optionally execute clone locally:

$ export DRONE_COMMIT_BRANCH=master
$ export DRONE_COMMIT_SHA=dac60baf1bd8a18c4f2c1c51baae5148bfcef3ce 
$ export DRONE_REMOTE_URL=https://github.com/drone/hello-world.git
$ drone exec --clone

[clone:0] Initialized empty Git repository in /drone/src/.git/
[clone:1] + git fetch origin +refs/heads/master:
[clone:2] From https://github.com/drone/hello-world
[clone:3]  * branch            master     -> FETCH_HEAD
[clone:4]  * [new branch]      master     -> origin/master
[clone:5] + git checkout dac60baf1bd8a18c4f2c1c51baae5148bfcef3ce -b master
[clone:6] Already on 'master'
[greeting:0] + echo hello
[greeting:1] hello

EDIT I see, this looks like it refers to when the default clone is disabled in the yaml and you define your own custom clone step directly in the pipeline? Yes, it looks like this is an edge case that is not accounted for in the CLI (if you rename the step from clone to something else, e.g. fetch, the exclude flag works as expected)

5

Correct, but then if the clone stage is named something else, it doesn’t kick in on the server, so it can’t be cloned.

I’m fine with that not automatically being disabled, though it’s probably better if it’s consistent with the behavior in re: the default clone, which is disabled. But the fact that it can’t be disabled with an explicit --exclude is a problem.

It looks like I can work around it with Jsonnet or Starlark, but I’ll see if I can find where the issue is in the source and submit a PR if those are welcome.

6

hmm, this is not accurate, there is no requirement that the custom clone step needs to be named clone in order to execute on the server. That aside, I agree that the exclude logic should be fixed to resolve this particular edge case.

7

Oh wait, that’s interesting, the documentation could probably use some clarification on this. If I’m interpreting this correctly, the clone step gets executed anyway because it’s the first step in the pipeline (no matter what it’s named), and it’s only forcibly executed when called clone because of said edge case? That makes some sense. I’ll try that out.

8

Let me try to clarify.

When the server executes a pipeline:

  1. Drone automatically prepends a clone step, named clone, to your pipeline
  2. You disabled this behavior by adding clone: { disable: true } to your yaml
  3. You added a step to your pipeline to perform the clone. You happened to name the step clone.
  4. Drone treats all steps the same. It does not treat your user-defined clone step any differently despite its name. As far as Drone is concerned this is just another step.

When the command line tools execute a pipeline:

  1. The command line tools do not automatically prepend a clone step because it mounts your current working directory to access the code.
  2. Because Drone treats all steps the same, it does not automatically disable your user-define clone step. As far as Drone is concerned this is just another step.
  3. The –exclude flag is used to disable user-defined steps. This should have worked but for whatever reason the exclude function was coded to ignore any attempts to exclude steps named clone [1]. Looking back I have no clue why added this restriction …

The reason I refer to this as an edge case is because it only impacts pipelines running locally, with a user-defined step named clone, trying to use –exclude=clone. This is a bug that should be fixed.

However, what I really wanted to clarify is that user-defined steps with the name clone are no different than any other pipeline step, and receive no special treatment from Drone (other than this bug with --exclude).

[1] https://github.com/drone/drone-yaml/blob/master/yaml/compiler/transform/filter.go#L44:L67

2 Likes
9

Right, it does make sense, other than the “why” of it, like you said. Since the main content of that file is all just the initial commit, git blame isn’t much help there. :slight_smile:

Perhaps I’m reading the docs wrong, but they sort of implied that the step should be named “clone” since it’s custom clone logic. It makes much more sense that it’s not a special case… you could probably really simply elide that issue without even adding much/any additional commentary by calling it something else in the doc example like my_custom_clone or something?

10

Good point, we should update the docs and name the step fetch to avoid any confusion, and then add some sort of note indicating that it is just a plain old step and can be named whatever. Thanks for the feedback.

1 Like
11

Absolutely! I’m not trying to come across as too harsh, apologies if that’s the case. Y’all have done a great job with Drone and I’m very happy to be able to be ditching Jenkins for good! I know this is sometimes a thankless task, so thanks very much for keeping up with things so quickly.