You can set the GIT_STRATEGY used to fetch the repository content, either globally or per-job in the variables section:
代码语言:javascript
复制
variables: GIT_STRATEGY: clone | fetch | none
There are three possible values: clone, fetch, and none. If left unspecified, jobs use the project’s pipeline setting.
clone is the slowest option. It clones the repository from scratch for every job, ensuring that the local working copy is always pristine. If an existing worktree is found, it is removed before cloning.
fetch is faster as it re-uses the local working copy (falling back to clone if it does not exist). git clean is used to undo any changes made by the last job, and git fetch is used to retrieve commits made after the last job ran.
git clean: Cleans the working tree by recursively removing files that are not under version control, starting from the current directory.
A Git strategy of none also re-uses the local working copy, but skips all Git operations normally done by GitLab. GitLab Runner pre-clone scripts are also skipped, if present. This strategy could mean you need to add fetch and checkout commands to your .gitlab-ci.yml script.
It can be used for jobs that operate exclusively on artifacts, like a deployment job. Git repository data may be present, but it’s likely out of date. You should only rely on files brought into the local working copy from cache or artifacts.
The GitLab Package Registry acts as a private or public registry for a variety of common package managers. You can publish and share packages, which can be easily consumed as a dependency in downstream projects.
The Package Registry supports the following formats:
To introduce a checkpoint in your source code history, you can assign a Git tag at the moment of release. However, in most cases, your users need more than just the raw source code.They need compiled objects or other assets output by your CI/CD system.
A GitLab Release is a snapshot of the source, build output, artifacts, and other metadata associated with a released version of your code.
You can create a GitLab release on any branch. When you create a release:
GitLab automatically archives source code and associates it with the release.
GitLab automatically creates a JSON file that lists everything in the release, so you can compare and audit releases. This file is called release evidence.
You can add release notes and a message for the tag associated with the release.
After you create a release, you can associate milestones with it, and attach release assets, like runbooks or packages.