This is for fixing a regression introduced by:
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/24969
This fix will allow users who are allowed to push to protected
branches to create protected branches via CLI as well, just
like before. The checks for protected branch creation won't
need to run.
This commit includes changes to add `UserAccess#can_create_branch?`
which will check whether the user is allowed to create a branch even
if it matches a protected branch.
This is used in `Gitlab::Checks::BranchCheck` when the branch name
matches a protected branch.
A `push_to_create_protected_branch` ability in `ProjectPolicy` has been
added to allow Developers and above to create protected branches.
When the `changes` passed to `GitAccess` are the literal string `_any`,
which indicates that this is a pre-authorization check, we now check
whether the user can push to any branch in the project in question,
instead of running the per-change check with `oldrev` `_any`, `newrev`
`nil`, and `ref` `nil`.
Validating each commit on ChangeAccess times out if
it already took too long to complete.
Improves the TimedLogger specs to not make use of a stubbed
class anymore
Adds a #full_message method so that external classes
do not have access to the state of the logger.
Adds a #append_message to always append to the array in-place
This significantly improves performance when a user pushes many references.
project.path_locks.any? doesn't cache the output and runs `SELECT 1 AS one
FROM "path_locks" WHERE project_id = N` each time. When there are thousands
of refs being pushed, this can time out the unicorn worker.
CE port for https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/6159.
This makes accessing LFS Objects for a project easier
project.lfs_storage_project.lfs_objects`
becomes
project.all_lfs_objects
This will make the refactor in
https://gitlab.com/gitlab-org/gitlab-ce/issues/39769 easier to deal
with.
We stop relying on Gitlab::Git::Env for the RevList class, and use
Gitlab::Git::Repository#run_git methods inteaad. The refactor also fixes
another issue, since we now top using "path_to_repo" (which is a
Repository model method).
No external behavior change.
This allows `GitHttpController` to set the HTTP status based on the type of error. Alternatively, we could have added an attribute to GitAccessStatus, but this pattern seemed appropriate.
* The spec has 7 failures at this point
* Specify rendered error messages
* Render the GitAccess message rather than “Access denied”
* Render the Not Found message provided by GitAccess, instead of a custom one
* Expect GitAccess to check the config for whether Git-over-HTTP pull or push is disabled, rather than doing it in the controller
* Add more thorough testing for authentication
* Dried up a lot of tests
* Fixed some broken tests