| Age | Commit message (Collapse) | Author |
|---|
|
This ensures that we have more visibility in the number of SQL queries
that are executed in web requests. The current threshold is hardcoded to
100 as we will rarely (maybe once or twice) change it.
In production and development we use Sentry if enabled, in the test
environment we raise an error. This feature is also only enabled in
production/staging when running on GitLab.com as it's not very useful to
other users.
|
|
|
|
Mitigate a N+1 requests to Gitaly problem. Still one left.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
In API v4 when requesting a branch with an invalid refname shows an
helpful error message: 'The branch refname is invalid'.
|
|
|
|
|
|
|
|
As we only override in two places, we could just ask for the value rather than
the method name.
|
|
|
|
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
branch name when the project full patch contains a `/`
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
API routes
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
It adds a button to the branches page that the user can use to delete
all the branches that are already merged. This can be used to clean up
all the branches that were forgotten to delete while merging MRs.
Fixes #21076.
|
|
|
|
- Pass `developers_and_merge` and `developers_can_push` in `params`
instead of using keyword arguments.
- Refactor a slightly complex boolean check to a simple `nil?` check.
|
|
|
|
1. Previously, we were not removing existing access levels before
creating new ones. This is not a problem for EE, but _is_ for CE,
since we restrict the number of access levels in CE to 1.
2. The correct approach is:
CE -> delete all access levels before updating a protected branch
EE -> delete developer access levels if "developers_can_{merge,push}" is switched off
3. The dispatch is performed by checking if a "length: 1" validation is
present on the access levels or not.
4. Another source of problems was that we didn't put multiple queries in
a transaction. If the `destroy_all` passes, but the `update` fails,
we should have a rollback.
5. Modifying the API to provide users direct access to CRUD access
levels will make things a lot simpler.
6. Create `create/update` services separately for this API, which
perform the necessary data translation, before calling the regular
`create/update` services. The translation code was getting too large
for the API endpoint itself, so this move makes sense.
|
|
1. `GitPushService` was still using `{merge,push}_access_level_attributes` instead
of `{merge,push}_access_levels_attributes`.
2. The branches API creates access levels regardless of the state of the
`developers_can_{push,merge}` parameters. This is in line with the UI,
where Master access is the default for a new protected branch.
3. Use `after(:build)` to create access levels in the
`protected_branches` factory, so that `factories_spec` passes. It
only builds records, so we need to create access levels on `build` as
well.
|
|
1. It makes sense to reuse these constants since we had them duplicated
in the previous enum implementation. This also simplifies our
`check_access` implementation, because we can use
`project.team.max_member_access` directly.
2. Use `accepts_nested_attributes_for` to create push/merge access
levels. This was a bit fiddly to set up, but this simplifies our code
by quite a large amount. We can even get rid of
`ProtectedBranches::BaseService`.
3. Move API handling back into the API (previously in
`ProtectedBranches::BaseService#translate_api_params`.
4. The protected branch services now return a `ProtectedBranch` rather
than `true/false`.
5. Run `load_protected_branches` on-demand in the `create` action, to
prevent it being called unneccessarily.
6. "Masters" is pre-selected as the default option for "Allowed to Push"
and "Allowed to Merge".
7. These changes were based on a review from @rymai in !5081.
|
|
1. The new data model moves from `developers_can_{push,merge}` to
`allowed_to_{push,merge}`.
2. The API interface has not been changed. It still accepts
`developers_can_push` and `developers_can_merge` as options. These
attributes are inferred from the new data model.
3. Modify the protected branch create/update services to translate from
the API interface to our current data model.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
not_found appends string "Not Found" to the argument causing the resulting message to be "Branch does not exist Not Found" which is an incorrect error message.
Changed the argument of not_found! for 'unprotect' command to "Branch" from "Branch does not exist". This makes the final error message to appear as "Branch Not Found" which is correct and same as error messages for other commands like 'protect'.
|
|
|
|
|
|
Branch names that contain `/` return a 405 error when being deleted because the slash is escaped to `%2F`
This patch will unescape the param prior to executing the delete action.
|
|
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
|
|
Add specs for GitRefValidator
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
#6128 (https://github.com/gitlabhq/gitlabhq/issues/6128).
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
|
Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>
|
