Cleanup code, and refactor tests that still use Rugged. After this, there should
be no Rugged code that access the instance's repositories on non-test
environments. There is still some rugged code for other tasks like the
repository import task, but since it doesn't access any repository storage path
it can stay.
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 will make it clearer to users which account is being used to make
the API/git call. So they know which account needs to be used to
accept the terms.
Closes#46649
When terms are enforced, but the user has not accepted the terms
access to the API & git is rejected with a message directing the user
to the web app to accept the terms.
[10.3] Migrate `can_push` column from `keys` to `deploy_keys_project`
See merge request gitlab/gitlabhq!2276
(cherry picked from commit f6ca52d31bac350a23938e0aebf717c767b4710c)
1f2bd3c0 Backport to 10.3
Replaces all the explicit include metadata syntax in the specs (tag:
true) into the implicit one (:tag).
Added a cop to prevent future errors and handle autocorrection.
In GitLab EE, a GitLab instance can be read-only (e.g. when it's a Geo
secondary node). But in GitLab CE it also might be useful to have the
"read-only" idea around. So port it back to GitLab CE.
Also having the principle of read-only in GitLab CE would hopefully
lead to less errors introduced, doing write operations when there
aren't allowed for read-only calls.
Closesgitlab-org/gitlab-ce#37534.
`allowed_key_types` is removed and the `minimum_<type>_bits` fields are
renamed to `<tech>_key_restriction`. A special sentinel value (`-1`) signifies
that the key type is disabled.
This also feeds through to the UI - checkboxes per key type are out, inline
selection of "forbidden" and "allowed" (i.e., no restrictions) are in.
As with the previous model, unknown key types are disallowed, even if the
underlying ssh daemon happens to support them. The defaults have also been
changed from the lowest known bit size to "no restriction". So if someone
does happen to have a 768-bit RSA key, it will continue to work on upgrade, at
least until the administrator restricts them.
This is an amalgamation of:
* Cory Hinshaw: Initial implementation !5552
* Rémy Coutable: Updates !9350
* Nick Thomas: Resolve conflicts and add ED25519 support !13712
- Adds a new `ProjectMovedError` class to encapsulate that error
condition. Inherits from `NotFoundError` so existing rescues should
continue to work.
- Separating that condition out of `NotFoundError` allowed us to
simplify the `raise_not_found` helper and avoid repeating the literal
string.
- Spec makes use of `ERROR_MESSAGES` hash to avoid repeating literal
error message strings.
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.
FFaker can generate data that randomly break our test suite. This
simplifies our factories and use sequences which are more predictive.
Signed-off-by: Rémy Coutable <remy@rymai.me>
These specs never ran due to incorrect indentation: the `context` blocks
were inside the `before`.
Additionally, `GitHooksService` now has to yield itself to callers, and
`GitAccess` never appears to have had an `allowed?` method.
* upstream/master:
Ensure we have a project with a repo in GitlabMarkdownHelper specs
Revert "Make sure TraceReader uses Encoding.default_external"
Make sure TraceReader uses Encoding.default_external
Update CONTRIBUTING.md after merging "up-for-grabs" and "Accepting Merge Requests" [ci skip]
Use `:empty_project` where possible in finder specs
Use `empty_project` where possible in controller specs
Use `:empty_project` where possible in helper specs
Don’t count tasks that are not defined as list items correctly
Use a project factory with a repository where necessary
Use `:empty_project` where possible throughout spec/lib
Use hashrocket for dasherized attribute
Remove markdown file extension and add anchor to link
Fixed builds info link on project settings page
Factories with a project association use `:empty_project` by default
Update enviroments.md the example for deleting an environment is missing the "s" in environments. curl --request DELETE --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" "https://gitlab.example.com/api/v3/projects/1/environments/1" wil 404
* master: (1031 commits)
Add changelog entry for renaming API param [ci skip]
Add missing milestone parameter
Refactor issues filter in API
Fix project hooks params
Gitlab::LDAP::Person uses LDAP attributes configuration
Don't delete files from spec/fixtures
Copy, don't move uploaded avatar files
Minor improvements to changelog docs
Rename logo, apply for Slack too
Fix Gemfile.lock for the octokit update
Fix cross-project references copy to include the project reference
Add logo in public files
Use stable icon for Mattermost integration
rewrite the item.respond_to?(:x?) && item.x? to item.try(:x?)
API: extern_uid is a string
Increases pipeline graph drowdown width in order to prevent strange position on chrome on ubuntu
Removed bottom padding from merge manually from CLI because of repositioning award emoji's
Make haml_lint happy
Improve spec
Add feature tests for Cycle Analytics
...
* upstream/master: (3852 commits)
Grapify token API
Fix cache for commit status in commits list to respect branches
Grapify milestones API
Grapify runners API
Improve EeCompatCheck, cache EE repo and keep artifacts for the ee_compat_check task
Use 'Forking in progress' title when appropriate
Fix CHANGELOG after 8.14.0-rc1 tag
Update CHANGELOG.md for 8.14.0-rc1
Fix YAML syntax on CHANGELOG entry
Remove redundant rescue from repository keep_around
Remove redundant space from repository model code
Remove order-dependent expectation
Minor CHANGELOG.md cleanups
Add a link to Git cheatsheet PDF in docs readme
Grapify the session API
Add 8.13.5, 8.12.9, and 8.11.11 CHANGELOG
Merge branch 'unauthenticated-container-registry-access' into 'security'
Merge branch '23403-fix-events-for-private-project-features' into 'security'
Merge branch 'fix-unathorized-cloning' into 'security'
Merge branch 'markdown-xss-fix-option-2.1' into 'security'
...
1. Remove `Project#developers_can_push_to_protected_branch?` since it
isn't used anymore.
2. Remove `Project#developers_can_merge_to_protected_branch?` since it
isn't used anymore.
1. The crux of this change is in `UserAccess`, which looks through all
the access levels, asking each if the user has access to push/merge
for the current project.
2. Update the `protected_branches` factory to create access levels as
necessary.
3. Fix and augment `user_access` and `git_access` specs.
1. Don't use case statements for dispatch anymore. This leads to a lot
of duplication, and makes the logic harder to follow.
2. Remove duplicated logic.
- For example, the `can_push_to_branch?` exists, but we also have a
different way of checking the same condition within `change_access_check`.
- This kind of duplication is removed, and the `can_push_to_branch?`
method is used in both places.
3. Move checks returning true/false to `UserAccess`.
- All public methods in `GitAccess` now return an instance of
`GitAccessStatus`. Previously, some methods would return
true/false as well, which was confusing.
- It makes sense for these kinds of checks to be at the level of a
user, so the `UserAccess` class was repurposed for this. The prior
`UserAccess.allowed?` classmethod is converted into an instance
method.
- All external uses of these checks have been migrated to use the
`UserAccess` class
4. Move the "change_access_check" into a separate class.
- Create the `GitAccess::ChangeAccessCheck` class to run these
checks, which are quite substantial.
- `ChangeAccessCheck` returns an instance of `GitAccessStatus` as
well.
5. Break out the boolean logic in `ChangeAccessCheck` into `if/else`
chains - this seems more readable.
6. I can understand that this might look like overkill for !4892, but I
think this is a good opportunity to clean it up.
- http://martinfowler.com/bliki/OpportunisticRefactoring.html
1. When a merge request is being merged, save the merge commit SHA in
the `in_progress_merge_commit_sha` database column.
2. The `pre-receive` hook looks for any locked (in progress) merge
request with `in_progress_merge_commit_sha` matching the `newrev` it
is passed.
3. If it finds a matching MR, the merge is legitimate.
4. Update `git_access_spec` to test the behaviour we added here. Also
refactored this spec a bit to make it easier to add more contexts / conditions.
Alejandro Rodríguez
Jacob Vosmaer (GitLab)
Mark Chao
Rubén Dávila
Stan Hu
Bob Van Landuyt
Mayra Cabrera
Tomasz Maczukin
Michael Kozono
James Edwards-Jones
Tiago Botelho
Douwe Maan
blackst0ne
Jacopo
Toon Claes
Nick Thomas
Robert Speicher
Rémy Coutable
Sam Rose
Douwe Maan
Sean McGivern
Semyon Pupkov
Lin Jen-Shin
Kamil Trzcinski
Ali Ibrahim
Timothy Andrew
Timothy Andrew
Mathias Vestergaard
Patricio Cano
Grzegorz Bizon
Jeroen van Baarsen
Valery Sizov
Marin Jankovski
Dmitriy Zaporozhets
Valery Sizov
Ciro Santilli