| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
Support empty PG database too
cc @rdavila @axil
See merge request !6221
|
| |
|
|
|
|
|
|
|
|
|
| |
Remove gitorious from import_sources on ApplicationSetting model
Removes 'gitorious' as import field from the import_sources field on ApplicationSetting
Closes #21804
cc @markglenfletcher
See merge request !6180
|
| |
|
|
|
|
|
|
|
|
| |
Scope webhooks/services that will run for confidential issues
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/20661
See merge request !1986
Conflicts:
db/schema.rb
|
| |
|
|
| |
This reverts commit d836a359b7a9eee7dd379a99022e3bb709cd9995.
|
| |
|
|
| |
This reverts commit ff39ccfc3fe12d8974da39cdadae674f28afd0ec.
|
| |
|
|
|
|
|
| |
Remove not-null constraint on lock_version column if it exists
Closes #21678
See merge request !6118
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remove default value for lock_version
From the very beginning we added `lock_version` column with default value, then we reverted that MR. A bit later we added that migration again but column's default value has been removed from migration. So if you installed GitLab form master it's possible that you have default value, which caused the bug.
We don't need to change a CHANGELOG here I think.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/21527 and https://dev.gitlab.org/gitlab/organization/issues/971
See merge request !6111
Conflicts:
db/schema.rb
|
| |
|
|
|
|
|
| |
Call `set_discussion_id` again in DiffNote `before_validation` because the order is important
See merge request !5913
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Koding Integration
## What does this MR do?
Will provide Koding integration with GitLab services. Forked from !4914.
## Are there points in the code the reviewer needs to double check?
I've introduced new layouts which might not be necessary, first time contributor.
## Why was this MR needed?
We're planning to ship Koding with GitLab.
## What are the relevant issue numbers?
#12759 #14698
## Screenshots (if relevant)
### Screencasts
http://recordit.co/BDMbhwgxPD
http://recordit.co/By0qiz1ClC
### Enable Koding in Application Settings
### Koding Dashboard
### Set up Koding Stack
1 - 
2 - 
### Run on Koding on Project Page
### Run in IDE on Merge Requests
## 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] Tests
- [x] Added for this feature/bug
- [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 !5909
|
| |
|
|
|
|
|
| |
Implement pipeline hooks, extracted from !5525
Closes #20115
See merge request !5620
|
| |
|
|
|
|
|
| |
Expiration date on memberships
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/17495
See merge request !5876
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Diff line comments resolve
## What does this MR do?
Diff line comments can be resolved.
Part of #10325
To do:
- [x] Backend (@DouweM)
- [x] Fix https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5022#note_13319326. Will be made easier by https://gitlab.com/gitlab-org/gitlab-ce/issues/17237#note_13370331
- [x] System note when all discussions are resolved
- [x] Notification when all discussions are resolved
- [x] Write unit tests
- [x] Look at resolve time https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5022#note_13912743 - Fixed by 4a13aa9
- [x] Frontend (@iamphill)
- [x] Fix bugs
- [x] Write more feature tests
- [x] Frontend (@connorshea)
- [x] Address frontend feedback
- [x] Feature specs for Jump feature
- [x] Documentation
- [x] Add Vue.js in a standard way
See merge request !5022
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow naming (and deleting) U2F devices.
## What does this MR do?
- Allow giving each U2F device a name (at the time of registration).
- Allow deleting individual U2F devices.
- Display a list of registered U2F devices.
## What are the relevant issue numbers?
- Closes #17334
- Closes #17335
See merge request !5833
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add pipeline graph
## What does this MR do?
Adds pipeline visualization
## What are the relevant issue numbers?
Closes #18141
Part of #19982
## Screenshots (if relevant)
See merge request !5742
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Resolve "Pipelines for merge request"
## What does this MR do?
Adds `Pipelines` tab in merge request view
## What are the relevant issue numbers?
Closes #18681
## Screenshots (if relevant)
See merge request !5485
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Issue boards
- Issue: #17907
- Issue backend: #20335
- Backend MR: !5548
- Frontend MR: !5554
- Documentation !5713
- [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
- [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 !5548
|
| |\
| |
| |
| |
| |
| |
| | |
Submit to Akismet Part 1 (Issues)
Related to #5932 #5573 gitlab-com/infrastructure#14
See merge request !5538
|
| | | |
|
| | |
| |
| |
| | |
- Refactored SpamCheckService into SpamService
|
| | |
| |
| |
| |
| | |
- 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.
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fix pipeline and build seeds in development environment
## What does this MR do?
When we depend on state machine events in seeds, it is likely that we will break fixtures from time to time because when transition rules change, using events most likely invalidates some objects in seeds
## Why was this MR needed?
Pipeline and build seeds were broken in development environment.
## What are the relevant issue numbers?
Closes #20933
See merge request !5810
|
| | |
| |
| |
| |
| |
| | |
When we depend on state machine events in seeds, it is likely that we
will break fixtures from time to time because when transition rules
change, using events most likely invalidates some objects in seeds.
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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();
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add a data migration to fix some missing timestamps in the members table (again)
## What does this MR do?
Repeats an earlier migration to fix historic bad data in the members table (missing created_at and updated_at fields)
## Are there points in the code the reviewer needs to double check?
I'm expecting the WHERE clauses to be fast enough, and to return few enough rows, that the migration doesn't need to use batches, but I'm not too familiar with the size of these tables in the wild, so perhaps that's a poor assumption.
## Why was this MR needed?
8.10 introduced a dependency on the `members.created_at` field in the project and namespace member view. If bad data is present, viewing the list of members now results in an NoMethodError and a 500 response from GitLab. Although the previous migration should have fixed all bad rows, we have evidence that it didn't in at least one case, despite the migration claiming to have run in the past.
## What are the relevant issue numbers?
#20568
## Screenshots (if relevant)
## Does this MR meet the acceptance criteria?
- [ ] [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)
Closes #20568
See merge request !5670
|
| | | |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Migrate protected branch access levels to match constants in `Gitlab::Access`
Closes #20606
Context: https://gitlab.com/gitlab-org/gitlab-ce/issues/20606#note_13561628
See merge request !5658
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- In the final round of review (!5081), we moved the protected branch
access levels from Rails enums to constants from Gitlab::Access.
- The migrations that moved us from the old data model (a single
protected_branches table with developers_can_push and
developers_can_merge flags) to the new one (separate tables for
push_access_levels and merge_access_levels) was not updated.
- These migrations still used 0 to mean "Masters" and 1 to mean
"Developers" (matching the previous Rails enum), while Gitlab::Access
uses 40 and 30 for these, respectively.
- Once the migrations run, our data gets into a broken state.
- We fix this by migrating all `0`s to `40` and all `1`s to `30`.
- https://gitlab.com/gitlab-org/gitlab-ce/issues/20606#note_13561628
= Caveats =
- In Gitlab::Access, 0 represents NO_ACCESS. When we run this migration,
all protected branches with "No one" as an access level will be
changed to "Masters"
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix `#down` for two protected branches-related migrations.
- The migrations called `add_column_with_default` with a `null` option, which the Rails `add_column` method accepts. This fails because `add_column_with_default` expects an `allow_null` option instead.
- The migrations have been fixed to use `allow_null`.
See merge request !5660
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- The migrations called `add_column_with_default` with a `null` option,
which the Rails `add_column` method accepts. This fails because
`add_column_with_default` expects an `allow_null` option instead.
- The migrations have been fixed to use `allow_null`.
|
| |\ \ \
| |_|/
|/| |
| | |
| | |
| | |
| | | |
Improve CI fixtures
cc @ayufan
See merge request !5645
|
| | |/ |
|
| |/
|
|
| |
table
|
| | |
|
| |
|
|
|
| |
This MR adds a string (thus max 255 chars) field to the enviroments
table to expose it later in other features.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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. 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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
| |
[ci skip]
|
