Name |
Last commit
|
Last update |
---|---|---|
.. | ||
api | ||
build_artifacts | ||
docker | ||
examples | ||
img | ||
permissions | ||
quick_start | ||
runners | ||
services | ||
ssh_keys | ||
triggers | ||
variables | ||
yaml | ||
README.md | ||
enable_or_disable_ci.md |
BigW Consortium Gitlab
Artifacts expire date What do you think @grzesiek? The syntax will be simple: ``` job: artifacts: expire_in: 7d ``` - [x] Implement `expire_in` - [x] Check current design of expiry information with @jschatz1 and @markpundsack - [x] Add tests in GitLab application for a `ExpireBuildArtifactsWorker` and for `ArtifactsController::keep` - [x] Add user documentation how to use `artifacts:expire_in` - [x] Prepare GitLab Runner changes to pass `expire_in`: gitlab-org/gitlab-ci-multi-runner!191 - [x] Fix `timeago` with help of @jschatz1 - [x] Merge latest master after builds view changes @iamphill - [ ] Add Omnibus support for `expire_build_artifacts_worker` cron job - [ ] Add documentation how to configure `expire_build_artifacts_worker` This is based on https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4201. See merge request !4200
Name |
Last commit
|
Last update |
---|---|---|
.. | ||
api | Loading commit data... | |
build_artifacts | Loading commit data... | |
docker | Loading commit data... | |
examples | Loading commit data... | |
img | Loading commit data... | |
permissions | Loading commit data... | |
quick_start | Loading commit data... | |
runners | Loading commit data... | |
services | Loading commit data... | |
ssh_keys | Loading commit data... | |
triggers | Loading commit data... | |
variables | Loading commit data... | |
yaml | Loading commit data... | |
README.md | Loading commit data... | |
enable_or_disable_ci.md | Loading commit data... |