Easy Way to Relate Git Version to Package Version

[markvoelker]

Per discussions with @iawells this afternoon:

It would be very helpful to have an easy way to see what the latest commit in git was at the time the source was pulled to create a given package. The "Recent Changes" section on the front page does show the code revision and packaging revision and the timestamp of the last build, but it only shows recent things and doesn't show the version of the package produced. Perhaps adding the first 7 chars of the SHA hash used to build the package on the /repositories/$repo/$series page would suffice? So:

Packages
Package name Stable version Proposed version Queued version
puppet-drbd 20121119-3-cisco1 20121119-3-cisco1

Becomes:

Packages
Package name Stable version Proposed version Queued version
puppet-drbd 20121119-3-cisco1 (962a9e8) 20121119-3-cisco1 (962a9e8)

Ideally the SHA text is a link to the commit.

[iawells]

For preference I would do this so that releases cause a tag to be made in git corresponding to their version number.

But any traceability would help.

[sorenisanerd]

This is rather difficult to achieve.

The system that polls git and creates and uploads source packages is by design decoupled from the core APT repo mgmt system. In order to pass this particluar bit of information, I'd need to embed it in the .changes file at source package build time, parse it out and store it somehow in the repomgmt system. So far, I've been able to rely entirely on reprepro for package tracking (i.e. I don't shadow its information in the repomgmt system's SQL database) and since this is custom information, I'd need to either modify reprepro to track this information or start shadowing reprepro's DB in the repomgmt system so that I can query this information easily.

As a temporary measure, would it be helpful is you could see the changelog entry of the package by hovering over the relevant line in the web UI? The changelog entry shows this information, but it's somewhat expensive to pull it out, so I'd like to avoid having to do it for every package ahead of time.

[iawells]

That would help quite a lot. At the moment the process for finding out whether your change is incorporate is basically:

commit change
wait around 30 minutes, but it varies
Install COE
Check README.Debian.gz on installed machine to get change number
Check git logs to confirm correct change re last commit

Anything that simplifies this process with reasonable confidence of being right would be a big help. Your hover suggestion sounds like a good answer.

Other than that, I wonder if the make-release-tag process should work from the packages in a repository, somehow - so when we freeze folsom-proposed to 2012.2.4 or whatever, we should be extracting the repository and change hash from the debian packages and tagging that. That would save doing it as a part of the generalised build process and ensure that we have a mark in place in the repository for the most significant versions - key when, for instance, you have to start a feature or a maintenance branch. We'd also be totally certain that the packages in the APT repository exactly correspond to the versions that we tag up, more so even than if we did this in the build process. If we did this this would become a part of the release management and not build management process - i.e. go in the release script rather than the web app.

Ian.

From: Soren Hansen <notifications@github.commailto:notifications@github.com>
Reply-To: sorenh/python-django-repomgmt <reply@reply.github.commailto:reply@reply.github.com>
Date: Tuesday, 2 April 2013 11:33
To: sorenh/python-django-repomgmt <python-django-repomgmt@noreply.github.commailto:python-django-repomgmt@noreply.github.com>
Cc: Ian Wells <iawells@cisco.commailto:iawells@cisco.com>
Subject: Re: [python-django-repomgmt] Easy Way to Relate Git Version to Package Version (#17)

The system that polls git and creates and uploads source packages is by design decoupled from the core APT repo mgmt system. In order to pass this particluar bit of information, I'd need to embed it in the .changes file at source package build time, parse it out and store it somehow in the repomgmt system. So far, I've been able to rely entirely on reprepro for package tracking (i.e. I don't shadow its information in the repomgmt system's SQL database) and since this is custom information, I'd need to either modify reprepro to track this information or start shadowing reprepro's DB in the repomgmt system so that I can query this information easily.