| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | |_|/ / / /
| |/| | | | | |
|
| | | | | | | | |
|
| | | |_|_|_|/
| |/| | | |
| | | | | |
| | | | | | |
Closes #15638
|
| | |\ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
- https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/3749#note_11626427
- Personal access tokens are still a separate entity as far as the
codebase is concerned - they just happen to use the same entry point
as private tokens.
- Update tests and documentation to reflect this change
|
| |\ \ \ \ \ \
| |/ / / / / |
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
- 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>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
list
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | |/ /
| |/| | |
|
| | |\ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
# Conflicts:
# Gemfile.lock
|
| | | | | |
| | | | |
| | | | | |
- Parameter validation as ISO8601 format
|
| | |\ \ \ \
| | |_|/ /
| |/| | | |
|
| | | |\ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Prevent information disclosure via milestone API
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/15579
See merge request !1961
|
| | | | |/ /
| | | | |
| | | | |
| | | | | |
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/15579
|
| | | |/ /
| | | |
| | | |
| | | | |
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/15580
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
`API::Helpers`
- Makes the MR easier to read; this can go in a separate MR
- This is a (sort of) revert of 99bea01
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
- In addition to a param.
|
| | | | | |
|
| |/ / /
| | |
| | |
| | | |
`API::Helpers::Authentication`
|
| |/ /
| |
| |
| |
| |
| |
| |
| | |
Previously all remote IPs appeared at 127.0.0.1, which made Akismet
not very useful. Using the ActionDispatch Remote IP (http://api.rubyonrails.org/classes/ActionDispatch/RemoteIp.html)
should provide more reliable results.
Closes #16629
|
| | |
| |
| |
| | |
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/15576
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | |\ \
| | | |
| | | |
| | | |
| | | | |
# Conflicts:
# db/schema.rb
|
| | | | | |
|
| | |\ \ \
| | | |/
| | |/|
| | | |
| | | | |
# Conflicts:
# db/schema.rb
|
| | |\ \ \ |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| |\ \ \ \ \
| |_|_|_|/
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | | |
License templates when creating/editing a LICENSE file
Closes #12804
See merge request !3660
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
endpoint
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | | |_|/
| |/| |
| | | |
| | | | |
endpoint
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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
|
| | |/ / / |
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
This allows us to re-use any other analytics that rely on the "action"
tag having a value set.
|
| | | | | |
|
