-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add CI check to ensure SO mapping addition are done correctly #172056
Add CI check to ensure SO mapping addition are done correctly #172056
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
self-review
export const runMappingsCompatibilityChecks = async ({ | ||
fix, | ||
verify, | ||
log, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Extracted from packages/kbn-check-mappings-update-cli/src/run_check_mappings_update_cli.ts
const fork = ChildProcess.fork(require.resolve('./extract_field_lists_from_plugins_worker.ts'), { | ||
execArgv: ['--require=@kbn/babel-register/install'], | ||
cwd: REPO_ROOT, | ||
stdio: ['ignore', 'pipe', 'pipe', 'ipc'], | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was wondering why the other check was using a worker, and decided to go without it, and then I understood: starting the server in this awkward state keeps some open handles, forcing the process to never terminate, so we're effectively forced to fork.
I didn't bother factorizing the fork creating code yet. I will probably if/when we need to add a third check.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't bother factorizing the fork creating code yet. I will probably if/when we need to add a third check.
Good choice, 2 instances of the same/ similar code is fine, a third is a pattern.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
starting the server in this awkward state keeps some open handles, forcing the process to never terminate, so we're effectively forced to fork.
We need to add this info somewhere in the package to prevent others from falling into the same trap.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah makes sense, I will add a comment around the place we're invoking the workers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another consideration was controlling log output more easily, but yeah I remember the non-dying process too
if (!task || task === 'mapping-addition') { | ||
log.info('Running model version mapping addition checks'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated the existing package / cli command to run both checks, given it makes more sense to execute everything in a single CI task.
export const runModelVersionMappingAdditionsChecks = async ({ | ||
fix, | ||
verify, | ||
log, | ||
}: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pseudo-code of the new check:
for each plugin:
file_fields = list already checked fields from file
mappings_fields = list fields from mappings
version_fields = list fields from model versions
if file_fields is empty:
// new type addition
update_file(mappings_fields)
return
if any field from mappings_fields not in file_fields and not in version_fields => type error
if any field from version_fields not in file_fields and not in mappings_fields => type error
if any error, fail ci check
if no error, update fields in file for all types
'3': { | ||
changes: [ | ||
{ | ||
type: 'mappings_addition', | ||
addedMappings: { | ||
secrets: { | ||
properties: { | ||
service_token: { | ||
dynamic: false, | ||
properties: { | ||
id: { type: 'keyword' }, | ||
}, | ||
}, | ||
}, | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@elastic/fleet fixing the mapping that was incorrectly added without a model version in #171875
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pgayvallet I wanted to confirm that the cli check detects problems and ran node scripts/check_mappings_update.js --task mapping-addition
locally after removing modelVersion 3
from here.
The check didn't respond with any issues. I'm assuming it should though. Is there some extra flag we need that's not documented well or is something else going on.
FYI: I did bootstrap after removing the model version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Confirmed, the check only detects when the field is removed from current_fields.json
. Is the expectation that mapped fields will never be removed from schema?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, it's "working as intended": because initial mappings (the ones defined when the type gets introduced) are not in any version, and because there's no way of differentiating those mappings from "new" mappings, we're forced to store the processed fields into the list on disk. So once the field is on the file, if you remove it from the version it was added it, the script will not detect it.
I added an override
option (and wired the fix
one) in case we need to manual "reset" the file (e.g a PR adding a new type with fields being added in separate commits)
Is the expectation that mapped fields will never be removed from schema?
Correct, for now it is (as we can't remove them from the actual index's mappings atm anyway)
Pinging @elastic/kibana-core (Team:Core) |
e7ff526
to
d781fd9
Compare
Sorry for the noise everyone :shame: |
💚 Build Succeeded
Metrics [docs]Public APIs missing comments
Unknown metric groupsAPI count
History
To update your PR or re-run it, just comment with: |
Summary
Fix #172055
Add a CI check verifying that any mapping addition (done after a type's initial introduction) correctly defines the added mappings as a
mappings_addition
change in a model version of the owning type (or throws otherwise)Similar to #169610