| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix bug where destroying a namespace would not always destroy projects
There is a race condition in DestroyGroupService now that projects are deleted asynchronously:
1. User attempts to delete group
2. DestroyGroupService iterates through all projects and schedules a Sidekiq job to delete each Project
3. DestroyGroupService destroys the Group, leaving all its projects without a namespace
4. Projects::DestroyService runs later but the can?(current_user,
:remove_project) is `false` because the user no longer has permission to
destroy projects with no namespace.
5. This leaves the project in pending_delete state with no namespace/group.
Projects without a namespace or group also adds another problem: it's not possible to destroy the container registry tags, since `container_registry_path_with_namespace` is the wrong value.
The fix is to destroy the group asynchronously and run `execute` directly on Projects::DestroyService.
Closes #17893
See merge request !4341
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There is a race condition in DestroyGroupService now that projects are deleted asynchronously:
1. User attempts to delete group
2. DestroyGroupService iterates through all projects and schedules a Sidekiq job to delete each Project
3. DestroyGroupService destroys the Group, leaving all its projects without a namespace
4. Projects::DestroyService runs later but the can?(current_user,
:remove_project) is `false` because the user no longer has permission to
destroy projects with no namespace.
5. This leaves the project in pending_delete state with no namespace/group.
Projects without a namespace or group also adds another problem: it's not possible to destroy the container
registry tags, since container_registry_path_with_namespace is the wrong value.
The fix is to destroy the group asynchronously and to run execute directly on Projects::DestroyService.
Closes #17893
|
| | | |
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
DRY code + fix rubocop
Add more test cases
Append to changelog
DRY changes list
find_url service for merge_requests
use GET for getting merge request links
remove files
rename to get_url_service
reduce loop
add test case for cross project
refactor tiny thing
update changelog
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Refactor pipeline creation service
## What does this MR do?
This refactors GitLab CI build processing: all builds for pipeline are pre-created when a pipeline object is created.
The builds are created with a new introduced status `created`.
The builds are then automatically promoted to `pending` when a previous stage do succeed.
This significantly simplifies pipeline processing code solving a lot of problems of lazily initialisation of previous approach (builds were created on-demand).
## Why was this MR needed?
The previous mechanism had a lot of flows (shown in related issues) in how it work, but also in code design. Removing cross model-service-library dependencies.
The current approach moves a build creation to single place `CreatePipelineService` and removes a dynamic dependency on `config_processor` significantly simplifying a build creation and pipeline processing. Pipeline processing is implemented in `ProcessPipelineService`.
This also allows to easily extend GitLab with Manual Actions which is part of 8.10 direction issue.
## Migration problem
~~This MR removes the a on-demand creation of builds in pipelines.
Pipelines that are running and are in mid-stage (some stages started, but not all) will not be fully evaluated after application restart.
This happens, because the code responsible for on-demand creation is removed.
There's no easy way to migrate existing pipelines, other than doing offline migration and putting pipeline processing in migration code (which seems to be a really bad idea).~~
To support old pipelines I added a lazy initialization of builds if none is found.
## What are the relevant issue numbers?
Fixes: https://gitlab.com/gitlab-org/gitlab-ce/issues/12839
Solves: https://gitlab.com/gitlab-org/gitlab-ce/issues/18644 https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/issues/289
Allows to easily implement: https://gitlab.com/gitlab-org/gitlab-ce/issues/17010
## Does this MR meet the acceptance criteria?
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [x] API support added
- Tests
- [x] Added for this feature/bug
- [ ] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !5295
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This change simplifies a Pipeline processing by introducing a special new status: created.
This status is used for all builds that are created for a pipeline.
We are then processing next stages and queueing some of the builds (created -> pending) or skipping them (created -> skipped).
This makes it possible to simplify and solve a few ordering problems with how previously builds were scheduled.
This also allows us to visualise a full pipeline (with created builds).
This also removes an after_touch used for updating a pipeline state parameters.
Right now in various places we explicitly call a reload_status! on pipeline to force it to be updated and saved.
|
| |/
|
|
|
|
|
|
| |
Also, mutualize AccessRequests and Members endpoints for Group &
Project.
New API documentation for the AccessRequests endpoints.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |
|
|
|
|
| |
Instead of redirecting from the project service to the service and back to the model,
put all destruction code in the service. Also removes a possible source of failure
where run_after_commit may not destroy the project.
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Enable/Disable Deploy keys for a project
Closes #20123
## Does this MR meet the acceptance criteria?
- [X] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [X] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [X] API support added
- Tests
- [X] Added for this feature/bug
- [X] All builds are passing
See merge request !5647
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix Import/Export not working in HA mode
Use a shared path instead of `Tempfile` default `/tmp` so the import file is accessible by any GitLab instance.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/20506
- [x] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- Tests
- [x] All builds are passing
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
See merge request !5618
|
| | |/
| |
| |
| | |
export worker
|
| | |
| |
| |
| | |
So we have raw_diffs too
|
| | |
| |
| | |
This object will manage Gitlab::Git::Compare instances
|
| | |
| |
| | |
Instead calling diff_collection.count use diff_collection.size which is cache on the diff_collection
|
| |/
|
|
| |
Introducing the concept of SafeDiffs which relates
diffs with UI highlighting.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
If somehow a user attempted to accept a merge request that had
conflicts (e.g. the "Accept Merge Request" button or the MR itself was
not updated), `MergeService` did not properly detect that a conflict
occurred. It would assume that the MR went through without any issues
and close the MR as though everything was fine. This could cause
data loss if the source branch were removed.
Closes #20425
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Enable Rubocop cops that check access modifiers
## What does this MR do?
This MR enables Rubocop cops that detect methods that should be restricted but are the part of public API because of access modifiers used improperly.
This also fixes existing offenses.
## Why was this MR needed?
Some method in our codebase are public instead of being private because it is sometimes difficult to get it right without static analysis.
## What are the relevant issue numbers?
See #17478
Closes #17372
See merge request !5014
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1. Instantiate `ProtectedBranchesAccessSelect` from `dispatcher`
2. Use `can?(user, ...)` instead of `user.can?(...)`
3. Add `DOWNTIME` notes to all migrations added in !5081.
4. Add an explicit `down` method for migrations removing the
`developers_can_push` and `developers_can_merge` columns, ensuring that
the columns created (on rollback) have the appropriate defaults.
5. Remove duplicate CHANGELOG entries.
6. Blank lines after guard clauses.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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. This is a third line of defence (first in the view, second in the
controller).
2. Duplicate the `API::Helpers.to_boolean` method in `BaseService`. The
other alternative is to `include API::Helpers`, but this brings with it
a number of other methods that might cause conflicts.
3. Return a 403 if authorization fails.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1. Remove `master_or_greater?` and `developer_or_greater?` in favor of
`max_member_access`, which is a lot nicer.
2. Remove a number of instances of `include Gitlab::Database::MigrationHelpers`
in migrations that don't need this module. Also remove comments where
not necessary.
3. Remove duplicate entry in CHANGELOG.
4. Move `ProtectedBranchAccessSelect` from Coffeescript to ES6.
5. Split the `set_access_levels!` method in two - one each for `merge` and
`push` access levels.
|
| | |
| |
| |
| | |
1. So it works with the new data model for protected branch access levels.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1. Move to dropdowns instead of checkboxes. One each for "Allowed to
Push" and "Allowed to Merge"
2. Refactor the `ProtectedBranches` coffeescript class into
`ProtectedBranchesAccessSelect`.
3. Modify the backend to accept the new parameters.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1. Improve error handling while creating protected branches.
2. Modify coffeescript code so that the "Developers can *" checkboxes
send a '1' or '0' even when using AJAX. This lets us keep the backend
code simpler.
3. Use services for both creating and updating protected branches.
Destruction is taken care of with `dependent: :destroy`
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Submit new issues created via the WebUI or API to Akismet for spam check on public projects.
## What does this MR do?
Submit new issues created via the WebUI by non project members to Akismet for spam check.
## Why was this MR needed?
Support for Akismet was added only to the API with !2266. This MR builds on that functionality to also check issues submitted via the WebUI for spam.
## What are the relevant issue numbers?
Related to:
- #5573
- #5932
- gitlab-com/infrastructure#14
- gitlab-com/support#61
- !2266
cc @stanhu @MrChrisW
See merge request !5333
|
| | | |
| | |
| | |
| | | |
legibility in `SpamCheckService`
|
| | | | |
|
| | | | |
|
| | | | |
|
| |/ / |
|
| | |
| |
| |
| |
| | |
'17073-tagscontroller-index-is-terrible-response-time-goes-up-to-5-…"
This reverts merge request !5375
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Replace invocation of `find` with Ruby code that matches old cached
files in a better, and safe way to avoid data-integrity issues.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Implements the form for renaming the new filename on the file edit page
## What does this MR do?
Adds the possibility to edit a filename when editing the content of a file on Gitlab
this MR was made to solve #5850
See merge request !5049
|
| | |\ \
| | |/ |
|
| | |\ \ |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
