Add sharding_key for ci_pipelines
What does this MR do and why?
Add sharding_key for ci_pipelines
Now that we have not-null constraint on project id
We can add corresponding sharding key
See previous issue for database finalization:
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
Before | After |
---|---|
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
Related to #458486 (closed)
Merge request reports
Activity
changed milestone to %17.4
assigned to @mfanGitLab
added pipelinetier-1 label
- A deleted user
added database databasereview pending labels
1 Message This merge request adds or changes files that require a review from the Database team. This merge request requires a database review. To make sure these changes are reviewed, take the following steps:
- Ensure the merge request has database and databasereview pending labels. If the merge request modifies database files, Danger will do this for you.
- Prepare your MR for database review according to the docs.
- Assign and mention the database reviewer suggested by Reviewer Roulette.
The following files require a review from the Database team:
db/docs/ci_pipelines.yml
Reviewer roulette
Category Reviewer Maintainer database @j.seto
(UTC-4)
@Andyschoenen
(UTC+2)
Please refer to documentation page for guidance on how you can benefit from the Reviewer Roulette, or use the GitLab Review Workload Dashboard to find other available reviewers.
If needed, you can retry the
danger-review
job that generated this comment.Generated by
DangerHi @terrichu can you help with the database review for this?
@mfanGitLab I think this needs to wait until the post deployment migration from !162638 (merged) is completed. There is a workflowpost-deploy-db-production label that would be assigned to the MR and it only says staging
@terrichu ah that makes sense. Thank you! I'll ping you here once that's updated
I think it'll be more efficient for me to do the first database approval now. You can assign it to a maintainer once that tag is applied, wdyt?
Interesting the label has not been updated on the MR even though the migration ran on production
@morefice The related MR is for ci_pipelines.
How do you know the migration ran? Prior to the MR, the table already has both check_constraints under the table definition.
I thought the
validate_not_null_constraint :ci_pipelines, :project_id
was mainly for SM users as gitlab.com is already validated byprepare_async_check_constraint_validation
Closing this MR as we set the sharding key in !162823 (merged) as it was needed for other tables
requested review from @terrichu
added databasereviewed label and removed databasereview pending label
removed review request for @terrichu
added pipeline:mr-approved label
added pipelinetier-2 label and removed pipelinetier-1 label
Before you set this MR to auto-merge
This merge request will progress on pipeline tiers until it reaches the last tier: pipelinetier-3. We will trigger a new pipeline for each transition to a higher tier.
Before you set this MR to auto-merge, please check the following:
- You are the last maintainer of this merge request
- The latest pipeline for this merge request is pipelinetier-3 (You can find which tier it is in the pipeline name)
- This pipeline is recent enough (created in the last 8 hours)
If all the criteria above apply, please set auto-merge for this merge request.
See pipeline tiers and merging a merge request for more details.
E2E Test Result Summary
allure-report-publisher
generated test report!e2e-test-on-gdk:
test report for ba4cde0aexpand test summary
+------------------------------------------------------------------+ | suites summary | +-------------+--------+--------+---------+-------+-------+--------+ | | passed | failed | skipped | flaky | total | result | +-------------+--------+--------+---------+-------+-------+--------+ | Create | 128 | 0 | 15 | 0 | 143 | ✅ | | Plan | 70 | 0 | 0 | 0 | 70 | ✅ | | Data Stores | 31 | 0 | 1 | 0 | 32 | ✅ | | Release | 5 | 0 | 0 | 0 | 5 | ✅ | | Analytics | 2 | 0 | 0 | 0 | 2 | ✅ | | Govern | 71 | 0 | 0 | 0 | 71 | ✅ | | Package | 20 | 0 | 12 | 0 | 32 | ✅ | | Verify | 44 | 0 | 2 | 0 | 46 | ✅ | | Fulfillment | 2 | 0 | 0 | 0 | 2 | ✅ | | Manage | 1 | 0 | 1 | 0 | 2 | ✅ | | Monitor | 8 | 0 | 0 | 0 | 8 | ✅ | | Secure | 3 | 0 | 0 | 0 | 3 | ✅ | +-------------+--------+--------+---------+-------+-------+--------+ | Total | 385 | 0 | 31 | 0 | 416 | ✅ | +-------------+--------+--------+---------+-------+-------+--------+
mentioned in merge request !162823 (merged)
Hello @mfanGitLab
The database team is looking for ways to improve the database review process and we would love your help!
If you'd be open to someone on the database team reaching out to you for a chat, or if you'd like to leave some feedback asynchronously, just post a reply to this comment mentioning:
@gitlab-org/database-team
And someone will be by shortly!
Thanks for your help!
This message was generated automatically. You're welcome to improve it.