Add schema_version to main index mapping
What does this MR do and why?
Related to #214601 (closed)
Adding schema_version
to index mapping for the main index (contains, project, wiki_blobs, and blob document types).
Note: We would like to have a schema_version
field available for future migrations in all document types.
This is prep work to be able to easily backfill traversal_ids
for projects which will be needed for the IndexIntegrityWorker
. The IndexIntegrityWorker
(dev in progress) will need to pull all projects for a root namespace and I need the traversal_ids
field populated for that. Currently it's only being populated for blobs and wiki_blobs.
Screenshots or screen recordings
N/A
How to set up and validate locally
prerequisites
setup Elasticsearch in gdk
config.rb
changes
check - create an index from scratch:
bundle exec rake gitlab:elastic:index
- verify the new mapping is there and has data (tests the
config.rb
changes) GET http://localhost:9200/gitlab-development/_search
{
"query": {
"bool": {
"must": [
{
"term": {
"type": {
"value": "project"
}
}
}
]
}
}
}
migration changes
- checkout the master branch
- recreate the indexes from scratch :
bundle exec rake gitlab:elastic:index
- add a new project
- verify that it doesn't throw an error and indexes properly (without the new field)
- stop rails-background-jobs to prevent it from running the migration automatically:
gdk stop rails-background-jobs
- start rails console
- run the migration in the rails console
- verify that the
schema_version
field exists in the mappings: GEThttp://localhost:9200/gitlab-development/_mappings
- add a new or update an existing project and run the indexing manually:
Elastic::ProcessBookkeepingService.new.execute
- verify that the
schema_version
field exists and is populated for the project in the search response GET http://localhost:9200/gitlab-development/_search
{
"query": {
"bool": {
"must": [
{
"term": {
"type": {
"value": "project"
}
}
}
]
}
}
}
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Merge request reports
Activity
changed milestone to %15.9
assigned to @terrichu
- A deleted user
added backend label
1 Warning featureaddition and featureenhancement merge requests normally have a documentation change. Consider adding a documentation update or confirming the documentation plan with the Technical Writer counterpart.
For more information, see:
- The Handbook page on merge request types.
- The definition of done documentation.
Reviewer roulette
Changes that require review have been detected!
Please refer to the table below for assigning reviewers and maintainers suggested by Danger in the specified category:
Category Reviewer Maintainer backend Eduardo Bonet (
@eduardobonet
) (UTC+1, 6 hours ahead of@terrichu
)Kamil Trzciński (
@ayufan
) (UTC+1, 6 hours ahead of@terrichu
)To spread load more evenly across eligible reviewers, Danger has picked a candidate for each review slot, based on their timezone. Feel free to override these selections if you think someone else would be better-suited or use the GitLab Review Workload Dashboard to find other available reviewers.
To read more on how to use the reviewer roulette, please take a look at the Engineering workflow and code review guidelines. Please consider assigning a reviewer or maintainer who is a domain expert in the area of the merge request.
Once you've decided who will review this merge request, assign them as a reviewer! Danger does not automatically notify them for you.
If needed, you can retry the
danger-review
job that generated this comment.Generated by
Dangerremoved backend label
marked the checklist item I have evaluated the MR acceptance checklist for this MR. as completed
- Resolved by Dmitry Gruzd
@rkumar555 would you mind an initial backend review? if everything looks good, can you send to
@dgruzd
for maintainer review?
requested review from @rkumar555
added workflowin review label and removed workflowin dev label
- A deleted user
added backend label
- Resolved by Dmitry Gruzd
- Resolved by Dmitry Gruzd
requested review from @dgruzd
@dgruzd
, thanks for approving this merge request.This is the first time the merge request is approved. To ensure full test coverage, a new pipeline will be started shortly.
For more info, please refer to the following links:
added pipeline:mr-approved label
enabled an automatic merge when the pipeline for df7b00f0 succeeds
mentioned in commit 566882df
added workflowstaging-canary label and removed workflowin review label
added workflowcanary label and removed workflowstaging-canary label
added workflowstaging label and removed workflowcanary label
added workflowproduction label and removed workflowstaging label
added workflowpost-deploy-db-staging label and removed workflowproduction label
added workflowpost-deploy-db-production label and removed workflowpost-deploy-db-staging label
added releasedcandidate label
mentioned in merge request kubitus-project/kubitus-installer!1922 (merged)
mentioned in issue #384597 (closed)
added releasedpublished label and removed releasedcandidate label