![]() Document GIT_STRATEGY=none ## What does this MR do? Adds documentation for the new `GIT_STRATEGY=none` option in GitLab Runner v1.7 ## Are there points in the code the reviewer needs to double check? Speling and grammar, of course. I'm using the term 'project workspace' to refer to the build directory, which is a Jenkins-ism. Is there preferred alternative wording? ## Why was this MR needed? Discoverability of new feature ## Screenshots (if relevant) ## Does this MR meet the acceptance criteria? - <strike>[ ] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added</strike> - [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md) - <strike>[ ] API support added</strike> - <strike>Tests</strike> - <strike>[ ] Added for this feature/bug</strike> - <strike>[ ] All builds are passing</strike> - <strike>[ ] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)</strike> - [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides) - [x] Branch has no merge conflicts with `master` (if you do - rebase it please) - [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits) ## What are the relevant issue numbers? Closes #21337 Depends on http://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/332 See merge request !6577 |
||
---|---|---|
.. | ||
api | ||
build_artifacts | ||
docker | ||
examples | ||
img | ||
permissions | ||
quick_start | ||
runners | ||
services | ||
ssh_keys | ||
triggers | ||
variables | ||
yaml | ||
README.md | ||
enable_or_disable_ci.md | ||
environments.md | ||
pipelines.md |
README.md
GitLab CI Documentation
CI User documentation
- Get started with GitLab CI
- CI examples for various languages
- Learn how to enable or disable GitLab CI
- Pipelines and builds
- Environments and deployments
- Learn how
.gitlab-ci.yml
works - Configure a Runner, the application that runs your builds
- Use Docker images with GitLab Runner
- Use CI to build Docker images
- Use variables in your
.gitlab-ci.yml
- Use SSH keys in your build environment
- Trigger builds through the API
- Build artifacts
- User permissions
- Build permissions
- API
- CI services (linked docker containers)
- New CI build permissions model Read about what changed in GitLab 8.12 and how that affects your builds. There's a new way to access your Git submodules and LFS objects in builds.