[QA][Code Coverage] Change location of Team Assignment Definition

[wayneseymour]

Move the json def to easier location, such that devs can easily find it, change it and include those
changes in their PR's.

[wayneseymour]

Testing: https://kibana-ci.elastic.co/job/elastic+kibana+qa-research/46/

[LeeDr]

I'm thinking we should also rename it while we're at it. ingestion_pipeline_painless.json doesn't really make it clear what it is. Could we rename it to something like code_coverage_team_assignment.json ?

[wayneseymour]

Yes sir!

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 11bf155

Build metrics

✅ unchanged

History

• 💚 Build #62425 succeeded fa0470d

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[LeeDr]

LGTM - Please check with operations team to make sure they don't have a problem with files at the root level. But I like it in the easiest to find place as possible.

[spalger]

such that devs can easily find it, change it and include those changes in their PR's

I don't think the location of this file is the right issue to fix. I really don't want another file at the root of the repo and this file specifically feels like it should be auto-generated from something like the codeowners file and be fixed to not be a massive json encoded string that nobody could possibly read or modify correctly without careful find-replace or knowing how to properly "de-compress" and "re-compress".

[wayneseymour]

such that devs can easily find it, change it and include those changes in their PR's

I don't think the location of this file is the right issue to fix. I really don't want another file at the root of the repo and this file specifically feels like it should be auto-generated from something like the codeowners file and be fixed to not be a massive json encoded string that nobody could possibly read or modify correctly without careful find-replace or knowing how to properly "de-compress" and "re-compress".

Yeah I concur. The process is to use the Kibana Dev Tools to edit it, then use the auto indent to one-line it. Maybe we should expose the code that does the formatting. Kinda looks like its tied to the Ace Editor though

[wayneseymour]

@spalger yeah I totally agree about the auto-gen from codeowners. I actually started coding that like 3 - 4 months ago but I scrapped it. We'd still have to expose the formatting code, imho.

[spalger]

The way we handle this for things like the renovate config is there is a module which generates the renovate config, commit the output of that script to the repo, and then validate that the generated output is up-to-date in CI. When the output does end up being out of date CI "educates" people about what they should do. Do you think we could implement something similar to that for this config file? I don't think adding it to the root of the repo is going to accomplish anything other than creating more clutter personally.

[wayneseymour]

@spalger oh totally down to not have it in the root.

Maybe we should go ahead and gen from code owners, but not sure how we'd validate or even update, via http. The reason I put in the src code a one-liner is that it fails to HTTP PUT when it's in the half-json format

[spalger]

Well, the idea would be that we'd use codeowners, or some other readable, maintainable, config format and then generate the painless script from that config. Then we would still have the painless script that's compatible with the ES API but would have a maintainable file that contributors can help maintain. If we can't use codeowners as the "readable, maintainable, config format" then maybe whatever we use instead could also generate the codeowners file...

CI would be used to make sure the config file and the generated painless script are in sync.

[wayneseymour]

ahhh, I think I'm starting to track what ya mean. You know it's Friday so my brain is lazy.
I do like that.

[wayneseymour]

@spalger I'll follow up with my boss write an issue on this. That way, we can track the what, why and how :)