Fedora Account System
Red Hat Associate
Red Hat Customer
When building packages automatically from an SCM repository, all packages will have the same N-V-R absent explicit changes to the spec file. It would be tremendously useful if we could provide the SCM revision id to the build process so that it could be included in package names (or written to a file included in the package), so that it was obvious from which commit a build originated. If the revision information was provided as an RPM macro, we could do something like: Release: 1%?{dist}%{?scm_revision_id:.git%{scm_revision_id}} Or: %if %{?scm_revision_id} echo "%{scm_revision_id}" > build_id %endif Additionally: It would be even better if copr could run a script in the repository to determine the version information (and then provide this as another rpm macro); this would allow builds to automatically derive the Version: field from git tags or other information.
Thinking about the practical implementation of the above, for the simple case, when using mock-scm with a git repository, we could call "git rev-parse HEAD" to get the current commit id... SCM_REVISION_ID=$(git rev-parse HEAD) ...and then run mock with: --define "scm_revision_id $SCM_REVISION_ID" For the second part of the request, we would need a couple of additional fields in the web ui ("Get version command" and "Get release command"), and then do something similar. E.g., if someone were to set "Get version command" to "git describe --tags | cut -f1 -d-", then we would do something like: SCM_VERSION=$(git describe --tags | cut -f1 -d-) And then run mock with: --define "scm_version $SCM_VERSION" Etc. This assumes that there exists a safe way to run an arbitrary script in the git repository before starting "mock".
This makes building of the same NVR harder to reproduce out from copr, so I'm not in favor of such change. Also the package would be against guidelines, most probably. But OTOH if user asks for it... I think for the sake of correctness, we should close this as duplicate for https://bugzilla.redhat.com/show_bug.cgi?id=1415802 though, because we tried to deal with the same issue before. To discuss further technical details: In your particular proposal, the subsequent NVRs are not guaranteed to be "greater than any previous" NVRs (with external copr-cli --define you could take of it in your CI e.g.). So this would make the addition a bit useless. We could play with 'git rev-list --count', though we have only shallow copy of git available ... We could play with '%define date %(date ...)', though such macro you can provide yourself, as discussed in 1415802. If we finally went this way, we should really stay in %copr_ or %copr_scm namespace, instead of %scm_ or so.
I think I can make this feature directly in mock-scm.
Since this bug is against mock now, please keep the macros in %mock_ namespace; so everybody can do things like (macro naming is not important): 'Release: 1%{?mock_build_date:.%mock_build_date}%{?dist} Or even better: 'Release: 1%{?mock_dist_date}%{?dist}' And it would be super nice if exporting of such macros was optional. The point is to avoid the need to differ the production spec files from continuous integration spec files too much ... So while maintaining one spec file for CI and production, the %{?mock_dist_date} would be (by default) expanded as empty string for production builds.
This package has changed maintainer in the Fedora. Reassigning to the new maintainer of this component.