Cloning
Updated 2 years ago
by
Admin
Drone automatically clones your repository before executing your pipeline steps. No special configuration is required. In some cases, however, you may need to customize, override or disable the default clone behavior.
The --depth flag
The default clone configuration does use the --depth flag. You can enforce a clone depth by declaring a clone block and adding the depth attribute:
1 kind: pipeline
2 type: docker
3 name: default
4
5 clone:
6 depth: 50
7
8 steps:
9 - name: build
10 image: golang
11 commands:
12 - go build
13 - go test
The --tags flag
The default clone configuration does not use the --tags flag. If you would like to fetch tags you should handle this as a step in your pipeline. For example:
1 kind: pipeline
2 type: docker
3 name: default
4
5 steps:
6 - name: fetch
7 image: alpine/git
8 commands:
9 - git fetch --tags
10
11 - name: build
12 image: golang
13 commands:
14 - go build
15 - go test
The --recursive flag
The default clone behavior does not use the --recursive flag and does not fetch submodules. If you would like to fetch submodules you should handle this as a step in your pipeline. For example:
1 kind: pipeline
2 type: docker
3 name: default
4
5 steps:
6 - name: submodules
7 image: alpine/git
8 commands:
9 - git submodule update --recursive --remote
10
11 - name: build
12 image: golang
13 commands:
14 - go build
15 - go test
Custom Logic
The default clone behavior can be disabled and custom clone logic implemented, when necessary. In the following example we implement custom clone commands as a pipeline step:
1 kind: pipeline
2 type: docker
3 name: default
4
5 clone:
6 disable: true
7
8 steps:
9 - name: clone
10 image: alpine/git
11 commands:
12 - git clone https://github.com/octocat/hello-world.git .
13 - git checkout $DRONE_COMMIT
14
15 - name: build
16 image: golang
17 commands:
18 - go build
19 - go test
Authentication
If your repository is private or requires authentication to clone, Drone injects the credentials into your pipeline environment. Drone uses the oauth2 token associated with the repository owner as the clone credentials.
Security Consideration
If your repository is private or requires authentication to clone, the clone credentials are injected into to your pipeline environment which means a malicious collaborator could submit a patch (to your pipeline configuration, unit tests, etc.) that attempts to expose these credentials during pipeline execution. Drone provides options, described below, to mitigate these risks.
Limit Clone Credentials
It is considered best practice to configure the Drone runners to only inject the clone credentials into the default clone step. This prevents untrusted code from from being able to access and expose the clone credentials.
Machine Accounts
It is also possible to create a machine user with the exact permissions and access required to clone your repository and its dependencies. Login to Drone using the machine user account and activate your repositories. The machine account credentials will be injected into your pipeline environment, eliminating risk of exposing credentials linked to a user account.
Global Machine Accounts
In the previous section we described creating a machine user. The downside to this approach is you have to login as the machine user to activate repositories. This section describes how to use machine account credentials regardless of the account that activated the repository.
If you configure a global machine account, it forces Drone to always use the global machine account credentials to clone all private repositories, regardless of the account that activated the repository. Please use the following links to configure global credentials:
