Add Application Setting to configure Container Registry token expire delay (default 5min)
This adds an option to configure Container Registry token expire delay. The default is set to 5mins (something that is also used by Docker Hub).
What is left:
* [x] Write test to check the expire_delay
Fixes: https://gitlab.com/gitlab-org/gitlab-ce/issues/17890
@stanhu I think that this should land in patch release of 8.8.
See merge request !4364
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
Restrict starred projects to viewable ones
`User#starred_projects` doesn't perform any visibility checks. This has
a couple of problems:
1. It assumes a user can always view all of their starred projects in
perpetuity (project not changed to private, access revoked, etc.).
2. It assumes that we'll only ever allow a user to star a project they
can view. This is currently the case, but bugs happen.
Add `User#viewable_starred_projects` to filter the starred projects by
those the user either has explicit access to, or are public or
internal. Then use that in all places where we list the user's starred
projects.
Closes#17249.
See merge request !4108
`User#starred_projects` doesn't perform any visibility checks. This has
a couple of problems:
1. It assumes a user can always view all of their starred projects in
perpetuity (project not changed to private, access revoked, etc.).
2. It assumes that we'll only ever allow a user to star a project they
can view. This is currently the case, but bugs happen.
Add `User#viewable_starred_projects` to filter the starred projects by
those the user either has explicit access to, or are public or
internal. Then use that in all places where we list the user's starred
projects.
- Fix naming of API::CommitStatuses
- Ensure we use require_dependency instead of require
- Ensure the namespace is right in lib/api/api.rb, otherwise, we
might require Grape::API::Helpers which defines the `#params` method.
This is to avoid requiring a file multiple times and getting an "Already
initialized constant" error.
Signed-off-by: Rémy Coutable <remy@rymai.me>
Ci::Commit becomes a Pipeline object
1. Ci::Commit receives context: ref, :tag.
1. One Ci::Commit describes a one Pipeline
1. Pipeline is created from `.gitlab-ci.yml`
1. Pipeline is a ordered group of builds
1. We test MR against Pipeline
1. Pipelines have a separate view (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3703)
1. Pipeline can be triggered from UI (https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3703)
1. Later we change `Trigger -> TriggerRequest -> Build` to `Trigger -> Pipeline` (future)
1. We add a Pipeline Hook that will be triggered on Pipeline status change (future)
1. We extend notifications to use `Pipeline Hook` to send summary on pipeline changes (future)
After merging that I'll prepare a separate MR that will unify naming, database columns, table names:
```
Ci::Commit -> Pipeline
Ci::Build -> Build
CommitStatus -> Job
GenericCommitStatus -> ExternalJob
ci_commits -> pipelines
ci_builds -> jobs
```
This MR implements first 5 points.
This is made to solve this issue https://gitlab.com/gitlab-org/gitlab-ce/issues/14149.
See merge request !3653
Merely setting the "action" tag will only result in the transaction
itself containing a value for this tag. To ensure other metrics also
contain this tag we must set the action using Transaction#action=
instead.
API: Present an array of Gitlab::Git::Tag instead of array of rugged tags
The annotated message was always `null` because the wrong array was presented.
The entity requires an array of `Gitlab::Git::Tags` instead an array of raw rugged tags was presented. Since a rugged tag does not respond to `message` to get the annotated message, this was always `null`.
See merge request !3764