chaoss / chaoss/grimoirelab-tutorial
Custom fields
- Dominant language
- Ruby
- Stars
- 30
- Forks
- 68
- PR merge metrics
- No merged PRs in 30d
Description
Just wanted to save this explanation. Not sure of where in the tutorial to insert it:
> The fields in GrimoireLab come to be through different paths:
>
> - Most are just retrieved from the data sources. We call this data raw data.
> - The enrichment process that runs after the data load (usually called by Morderd for similar) adds more standard-calculated fields. We call this data enriched data.
> - Then, the user can inject fields via configuration (instead of retrieving them directly or indirectly from the sources). We can call these configuration-injected fields "_tags_".
>
> Currently, all tags are defined via the `project.json` file).
>
> Some tags have standard field names. The user only injects their arbitrary values.
> Some other tags are user-defined fields. The user injects both their values and the name of these fields.
>
> Grimoirelab can inject user-defined data through at least 3 paths:
> - The `project` field. It holds the name of the projects. Their values (project names) and their applicabilities (which data source belongs to each project) are defined in the `projects.json` file.
> - The `meta` member of each project (set in the `projects.json file`).
> - It generates the `cm_*` fields we find in every item retrieved from sources (commits, issues, PRs, repos, areas_of_code, ...) attributed to that **project**.
> - All these project-level custom fields are marked with a `cm_` appendix. So, if you ask for a `my_tag` field in the `meta` member of a project you get a `cm_my_tag` field.
> - A standard field called `labels`.
> - It is a list of values.
> - We can inject a user-defined list of values per **repository**.
> - This, again, propagates to many items retrieved from sources (commits, issues, PRs, repos, areas_of_code, ...) attributed to that **repository**.
Contributor guide
Assessment
This issue has not been assessed yet.