This new version was just released to candidate channel, we’d appreciate any tests on this, please report here any issues you find. Once we find this is solid enough, we will release it to stable.
It includes the following changes:
Added the --name option in the upload command to override the name declared in the metadata
Improved logging with details of the system where it’s being run (operating system, version, desktop, etc) for better debugging
Fixed the Framework linter to use the name from metadata in reactive charms
Added instructions to install Charmcraft from PyPI.
Fixed the release command to allow resources with revision 0
Fixed the process execution inside the isolated container so logs can be properly obtained from it
Reworked how Craft Store errors are handled to expose failures correctly
We recommend the Charmed Operator Framework for charm development, but Charmcraft will help you publish charms written in any language. The Charmed Operator Framework enables the development of operators in a simple and straightforward way, using standard Python structures to allow for clean, maintainable, and reusable code.
I wonder aloud if anyone uses CICD to package and release their charms? I am on gitlab and wondering how to just… test for now… not release or deliver but perhaps one day.
Would love some to chime in if they use charmcraft and how so
is this running for you in a Docker Container? I am on gitlab attempting to get snap to work but… seems quite challenging… perhaps I need to install charmcraft via some other manner?
Here I am trying to start the SNAPD … within a docker container …
`Removing intermediate container 1806b1c55edf` ` ---> 61d15d4462e4` `Step 6/9 : RUN systemctl start snapd.service` ` ---> Running in 6254724ad698` `System has not been booted with systemd as init system (PID 1). Can't operate.` `Failed to connect to bus: Host is down` `The command '/bin/sh -c systemctl start snapd.service' returned a non-zero code: 1 ` `Cleaning up project directory and file based variables
00:01
` `ERROR: Job failed: exit code 1`
well , after thinking I’d solved my problem I hit the next snag… I will next attempt to see if I can use charmcraft build or pack without LXD … because I am in gitlab with docker based containers and I dont really want to go down the route of having to put LXD in a docker container do I? or is this something others do? Or is everyone just… leveraging custom runners?
output I saw so far when attempting to leverage the docker container build in the previous posts CICD
$ charmcraft version 1.5.0 ` `
$ charmcraft pack` `LXD is required, but not installed.
Visit https://snapcraft.io/lxd for instructions on how to install the LXD snap for your distribution ` `
Full execution log: '/root/.cache/charmcraft/log/charmcraft-20220313-122414.568475.log' ` `
Cleaning up project directory and file based variables
00:01
` `ERROR: Job failed: exit code 1`
EDIT:
I added LXD via apt… no dice
$ charmcraft pack
Failed to query LXD version.
* Command that failed: 'lxd version'
* Command exit code: 1
* Command standard error output: "\nCommand '/usr/bin/lxd' requires the lxd snap to be installed.\nPlease install it with:\n\nsnap install lxd\n\n"
Full execution log: '/root/.cache/charmcraft/log/charmcraft-20220313-123745.451517.log'
Cleaning up project directory and file based variables 00:01
ERROR: Job failed: exit code 1
I tried doing
# Required for Charmcraft Pack
RUN apt install snapd -y
CMD systemctl status snapd.service
but to no avail
$ snap install lxd
error: cannot communicate with server: Post http://localhost/v2/snaps/lxd: dial unix /run/snapd.socket: connect: no such file or directory
Cleaning up project directory and file based variables 00:01
ERROR: Job failed: exit code 1
and
systemctl status snapd.service
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to connect to bus: Host is down
Cleaning up project directory and file based variables 00:00
ERROR: Job failed: exit code 1
The “building inside a container” feature from Charmcraft is to provide isolation from your host and exact control of the building environment.
If you already have a container (on which you have control on what is installed), no need to launch another container inside it, you can just use the --destructive-mode option for the pack command so Charmcraft builds directly there.
Using docker image sha256:7f4f35cfd9b5d4bdfb155546e29a7140d383b406d28bf862f3a5c0d4af7a3453 for registry.gitlab.com/jrgemcp-public/gitlab-cicd-docker/build-charms-docker:latest with digest registry.gitlab.com/jrgemcp-public/gitlab-cicd-docker/build-charms-docker@sha256:3238dbb9fd181087dac73684d9b02d641736ebe8148b46e138634e33aa072bf0 ...
$ charmcraft version
1.5.0
$ charmcraft pack --destructive-mode
Created 'mahrio_ubuntu-20.04-amd64.charm'.
Charms packed:
mahrio_ubuntu-20.04-amd64.charm
Cleaning up project directory and file based variables 00:01
Job succeeded
Hello! Are you able to install Charmcraft from the snap? If no, what is the error you get? If yes, are you able to run charmcraft pack --verbose succesfully? If no, can you provide the logs? Thanks
RUN apt install python3 python3-pip libffi-dev libapt-pkg-dev libssl-dev -y
RUN pip3 install https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/python-apt/2.2.1/python-apt_2.2.1.tar.xz
RUN pip3 install charmcraft
RUN charmcraft version
RUN python3 --version
I’ve moved to running charmcraft pack from an Ubuntu Server machine sitting on my desk. Login to the store fails, because I don’t have the ubuntu-desktop packages installed. But the new version of charmcraft fails in a more useful way, which lead me to the docs outlining a fix
Unfortunately this just add dependency to another container, but I guess I can skip the docker steps and perhaps @heitor can supply information about the systemd-nspawn ?
It seems this would be a path forward, especially for CI/CD but it would indeed introduce the destructive part of it. Perhaps @heitor is on to something here with systemd-nspawn?
Oh and I saw the PR for the desktop plug in Mattermost, thanx alot for looking at this its really in a dire need to help other communities that hasn’t bought in to snap, to be able to buy in to juju…
There is no problem of using destructive mode in CI/CD, as those containers are ephemeral (you should not use them in your daily computer or places where the installation it’s supposed to be long-lived).
Totally, but I’m considering all those trying to build on a non-ubuntu client.
Think community here: “Is juju a Ubuntu community?”
If the answer to that is “yes” then I can understand the logic for just basically don’t give a rats about anything that is not included in the Ubuntu clients.
But if the answer is that is “no” - Juju should stand on its own merits. Then these things matter.
There are consequences of alienating other distros. Picking a technology for building charms that can reach other distros would benefit Juju.
I just released 1.5.0 to the stable channel. And, as a novelty, I released it also to the very new track 1.x (which you could install from to not be upgraded from 1.x accidentally).
