You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We need to handle bundles properly in all the operations related to the store.
Most of that should be ok already, but for sure we need to improve some details:
in the register command, give the option to register the name for a bundle. The idea is to provide a --type option that will allow the charm and bundle values (and possibly more in the future, like stack); this --type can be avoided if the project from where the command is issued can be identified as one or the other, otherwise it's mandatory.
in the names command, add a column with the type of the package.
in the build command, we should support a metadata.yaml not being there but a bundle.yaml: in that case just build a zip named .bundle with everything that is there (pretty much like we do for charms) but without building dependencies, or creating hooks/dispatch, etc. So in reality build will have two modes ("charm" and "bundle"), decided automatically after what is found in the project. Note also that some options are valid for the different modes (like --from) but others are not (like --entrypoint): in the latter cases we need to raise an error.
in the upload command, we need to rename current --charm-file to be --file (supporting both charm and bundle files), and improve what is automatically detected from the project where the command is issued (we can guess the name from a possible metadata.yaml, for example, but not from a bundle.yaml).
The text was updated successfully, but these errors were encountered:
We need to handle bundles properly in all the operations related to the store.
Most of that should be ok already, but for sure we need to improve some details:
in the
register
command, give the option to register the name for a bundle. The idea is to provide a--type
option that will allow thecharm
andbundle
values (and possibly more in the future, likestack
); this--type
can be avoided if the project from where the command is issued can be identified as one or the other, otherwise it's mandatory.in the
names
command, add a column with the type of the package.in the
build
command, we should support ametadata.yaml
not being there but abundle.yaml
: in that case just build a zip named.bundle
with everything that is there (pretty much like we do for charms) but without building dependencies, or creating hooks/dispatch, etc. So in reality build will have two modes ("charm" and "bundle"), decided automatically after what is found in the project. Note also that some options are valid for the different modes (like--from
) but others are not (like--entrypoint
): in the latter cases we need to raise an error.in the
upload
command, we need to rename current--charm-file
to be--file
(supporting both charm and bundle files), and improve what is automatically detected from the project where the command is issued (we can guess the name from a possiblemetadata.yaml
, for example, but not from abundle.yaml
).The text was updated successfully, but these errors were encountered: