canonical / canonical/operator
[feat] scenario: make a more complete copy of the charm's root
- Dominant language
- Python
- Stars
- 267
- Forks
- 136
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 28
Description
My charm's src directory looks like this:
```
src
├── charm.py
├── config.py
├── grafana_dashboards
│ └── overview-dashboard.json
├── loki_alert_rules
└── prometheus_alert_rules
├── otelcol_exporter.rules
├── otelcol_hardware.rules
└── otelcol_receiver.rules
```
Scenario: The charm works as expected, so I write my first scenario test and it fails 😢.
```
scenario.errors.UncaughtCharmError: Uncaught exception () in operator/charm code: FileNotFoundError(2, 'No such file or directory')
```
I realize I can solve this by adding an extra LOC in charm.py to create the dirs with `src_path.mkdir(parents=True, exist_ok=True)`. As a charm author I realize that adding code to the charm to make tests pass is bad practice. From the ops-scenario docs, I found that I can [create the virtual charm root](https://github.com/canonical/ops-scenario?tab=readme-ov-file#the-virtual-charm-root), like this:
```python
@pytest.fixture(scope="function")
def context(otelcol_charm, tmp_path):
src_dirs = ["grafana_dashboards", "loki_alert_rules", "prometheus_alert_rules"]
for src_dir in src_dirs:
path_to_create = tmp_path / "src" / src_dir
path_to_create.mkdir(parents=True, exist_ok=True)
return Context(charm_type=otelcol_charm, charm_root=tmp_path)
```
All works and I feel more professional, but this makes me question whether ops-scenario should attempt to obtain this virtual charm root automatically. It can be quite the time sink solving this without guidance since the solution is not evident.
Little birdy told me that it would require this code `scenario._runtime.Runtime._virtual_charm_root` to have its functionality updated to make this happen. This would avoid having to create the virtual charm root as a workaround.
ping @PietroPasotti
Contributor guide
Assessment
This issue has not been assessed yet.