os.getcwd() is not the charm root in ops[testing]

[tonyandrewmeyer]

When running in Juju, the current directory is the charm root at the start of a hook. When running in Scenario, the current directory is typically the root directory of the repository.

This hockeypuck-k8s branch has examples of where this fails in a paas-charm.

• test_scenario fails because we don't support charmcraft extensions in autoload
• test_scenario_one needs to have the context created as Context(HockeypuckK8SCharm, meta=METADATA, actions=METADATA['actions']) because you can't pass all of charmcraft.yaml in the 'meta' argument
• test_scenario_three needs to have all of the actions provided in the metadata, because otherwise charm.on won't have them all.
• test_scenario_two (and test_scenario_one and test_scenario_three once the above issues are fixed) fail because they cannot load the config.

paas_charm loads the config.yaml file directly rather than using .config (or the newer .load_config, which would provide the "load a secret as a secret" functionality that they're also implementing). This fails under Scenario because it looks for config.yaml in the current directory, but Scenario carefully creates a temporary directory for executing the tests. For most charms, this would still work (if it fell back to charmcraft.yaml), because the YAML is just copied, but in this case the YAML is being explicitly provided because of the lack of extension support.

(I think there is some other issue with the tests, because some of them end up with UnknownStatus rather than the expected BlockedStatus, but I don't think that's an issue with Scenario).

A simple os.chdir() (and restoring the value after the yield) in _runtime.py fixed this for me locally, and should probably be a simple and safe fix, I think. It would be nicer if the charms didn't directly access the metadata files but it probably is reasonable that they do. The paas_charm code would be better if it used Framework's charm_dir rather than relying on getcwd(), but I think it is also reasonable to expect the initial working directory to be the charm dir.

[james-garner-canonical]

I wonder if we should reconsider this. It's timely given the proposed performance related changes in #2361. If we add some friction to charms accessing the files in their charm root during testing, it would encourage better practices in production. But maybe we should have some sort of explicit opt-in for 'create me a directory, copy everything there, and change the working directory. See also #1673