Populate the 'version' file as part of 'charmcraft build'

[jameinel]

When Juju creates a charm .zip file from a directory, one of the steps is to populate the version file:
https://github.com/juju/charm/blob/master/charmdir.go#L268

https://github.com/juju/charm/blob/5fe646695e8585e7a6b9fedb0d10cc7fbc598e48/charmdir.go#L521

That allows for a nice way to track back what content is running on a given server, tied back into the source tree that it was generated from.

[facundobatista]

What we'll put in the 'automatic version file'?

We only have the git hash, users will want the version to be 1.0, 1.1.

I'm +1 for build to produce something if not there, but a good formed project probably should provide its own information there. Versioning is important :)

[mthaddon]

Is this issue is about allowing charm consumers to verify which revision of a charm's source code it was generated from (which I think it is based on the original comment)? If so I don't think we're talking about a version of "1.0" or "1.1". If not I'd like to file a separate issue for that, as it's needed as part of canonical/charmhub.io#727.

[facundobatista]

Conclusion of what we'll do is:

• if the version file is there, we'll just include it (not modifying it at all)
• otherwise, generate it automatically in the built charm with CVS information:

    CMDS = (
        ('git', 'describe', '--dirty', '--always'),
        ('bzr', 'version-info'),
        ('hg', 'id', '-n'),
    )

In the future we may add a keyword in charmcraft.yaml to override this behaviour, if needed.

[facundobatista]

We dropped the idea of automatically saving a version file as part of charm packing. The very concept of "version" is under discussion, and probably it or something similar will appear in the official Charm metadata, but with semantics still under study (specially when used by Juju). Furthermore, it's not clear that Charmcraft as a tool will be involved in it, if it will be a pure developer responsibility, or Charmhub will do something regarding its value.

[hloeung]

@facundobatista can Charmcraft as a tool detect the presence of the version file and create it if it doesn't exist? This then allows developers or charm authors to ability to either have charmcraft maintained for a charm or manually override it with a version.

Reason for this is that we've written a few charms now that rely on the version being there and populate the status field with info from that. This allows us, Canonical IS, to more easily identify what commit or version of a charm was used and also find where a charm revision was deployed and upgrade (we have cron jobs to periodically dump out juju status output).

If Charmhub were to manage something, perhaps it would use it's own ".charmhub_version" or just not update what's in the charm itself but retrieve from it's own DB.

[facundobatista]

We decided to not create a version file if it does not exist. As commented above, there are some fundamental changes on how Charmhub/Juju will handle the concept of version and how/where it will be expressed. We need to wait for that to be designed before we understand what (if something) we need to do in Charmcraft.

[phvalguima]

charmcraft team, hi

This continues to be an issue for air gapped deployments and support later on. We really need a solution here, as Juju does support manually setting revision numbers with "revision" file, but charmcraft ignores it when it generates the .charm file.

I have filed a similar bug requesting juju to have an option to set channel information for local charms in LP#2039544.

[phvalguima]

Adding the following:

parts:
  charm:
...
    override-stage: |
      craftctl default
      cp /root/parts/charm/build/revision /root/stage/revision
    prime:
      - revision

Allow to push the revision file with the charm. Is there an env variable to define /root/stage and /root/parts/charm/build?

[jameinel]

Note that you can create a 'version' file with whatever you would like, and charmcraft will preserve it in the .charm file. 'revision' is dangerous for other reasons, but as long as your build pipeline creates a 'version' file, charmcraft will preserve it. (`git describe --tags --dirty > version` is generally a reasonable build stage)

…

On Tue, Oct 17, 2023 at 6:38 AM phvalguima ***@***.***> wrote: Adding the following: parts: charm: ... override-stage: | craftctl default cp /root/parts/charm/build/revision /root/stage/revision prime: - revision Allow to push the revision file with the charm. Is there an env variable to define /root/stage and /root/parts/charm/build? — Reply to this email directly, view it on GitHub <#37 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABRQ7KLRXU2Z5U7SCWXWITX7ZN3JAVCNFSM4N7TZ3LKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCNZWGYYTINRQG44A> . You are receiving this because you authored the thread.Message ID: ***@***.***>