Conversation
There was a problem hiding this comment.
Pull request overview
Updates repository documentation to better explain the repo’s purpose/structure and adds a reference page documenting Grafana dashboard locations and conventions.
Changes:
- Refresh
README.mdto describe the repo and provide an updated directory layout. - Add new reference doc for Grafana dashboards and link it from the reference index.
- Update
docs/reference/index.rstto include the new reference page in the toctree.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
README.md |
Replaces WIP README content with a purpose statement, updated repo layout, and pointer to docs/. |
docs/reference/index.rst |
Adds grafana-dashboards to the reference toctree. |
docs/reference/grafana-dashboards.md |
New reference page describing dashboard directories and JSON conventions. |
| ## Further information | ||
|
|
||
| Dashboard JSON files should use `__inputs` to declare the datasource (type `prometheus`). | ||
| Setting `"editable": false` is recommended for clarity, but is not strictly required: | ||
| dashboards delivered through `cos-configuration-k8s` are filesystem-provisioned and | ||
| therefore read-only in Grafana regardless of the JSON flag. Metric names follow the | ||
| [OpenTelemetry hostmetrics receiver](https://opentelemetry.io/docs/collector/components/#receiver) | ||
| Prometheus naming convention (e.g. `system_cpu_time_seconds_total`). | ||
| Further information can be found in the `docs/` directory. |
There was a problem hiding this comment.
A new doc page is being added under docs/reference/, but docs/changelog.md wasn’t updated. Please add a short changelog entry noting the new reference page so documentation consumers can track user-facing doc changes.
There was a problem hiding this comment.
the changelog currently only refers to planner and webhook-gateway charm. should we change the changelog to reflect everything user-facing in this repo? @erinecon
There was a problem hiding this comment.
Yes, I think so -- the changelog should cover everything relevant to users
| JSON files from this Git repository and provisions them via the `grafana-dashboard` | ||
| relation. Provisioned dashboards are **immutable** in Grafana regardless of user | ||
| role — they cannot be edited or deleted through the UI. | ||
| docs/ # Documentation |
There was a problem hiding this comment.
I have removed this, because I do not think we should mention deployment details here.
erinecon
left a comment
There was a problem hiding this comment.
Thanks for updating the README!
| ## Further information | ||
|
|
||
| Dashboard JSON files should use `__inputs` to declare the datasource (type `prometheus`). | ||
| Setting `"editable": false` is recommended for clarity, but is not strictly required: | ||
| dashboards delivered through `cos-configuration-k8s` are filesystem-provisioned and | ||
| therefore read-only in Grafana regardless of the JSON flag. Metric names follow the | ||
| [OpenTelemetry hostmetrics receiver](https://opentelemetry.io/docs/collector/components/#receiver) | ||
| Prometheus naming convention (e.g. `system_cpu_time_seconds_total`). | ||
| Further information can be found in the `docs/` directory. |
There was a problem hiding this comment.
Yes, I think so -- the changelog should cover everything relevant to users
There was a problem hiding this comment.
WDYT about adding a link to the RTD site somewhere in the README, or a dedicated section about the documentation? Currently we use this template section for most of our repos with RTD projects:
## Documentation
Our documentation is stored in the `docs` directory.
It is based on the Canonical starter pack
and hosted on [Read the Docs](LINK TO RTD). In structuring,
the documentation employs the [Diátaxis](https://diataxis.fr/) approach.
You may open a pull request with your documentation changes, or you can
[file a bug](LINK TO ISSUES) to provide constructive feedback or suggestions.
To run the documentation locally before submitting your changes:
```bash
cd docs
make run
```
GitHub runs automatic checks on the documentation
to verify spelling, validate links and style guide compliance.
You can (and should) run the same checks locally:
```bash
make spelling
make linkcheck
make vale
make lint-md
```
| charms/ | ||
| planner-operator/ # Juju charm: GitHub runner planner | ||
| cos_custom/ | ||
| grafana_dashboards/ # Grafana dashboards for the planner charm | ||
| # (served via cos-configuration-k8s, path: charms/planner-operator/cos_custom/grafana_dashboards) | ||
| webhook-gateway-operator/ # Juju charm: GitHub webhook gateway |
There was a problem hiding this comment.
Do you think the README should provide any descriptions or high-level overview of the roles/responsibilities fulfilled by the charms? I think that the layout block is already clear about the structure, but consider adding a new section after the layout (maybe something like ## Charms or ## Repository charms) with some brief details about the purpose of the charms.
| webhook-gateway/ # Application entry point: webhook gateway | ||
|
|
||
| ## Observability: Grafana dashboards | ||
| internal/ # Shared Go packages |
There was a problem hiding this comment.
I ran the README draft through Gemini and asked for feedback about how digestable the README is for LLMs. Gemini said that it's not clear what the internal folder actually holds -- what kind of logic exists in this folder? Perhaps clarifying the purpose in this block may help, something like:
| internal/ # Shared Go packages | |
| internal/ # Shared Go packages to <fulfill this specific purpose> |
That way you don't need to provide more details or an explicit section
What this PR does
Update the README with purpose and structure of the repo, and move Grafana dashboard conventions to a new reference doc page.
Why we need it
The README is not providing a lot of information and is still marking the repo as WIP, though the charms are already used in production.
Checklist
CONTRIBUTING.mdhas been updated upon changes to the contribution/development process (e.g. changes to the way tests are run)docs/changelog.mdwith user-relevant changes(e.g., in
.github/workflows/integration_tests.yaml, ensure themoduleslist is correct)terraform fmtpasses andtflintreports no errors