Add notices about disabling auth features for users with 2FA.
Related to #2979
- Document the proposed changes to the GitLab authentication system.
- This is done because currently, users with 2FA enabled are allowed API access without a 2FA token.
# Tasks
- [ ] #2979 !xxxx - Document proposed auth changes for 2FA users
- [x] Wait for replies on "[potential avenues for documenting the planned changes](https://gitlab.com/gitlab-org/gitlab-ce/issues/2979#note_12591578)"
- [x] Update documentation
- [ ] CHANGELOG entry?
- [ ] Merge conflicts
See merge request !4815
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
The `sha` parameter is optional, and when present, must match the
current HEAD SHA of the source branch. Otherwise, the API call fails
with a 409 Conflict and a message containing the current HEAD for the
source branch.
Also tidy up some doc wording.
Amend jira service api docs [ci skip]
## What does this MR do?
Amends the API documentation for jira service integration
## Are there points in the code the reviewer needs to double check?
No
## Why was this MR needed?
The current documentation omits the username and password parameters
## What are the relevant issue numbers?
## Screenshots (if relevant)
See merge request !4382
Added authentication service for docker registry
This adds a simple authentication service for docker which uses current user credentials to authenticate pulls and pushes.
I have only one concern. Since the `.docker/config` is unencrypted, thus the password for user stored there is unencrypted, maybe we should from the start implement function to generate/provide a separate password just for the purposes of accessing docker registry?
What do you think @jacobvosmaer @sytses @marin?
cc @marin
See merge request !3787
The user API documentation and the actual implementation were out of sync, missing certain newly introduced fields and beeing inconsistent between certain API definitions. The documentation was changed according the actual latest implementation.
Signed-off-by: Fabio Huser <fabio@fh1.ch>
Achilleas Pipinellis
Timothy Andrew
Takuya Noguchi
Marc Siegfriedt
Z.J. van de Weg
Patricio Cano
Grzegorz BizonandAchilleas Pipinellis
Rémy Coutable
Kamil TrzcinskiandPhil Hughes
Stan Hu
Mark Fletcher
Sean McGivern
Richard Grainger
Chris Spicer
Sanster
Hannes Rosenögger
Douwe Maan
Ahmad Sherif
cnam-depandRémy Coutable
Dmitriy Zaporozhets
Thomas WoodandAchilleas Pipinellis
Fabio HuserandFabio Huser
Douwe Maan
Aral Balkan
Paco Guzman
Michael Greene