| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| | |
pipeline-hooks-without-slack
|
| | | |
|
| | |
| |
| |
| |
| | |
- Added controller actions as reusable concerns
- Added controller tests
|
| | |
| |
| |
| |
| | |
- Added `submitted_as_ham` to `SpamLog` to mark which logs have been submitted to Akismet.
- Added routes and controller action.
|
| | |
| |
| |
| |
| |
| |
| | |
- Removed unnecessary column from `SpamLog`
- Moved creation of SpamLogs out of its own service and into SpamCheckService
- Simplified code in SpamCheckService.
- Moved move spam related code into Spammable concern
|
| | |
| |
| |
| |
| |
| | |
- New concern `AkismetSubmittable` to allow issues and other `Spammable` models to be submitted to Akismet.
- New model `UserAgentDetail` to store information needed for Akismet.
- Services needed for their creation and tests.
|
| |\ \
| |/ |
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Show deployment status on a MR view
## What are the relevant issue numbers?
Resolves #19571, one in the list of #19992
## Screenshots (if relevant)
external_url = nil
external_url != nil
Note, the timings are weird between merging and deploying, that is because I did it in the wrong order.
## Does this MR meet the acceptance criteria?
- [X] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
See merge request !5622
|
| | | | |
|
| |\ \ \
| |/ / |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One can see which indexes are used in PostgreSQL by running the
following query:
SELECT relname as table_name, indexrelname as index_name, idx_scan, idx_tup_read, idx_tup_fetch, pg_size_pretty(pg_relation_size(indexrelname::regclass))
FROM pg_stat_all_indexes
WHERE schemaname = 'public'
AND "idx_scan" = 0
ORDER BY pg_relation_size(indexrelname::regclass) desc;
Using this query I built a list of indexes that could be potentially
removed. After checking every single one by hand to make sure they
really aren't used I only found 1 index that _would_ be used. This was a
GitLab GEO index (EE) specific that's currently not used simply because
the table is empty.
Apart from this one index all indexes could be removed. The migration
also takes care of 6 composite indexes that can be replaced with a
single column index, which in most cases was already present.
For more information see gitlab-org/gitlab-ce#20767.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
These indexes are only used when you search for runners in the admin
interface. This operation is so rarely used that it does not make sense
to slow down every update in order to update the GIN trigram indexes.
Removing these indexes should speed up queries such as those used for
updating the last contact time of CI runners. Locally the timings of
this query were reduced from ~50 ms to ~25 ms:
UPDATE ci_runners SET updated_at = now(), contacted_at = now();
|
| | |
|
| |
|
|
| |
table
|
| | |
|
| |
|
|
|
| |
This MR adds a string (thus max 255 chars) field to the enviroments
table to expose it later in other features.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
branch access levels.
1. Remove the `developers_can_push` and `developers_can_merge` boolean
columns.
2. Add two new tables, `protected_branches_push_access`, and
`protected_branches_merge_access`. Each row of these 'access' tables is
linked to a protected branch, and uses a `access_level` column to
figure out settings for the protected branch.
3. The `access_level` column is intended to be used with rails' `enum`,
with `:masters` at index 0 and `:developers` at index 1.
4. Doing it this way has a few advantages:
- Cleaner path to planned EE features where a protected branch is
accessible only by certain users or groups.
- Rails' `enum` doesn't allow a declaration like this due to the
duplicates. This approach doesn't have this problem.
enum can_be_pushed_by: [:masters, :developers]
enum can_be_merged_by: [:masters, :developers]
|
| | |
|
| |\ |
|
| | |
| |
| |
| | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |\
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Added the ability to block sign ups using a domain blacklist.
As part of this MR, I restructured the Application Settings form to separate **Sign up** related settings from **Sign in** related settings and make everything cleaner and easier to read.
Fixes #19749
Related to #5573
See merge request !5259
|
| | | |
| | |
| | |
| | | |
better conform to its behavior and newly introduced behavior.
|
| | | | |
|
| | | | |
|
| |\ \ \
| |/ / |
|
| | |/
| |
| |
| |
| |
| |
| |
| | |
* This method previously iterated over all services in a project. Now it
will directly query the ExternalWikiService for the project and filter
by active state.
* The presence of an external wiki is also cached
* When an external wiki is added or removed, the cached value is updated
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Revert "Revert "Merge branch '18193-developers-can-merge' into 'master'""
## What does this MR do?
Reverts the revert of !4892 which lacked an EE MR at the time. This has been done in gitlab-org/gitlab-ee!564.
## What are the relevant issue numbers?
Closes #19872.
See merge request !5310
|
| | |
| |
| |
| |
| |
| |
| | |
- This was introduced (at some point) while rebasing `master` against
the "developers can merge" feature branch.
- https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5310#note_13139705
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 530f5158e297f3cde27f3566cfe13bad74ba3b50.
See !4892.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
store-variables-and-when-in-builds-table
# Conflicts:
# db/schema.rb
|
| | |\ \
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Track a user who creates a Pipeline
## What does this MR do?
This adds additional column to pipelines to track user who is creating pipelines.
## Why was this MR needed?
This is to make it possible to show all pipelines created by specific user and to later solve: https://gitlab.com/gitlab-org/gitlab-ce/issues/18054
## What are the relevant issue numbers?
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/18992
- [ ] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG) entry added
- [ ] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [ ] API support added
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] 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 !5272
|
| | | | |
|
| | | | |
|
| | |/
| |
| |
| | |
This reverts commit c39356998b1850f3dc26fe0b987cb419c1d1afb4.
|
| |/ |
|
| |
|
|
|
| |
This reverts commit 9ca633eb4c62231e4ddff5466c723cf8e2bdb25d, reversing
changes made to fb229bbf7970ba908962b837b270adf56f14098f.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
| |
- Cherry-picked from `mvestergaard:branch-protection-dev-merge`
- https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4220
|
| | |
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Added setting to set new users by default as external
## What does this MR do?
This implements the feature request #14508. It adds an option in the application settings to set new users by default as external.
## Are there points in the code the reviewer needs to double check?
Everything. Like I mentioned in the discussion of the issue my knowledge of Ruby basically doesn't exists. I tested it on my machine and it seems to work, but as I am very unexperienced in Ruby I highly recommend to take a close look at the code.
## Why was this MR needed?
It was requested by @DouweM to work on the issue with the proposed changes by me.
## What are the relevant issue numbers?
This MR is for the issue #14508 that followed up after the implementation of #4009.
See merge request !4545
|
