docs: add charm-user in the charmcraft.yaml file reference
#2195
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
tonyandrewmeyer
force-pushed
the
charm-user-doc
branch
from
e05fb3a to
642073b
Compare
tonyandrewmeyer
force-pushed
the
charm-user-doc
branch
from
642073b to
0e10845
Compare
tonyandrewmeyer
changed the title
charm-user in the charmcraft.yaml file referencecharm-user in the charmcraft.yaml file reference
tonyandrewmeyer
added a commit
to canonical/operator
that referenced
this pull request
Mar 3, 2025
Exposes the `charm-user` field in `CharmMeta`. The field is added as a string (with type annotations providing the three possible values) rather than an enum. We have a mixture in the other meta fields - `RelationRole` is an enum, but `ResourceMeta.type` is a string and `StorageMeta.type` is a string. It seems like `charm-user` can go with the simpler form - and it's also easier to add an enum later than it is to remove one. Like most of the rest of the meta loading, there's also no validation (that it's one of the three possible values) - it seems reasonable to assume that if there's some other value in a production environment that's a `charmcraft` bug (or there's a new type we don't handle yet) and in development `charmcraft` will raise the problem when packing. See also the [charmcraft docs](https://canonical-charmcraft.readthedocs-hosted.com/en/stable/reference/files/metadata-yaml-file/#charm-user) (and a [PR to fix it being missing from charmcraft.yaml reference](canonical/charmcraft#2195)). Fixes #1396
lengau
approved these changes
Mar 4, 2025
Collaborator
lengau
left a comment
lengau
left a comment
There was a problem hiding this comment.
Thanks! Could you do me a favour and add this key to one of the charmcraft YAML files under the basic smoke tests? I just looked and it doesn't seem like we're actually e2e testing this anywhere.
medubelko
reviewed
Mar 4, 2025
Contributor
Author
Done, assuming that adding the key is all that's required. |
Some specific fixes to the Django tutorial: * Don't need to explicitly have `python3 manage.py`. Django developers are more used to `./manage.py` instead. I have updated the tutorial and `task.yaml` file. * Any reference to `/django-hello-world` in text has been updated to `~/django-hello-world`. * Updated indentation in a code snippet that was rendering incorrectly. Additional reviewers: @jdkandersson
This PR is related to 12 Factor [SMTP PR](canonical/paas-charm#32). ## Rationale Some applications require an SMTP integration to send emails to their clients. This PR is a follow-up to the latest [12 Factor PR](canonical/paas-charm#32) for adding SMTP integration. ## Changes - Add commented-out SMTP relation required objects to extension charmcraft.yaml.j2 files. - Add references about SMTP into extension reference documents. - Add documentation about SMTP integration and generated environment variables - Add the smtp charm lib to the initializer. Reviewers: @jdkandersson @javierdelapuente @erinecon --------- Co-authored-by: Erin Conley <[email protected]>
tonyandrewmeyer
force-pushed
the
charm-user-doc
branch
from
ea10d9c to
4ebfa67
Compare
Contributor
Author
|
I'm not sure of the conventions here - do I need to squash all the commits, and/or rebase? Or will you do that as part of the merge? Let me know if I need to do more. |
Contributor
|
@tonyandrewmeyer We'll squash on merge. |
medubelko
approved these changes
Mar 5, 2025
erinecon
added a commit
to erinecon/charmcraft
that referenced
this pull request
Mar 10, 2025
…al#2195) The `charm-user` field is documented in the metadata.yaml file reference, but is missing from the charmcraft.yaml file reference, even though it does work there. This PR adds it to that reference. As the docs currently are, it gives the incorrect impression that you cannot use the combined charmcraft.yaml file to specify `charm-user`, and must have separate metadata, actions, and config files. --------- Co-authored-by: Erin Conley <[email protected]> Co-authored-by: Ali UĞUR <[email protected]>
tonyandrewmeyer
added a commit
to tonyandrewmeyer/charmcraft
that referenced
this pull request
Mar 13, 2025
…al#2195) The `charm-user` field is documented in the metadata.yaml file reference, but is missing from the charmcraft.yaml file reference, even though it does work there. This PR adds it to that reference. As the docs currently are, it gives the incorrect impression that you cannot use the combined charmcraft.yaml file to specify `charm-user`, and must have separate metadata, actions, and config files. --------- Co-authored-by: Erin Conley <[email protected]> Co-authored-by: Ali UĞUR <[email protected]>
dimaqq
pushed a commit
to dimaqq/operator
that referenced
this pull request
Mar 17, 2025
Exposes the `charm-user` field in `CharmMeta`. The field is added as a string (with type annotations providing the three possible values) rather than an enum. We have a mixture in the other meta fields - `RelationRole` is an enum, but `ResourceMeta.type` is a string and `StorageMeta.type` is a string. It seems like `charm-user` can go with the simpler form - and it's also easier to add an enum later than it is to remove one. Like most of the rest of the meta loading, there's also no validation (that it's one of the three possible values) - it seems reasonable to assume that if there's some other value in a production environment that's a `charmcraft` bug (or there's a new type we don't handle yet) and in development `charmcraft` will raise the problem when packing. See also the [charmcraft docs](https://canonical-charmcraft.readthedocs-hosted.com/en/stable/reference/files/metadata-yaml-file/#charm-user) (and a [PR to fix it being missing from charmcraft.yaml reference](canonical/charmcraft#2195)). Fixes canonical#1396
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
charm-userfield is documented in the metadata.yaml file reference, but is missing from the charmcraft.yaml file reference, even though it does work there. This PR adds it to that reference.As the docs currently are, it gives the incorrect impression that you cannot use the combined charmcraft.yaml file to specify
charm-user, and must have separate metadata, actions, and config files.