[JIRA] (OVIRT-1374) Provide a mechanism to obtain an ever increasing build number

Barak Korren (oVirt JIRA) jira at ovirt-jira.atlassian.net
Fri May 12 12:10:37 UTC 2017


    [ https://ovirt-jira.atlassian.net/browse/OVIRT-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=30701#comment-30701 ] 

Barak Korren commented on OVIRT-1374:
-------------------------------------

While this is something we can look into, I think in the short term just counting commits from last tag with something like 'git describe' should be enough. It is not likely that we'll switch to shallow cloning any time soon because we know that there are project that are using 'git describe'.



> Provide a mechanism to obtain an ever increasing build number
> -------------------------------------------------------------
>
>                 Key: OVIRT-1374
>                 URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1374
>             Project: oVirt - virtualization made easy
>          Issue Type: New Feature
>          Components: Jenkins
>            Reporter: Juan Hernández
>            Assignee: infra
>
> Currently when a project needs to generate unique names for artifacts, they have to use mechanisms like embedding the date and/or the git hash into the artifact name. For example, when a new build of the Ruby SDK is generated, the name of the RPM is like this:
>   rubygem-ovirt-engine-sdk4-4.2.0-1.alpha0.20170505gita6de891.el7.centos.ppc64le.rpm
> That information is useful, and usually unique. But can be repeated if the same jobs is manually triggered the same day, as the date and the git hash will be the same.
> In addition the date may be misleading, because a build performed later but using an old commit, will look newer than an older build that uses a newer commit.
> A possible solution is to count the number of commits since certain well known commit. But this isn't reliable if the repository isn't completely cloned, for example if it is cloned with '--depth 1', as that well known commit may not be in the cloned repository. That cloning out of the control of the automation scripts.
> So my suggestion/request is to add to the CI/CD environment a mechanism to provide that sequence to the jobs explicitly. I'd suggest to use the count of commits since the initial commit of the repository. The CI/CD environment performs the clone, so it can make sure it has all the relevant commits.
> This information could be passed to the build-artifacts.sh script in an environment variable, or in the command line, or in a file in a known location.
> With that each project could (optionally) modify its automation scripts to include that number. for example, in the Ruby SDK I'd like to generate RPMs like this:
>   rubygem-ovirt-engine-sdk4-4.2.0-1.alpha0.<that-number>.rpm



--
This message was sent by Atlassian JIRA
(v1000.962.0#100041)


More information about the Infra mailing list