You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Step checks out the defined repository state, optionally updates the repository submodules and exports the achieved git repository state properties.
5
+
Checks out the repository, updates submodules and exports git metadata as Step outputs.
6
6
7
7
<details>
8
8
<summary>Description</summary>
9
9
10
-
The checkout process depends on the checkout properties: the Step either checks out a repository state defined by a git commit or a git tag, or achieves a merged state of a pull / merge request.
11
-
The Step uses two solutions to achieve the merged state of the pull / merge request: auto merge in the case of a merge branch or diff file (provided by the Git service) and manual merge otherwise.
12
-
Once the desired state is checked out, the Step optionally updates the submodules. In the case of pull / merge request, the Step checks out a detach head and exports the achieved git state properties.
10
+
The checkout process depends on the Step settings and the build trigger parameters (coming from your git server).
11
+
12
+
Depending on the conditions, the step can checkout:
13
+
- the merged state of a Pull Request
14
+
- the head of a Pull Request
15
+
- a git tag
16
+
- a specific commit on a branch
17
+
- the head of a branch
18
+
19
+
The Step also supports more advanced features, such as updating submodules and sparse checkouts.
13
20
14
21
### Configuring the Step
15
22
16
-
1. The **Git repository URL** and the ** Clone destination (local)directory path** fields are required fields and are automatically filled out based on your project settings.
17
-
Optionally, you can modify the following fields in the **Clone Config** section:
18
-
1. You can set the **Update the registered submodules?** option to `yes` to pull the most up-to-date version of the submodule from the submodule's repository.
19
-
2. You can set the number of commits you want the Step to fetch in the **Limit fetching to the specified number of commits** option. Make sure you set a decimal number.
23
+
The step should work with its default configuration if build triggers and webhooks are set up correctly.
20
24
21
-
Other **Clone config** inputs are not editable unless you go to the **bitrise.yml** tab, however, to avoid issues, we suggest you to contact our Support team instead.
25
+
By default, the Step performs a shallow clone in most cases (fetching only the latest commit) to make the clone fast and efficient. If your workflow requires a deeper commit history, you can override this using the **Clone depth** input.
22
26
23
-
### Troubleshooting
24
-
If you have GitHub Enterprise set up, it works slightly differently on [bitrise.io](https://www.bitrise.io) than on [github.com](https://github.com). You have to manually set the git clone URL, register the SSH key and the webhook.
25
-
If you face network issues in the case of self-hosted git servers, we advise you to contact our Support Team to help you out.
26
-
If you face slow clone speed, set the **Limit fetching to the specified number of commits** to the number of commits you want to clone instead of cloning the whole commit history or you can use the Git LFS solution provided by the git provider.
27
-
28
27
### Useful links
29
28
30
29
-[How to register a GitHub Enterprise repository](https://discuss.bitrise.io/t/how-to-register-a-github-enterprise-repository/218)
|`pull_request_head_branch`| If the Git hosting provider system supports and provides this, this special git ref should point to the source of the pull request. ||`$BITRISEIO_PULL_REQUEST_HEAD_BRANCH`|
64
-
|`update_submodules`| Update the registered submodules to match what the superproject expects by cloning missing submodules, fetching missing commits in submodules and updating the working tree of the submodules. If set to "no" `git fetch` calls will get the `--no-recurse-submodules` flag. ||`yes`|
65
-
|`clone_depth`| Limit fetching to the specified number of commits. The value should be a decimal number, for example `10`. |||
66
-
|`submodule_update_depth`| Truncate the history to the specified number of revisions. The value should be a decimal number, for example `10`. |||
67
-
|`merge_pr`| Disables merging the source and destination branches. - `yes`: The default setting. Merges the source branch into the destination branch. - `no`: Treats Pull Request events as Push events on the source branch. ||`yes`|
68
-
|`sparse_directories`| Limit which directories should be cloned during the build. This could be useful if a repository contains multiple platforms, so called monorepositories, and the build is only targeting a single platform. For example, specifying "src/android" the Step will only clone: - contents of the root directory and - contents of the "src/android" directory and all subdirectories of "src/android". On the other hand, "src/ios" and any other directories will not be cloned. |||
69
-
|`reset_repository`|||`No`|
70
-
|`manual_merge`| Prefer to do a manual `git merge` by default. When the Pull Request is from a GitHub or Bitbucket private fork repository set this to `no`. ||`yes`|
71
-
|`fetch_tags`| yes - fetch all tags from the remote by adding `--tags` flag to git fetch calls no - disable automatic tag following by adding `--no-tags` flag to git fetch calls ||`no`|
52
+
|`merge_pr`| This only applies to builds triggered by pull requests. Options: - `yes`: Depending on the information in the build trigger, either fetches the PR merge ref or creates the merged state locally. - `no`: Checks out the head of the PR branch without merging it into the destination branch. ||`yes`|
53
+
|`clone_into_dir`| Local directory where the repository is cloned | required |`$BITRISE_SOURCE_DIR`|
54
+
|`clone_depth`| Limit fetching to the specified number of commits. By default, the Step tries to do a shallow clone (depth of 1) if it's possible based on the build trigger parameters. If it's not possible, it applies a low depth value, unless another value is specified here. It's not recommended to define this input because a shallow clone ensures fast clone times. Examples of when you want to override the clone depth: - A Step in the workflow reads the commit history in order to generate a changelog - A Step in the workflow runs a git diff against a previous commit Use the value `-1` to disable the depth limit completely and fetch the entire repo history. |||
55
+
|`update_submodules`| Update registered submodules to match what the superproject expects. If set to `no`, `git fetch` calls will use the `--no-recurse-submodules` flag. ||`yes`|
56
+
|`submodule_update_depth`| When updating submodules, limit fetching to the specified number of commits. The value should be a decimal number, for example `10`. |||
57
+
|`fetch_tags`| yes - fetch all tags from the remote by adding `--tags` flag to `git fetch` calls no - disable automatic tag following by adding `--no-tags` flag to `git fetch` calls ||`no`|
58
+
|`sparse_directories`| Limit which directories to clone using [sparse-checkout](https://git-scm.com/docs/git-sparse-checkout). This is useful for monorepos where the current workflow only needs a subfolder. For example, specifying `src/android` the Step will only clone: - contents of the root directory and - contents of the `src/android` directory and all of its subdirectories On the other hand, `src/ios` will not be cloned. This input accepts one path per line, separate entries by a linebreak. |||
59
+
|`repository_url`| SSH or HTTPS URL of the repository to clone | required |`$GIT_REPOSITORY_URL`|
60
+
|`commit`| Commit SHA to checkout ||`$BITRISE_GIT_COMMIT`|
61
+
|`tag`| Git tag to checkout ||`$BITRISE_GIT_TAG`|
62
+
|`branch`| Git branch to checkout ||`$BITRISE_GIT_BRANCH`|
63
+
|`branch_dest`| The branch that the pull request targets, such as `main`||`$BITRISEIO_GIT_BRANCH_DEST`|
64
+
|`pull_request_repository_url`| URL of the source repository of a pull request. This points to the fork repository in builds triggered by pull requests. ||`$BITRISEIO_PULL_REQUEST_REPOSITORY_URL`|
65
+
|`pull_request_merge_branch`| Git ref pointing to the result of merging the PR branch into the destination branch. Even if the source of the PR is a fork, this is a reference to the destination repository. Example: `refs/pull/14/merge` Note: not all Git services provide this value. ||`$BITRISEIO_PULL_REQUEST_MERGE_BRANCH`|
66
+
|`pull_request_head_branch`| Git ref pointing to the head of the PR branch. Even if the source of the PR is a fork, this is a reference to the destination repository. Example: `refs/pull/14/head` Note: not all Git services provide this value. ||`$BITRISEIO_PULL_REQUEST_HEAD_BRANCH`|
67
+
|`reset_repository`| Reset repository contents with `git reset --hard HEAD` and `git clean -f` before fetching. ||`No`|
72
68
|`build_url`| Unique build URL of this build on Bitrise.io ||`$BITRISE_BUILD_URL`|
73
69
|`build_api_token`| The build's API Token for the build on Bitrise.io | sensitive |`$BITRISE_BUILD_API_TOKEN`|
74
70
</details>
75
71
76
72
<details>
77
73
<summary>Outputs</summary>
78
74
79
-
| Environment Variable | Description |
80
-
|------------------------------------| --- |
81
-
|`GIT_CLONE_COMMIT_HASH`||
82
-
|`GIT_CLONE_COMMIT_MESSAGE_SUBJECT`||
83
-
|`GIT_CLONE_COMMIT_MESSAGE_BODY`||
84
-
|`GIT_CLONE_COMMIT_COUNT`|Count will only work properly if no `--depth` option is set. If `--depth` is set then the history truncated to the specified number of commits. Count will **not** fail but will be the clone depth. |
85
-
|`GIT_CLONE_COMMIT_AUTHOR_NAME`||
86
-
|`GIT_CLONE_COMMIT_AUTHOR_EMAIL`||
87
-
|`GIT_CLONE_COMMIT_COMMITTER_NAME`||
88
-
|`GIT_CLONE_COMMIT_COMMITTER_EMAIL`||
75
+
| Environment Variable | Description |
76
+
|---| --- |
77
+
|`GIT_CLONE_COMMIT_HASH`| SHA hash of the checked-out commit.|
78
+
|`GIT_CLONE_COMMIT_MESSAGE_SUBJECT`|Commit message of the checked-out commit.|
79
+
|`GIT_CLONE_COMMIT_MESSAGE_BODY`| Commit message body of the checked-out commit.|
80
+
|`GIT_CLONE_COMMIT_COUNT`| Commit count after checkout. Count will only work properly if no `--depth` option is set. If `--depth` is set then the history truncated to the specified number of commits. Count will **not** fail but will be the clone depth. |
81
+
|`GIT_CLONE_COMMIT_AUTHOR_NAME`| Author of the checked-out commit.|
82
+
|`GIT_CLONE_COMMIT_AUTHOR_EMAIL`| Email of the checked-out commit.|
83
+
|`GIT_CLONE_COMMIT_COMMITTER_NAME`| Committer name of the checked-out commit.|
84
+
|`GIT_CLONE_COMMIT_COMMITTER_EMAIL`|Email of the checked-out commit.|
0 commit comments