Age | Commit message (Collapse) | Author |
|
|
|
We had concerns about the cached values on Redis with the previous two
releases strategy:
First release (this commit):
- Create new encrypted fields in the database.
- Start populating new encrypted fields, read the encrypted fields or
fallback to the plaintext fields.
- Backfill the data removing the plaintext fields to the encrypted
fields.
Second release:
- Remove the virtual attribute (created in step 2).
- Drop plaintext columns from the database (empty columns after
step 3).
We end up with a better strategy only using migration scripts in one
release:
- Pre-deployment migration: Add columns required for storing encrypted
values.
- Pre-deployment migration: Store the encrypted values in the new
columns.
- Post-deployment migration: Remove the old unencrypted columns
|
|
This is the plan to encrypt the plaintext tokens:
First release (this commit):
1. Create new encrypted fields in the database.
2. Start populating new encrypted fields, read the encrypted fields or
fallback to the plaintext fields.
3. Backfill the data removing the plaintext fields to the encrypted fields.
Second release:
4. Remove the virtual attribute (created in step 2).
5. Drop plaintext columns from the database (empty columns after step 3).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- A regular migration caused problems such as
https://gitlab.com/charts/gitlab/issues/1565.
|
|
The Sidekiq job `RemoveExpiredMembersWorker` was failing to run in
production because it was hitting statement timeouts because it was
scanning all rows in order. On staging, where it used to scan 4 million
rows, adding an index brought this down to only a few hundred rows.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/67286
|
|
Enable serving static objects from an external storage
See merge request gitlab-org/gitlab-ce!31025
|
|
Notes on epics promoted from an issue used to get same discussion_id
as the notes from the issue the epic was promoted from, which would
cause problems when trying to reply to the epic discussion.
|
|
Optimize /admin/applications so that it does not timeout
Closes #67228
See merge request gitlab-org/gitlab-ce!32852
|
|
This fixes previously added migration which caused timeouts on
big events table.
|
|
It consists of two parts:
1. Redirecting users to the configured external storage
1. Allowing the external storage to request the static object(s)
on behalf of the user by means of specific tokens
Part of https://gitlab.com/gitlab-com/gl-infra/infrastructure/issues/6829
|
|
On our dev instance, /admin/applications as not loading because:
1. There was an unindexed query by `application_id`.
2. There was an expensive query that attempted to load 1 million
unique entries via ActiveRecord just to find the unique count.
We fix the first issue by adding an index for that column.
We fix the second issue with a simple SELECT COUNT(DISTINCT
resource_owner_id) SQL query.
In addition, we add pagination to avoid loading more than 20
applications at once.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/67228
|
|
Make epic_issues relative_position migration more robust
Closes #66923
See merge request gitlab-org/gitlab-ce!32646
|
|
Port CreateGithubPullRequestEvents migration from EE
See merge request gitlab-org/gitlab-ce!31802
|
|
Detect if pipeline runs for a GitHub pull request
When using a mirror for CI/CD only we register a pull_request
webhook. When a pull_request webhook is received, if the
source branch SHA matches the actual head of the branch in the
repository we create immediately a new pipeline for the
external pull request. Otherwise we store the
pull request info for when the push webhook is received.
When using "only/except: external_pull_requests" we can detect
if the pipeline has a open pull request on GitHub and create or
not the job based on that.
|
|
Since it is not possible to dynamically detect if a job is automatically
cancellable or not, a this new attribute is necessary. Moreover, it let
the maintainer of the repo to adjust the behaviour of the auto cancellation
feature to match exactly what he needs.
|
|
These are the structural changes for supporting the EE feature of moving
"code_owner_approval_required" state from existing on a project to being
on the protected branches individually, allowing for CODEOWNER
validation on push events.
|
|
Create index for users.unconfirmed_email
See merge request gitlab-org/gitlab-ce!32664
|
|
This speeds up the following query:
```sql
SELECT users.* FROM users WHERE users.unconfirmed_email = ? ORDER BY
users.id ASC LIMIT 1
```
Presumably, this is a query coming from Devise.
Context is https://gitlab.com/gitlab-org/gitlab-ce/issues/66958.
|
|
If someone installed EE, then downgraded to CE before this column was
added, upgrading to the latest version of CE will fail:
1. We have a backport migration for the entire EE schema but the table
`epic_issues` exists, just not the `relative_position` column.
2. The migration that changes the default (quite reasonably) didn't
check if the column exists.
If the column doesn't exist, we can just create it with the correct
default.
|
|
This creates a partial index intended to speed up queries on
`ci_builds`. Particularly, `gitlab-monitor` has rather heavy queries.
Those have been changed to only look back 7 days and benefit from this
index tremendously.
Relates to
https://gitlab.com/gitlab-org/gitlab-exporter/merge_requests/101.
|
|
Creates new event when an epic is created, closed, reopened or
commented.
|
|
Remove Users.support_bot column
See merge request gitlab-org/gitlab-ce!32554
|
|
|
|
Modified schema via migrations.
Added one-to-one relationship between the two models.
Added changelog file
|
|
|
|
This column is not present in `db/schema.rb` and hence needs to be
removed conditionally.
See https://gitlab.com/gitlab-org/gitlab-ce/issues/66901 for background
|
|
This adjusts the partial condition for an index. The index is intended
to be used when counting active users with `ghost IS NOT TRUE AND
bot_type IS NULL`.
With the current index, this wasn't working as the partial condition
didn't match the query: `ghost <> TRUE` is not semantically equivalent
to `ghost IS NOT TRUE` (null semantics).
The reason we add an index particularly intended for EE is that the EE
query is going to have the additional part `AND bot_type IS NULL`
whereas the CE query doesn't. Logically, it'd be enough to have an index
for `ghost IS NOT TRUE`. However, on GitLab.com, the query planner makes
poor choices when the additional `AND bot_type IS NULL` part is present:
It goes for the index on `bot_type` and doesn't use the partial index.
Note the existing index isn't being used at all according to GitLab.com
index statistics. Hence we can first remove it and don't have to worry
about the window of time without an index.
Relates to https://gitlab.com/gitlab-org/gitlab-ce/issues/66770
|
|
Since migrations are not run by new instances, add a production
fixture that should ensure that the self-monitoring project is created
for new instances as well.
|
|
Rename epic column state to state_id to be consistent with
issues and merge requests
|
|
|
|
|
|
Use image proxy to mitigate stealing ip addresses
Closes #2812
See merge request gitlab/gitlabhq!2926
|