search

canonical / charmhub.io

GNU General Public License v3.0
9 stars 23 forks source link

Display source/commit of specific version of a charm #727

Open ghost opened 3 years ago

ghost commented 3 years ago

Hi, the charm page should display which commit the version is based on. Currently it only shows channel/version which makes it impossible to relate to a specific commit in the source of the charm.

tbille commented 3 years ago

Hey thanks for reporting this issue. This seems to be an issue with the API that we are hitting. Opened an issue: https://bugs.launchpad.net/snapstore-server/+bug/1908069

ghost commented 3 years ago

Hi @tbille, thanks for the update. Just to double check, the LP bug only mentions the bugs-url field. Does that also cover the commit hash/tag case?

mthaddon commented 3 years ago

Hi @tbille, thanks for the update. Just to double check, the LP bug only mentions the bugs-url field. Does that also cover the commit hash/tag case?

My understanding is that this is something entirely different. bugs-url is just about listing where bugs for the project are tracked (see https://github.com/canonical-web-and-design/charmhub.io/issues/709) but this issue is about showing the specific source/commit of a version of a charm. This is something the charmstore doesn't do currently, fwiw, and I'm not sure it's possible with the architecture as some charms require a "build" process (either using charm build for reactive or charmcraft build for the operator framework), so unless those processes embed some information about what source/revision a charm was built from there's no way for the charmstore (or charmhub) to know about it.

I'll ask for some input on this issue from some others to confirm.

ghost commented 3 years ago

Hi @mthaddon, yes, looks like the LP bug is for the other issue you mentioned.

This was already raised in 2017 in juju/charmstore#774 and the (old) charmstore actually has a field called extra-info which is being used by some charms to store the commit it's based on (see nova-compute example). In addition the OpenStack charmers usually also include a file called repo-info in the charm as part of the build process so there is an active need and use case for this.

tbille commented 3 years ago

hey @szeestraten-ntnu @mthaddon this is correct. My reply is not for this bug, sorry for the confusion I was triaging some issues :smile:

as @mthaddon mentioned this is another issue. I am not sure this feature. On snapcraft.io, which follows quite closely this store what was done is adding the commit hash on the version see: https://snapcraft.io/flameshot

I realise this is not the right solution in this case.

@facundobatista might be able to help for this?

mthaddon commented 3 years ago

Note that https://github.com/canonical/charmcraft/issues/37 is relevant here, in terms of operator framework charms.

jlounder commented 3 years ago

There is already an issue open on the charmcraft project to include a version file in the built charm (for operator charms) - which would contain identifying information related to the original source repository. https://github.com/canonical/charmcraft/issues/37

It would be great to get some addition feedback/ideas on the issue before any type of solution is implemented. There is a core challenge here, which is build are not executed directly from a GitHub repository, they are typically executed on a developer machine. We need to fully understand what contents to put in the version file if the developer is: working on branch; has uncommitted code; is not in-sync with upstream; etc.

mthaddon commented 3 years ago

It would be great to get some addition feedback/ideas on the issue before any type of solution is implemented. There is a core challenge here, which is build are not executed directly from a GitHub repository, they are typically executed on a developer machine. We need to fully understand what contents to put in the version file if the developer is: working on branch; has uncommitted code; is not in-sync with upstream; etc.

I think we should come up with sensible defaults, and warn the user if they're doing something unexpected. So for example, you could expect that at the point someone is running charmcraft build they should be doing so from the "master" branch that's in sync with upstream, or on a specific revision that can be referred to from charmhub.io (i.e. doesn't have to be the latest commit). If they're doing this, that allows you to include relevant info about the version it was built from. If that's not the case for any reason you could decide to do something different (prompt for "go ahead without version info", for example).

hloeung commented 3 years ago

For non-Operator Framework charms, there already exists a .build.manifest with a bunch of info including revision of repos as well as signature/check sum of files. Maybe we can use that, also have charmcraft build generate something similar for Operator Framework charms?

What would also be nice is to show a diff between charm revisions (similar to that of apt packages in LP with the debdiff files).