Skip to content

Resolve "(build): packaging fails with version tags containing app names"

Description

Previously, we version our application packages with the latest git tag found in the repository. This is not working in repositories where we have different tags for each application.

Let's take an example. Imagine a repository with three applications:

  • appFirst
  • appSecond
  • appThird

Here is the list of the tags ordered chronologically:

  • appFirst/1.0
  • appFirst/0.9
  • appSecond/2.2
  • appFirst/0.8
  • appSecond/2.1
  • ...

Before the changes in this MR, if we run the three packages targets, we would get three packages named (on Ubuntu):

  • 1.0-1-ga59ef67-Ubuntu-21.10-Debug-x86_64.tar.zst
  • 1.0-1-ga59ef67-Ubuntu-21.10-Debug-x86_64.tar.zst
  • 1.0-1-ga59ef67-Ubuntu-21.10-Debug-x86_64.tar.zst

So actually we only get one package. 😉 This is because the latest tag is appFirst/1.0 and because of the presence of a '/' which is badly interpreted.

To overcome this, we now proceed in the following way for each package target:

  • find the latest git tag matching the application name, and if found replace the '/' by a '-'
  • if not found, use the latest git tag with only contains digits
  • if not found, use the hash of the last commit

That means now, we get the following packages:

  • appFirst-1.0-1-ga59ef67-Ubuntu-21.10-Debug-x86_64.tar.zst
  • appSecond-2.2-1-ga59ef67-Ubuntu-21.10-Debug-x86_64.tar.zst
  • appThird-a59ef67-Ubuntu-21.10-Debug-x86_64.tar.zst

If we had anywhere an extra global tag with digits, i.e. 1.2, the last package would include this tag and thus be named appThird-1.2-1-ga59ef67-Ubuntu-21.10-Debug-x86_64.tar.zst. This is convenient for the Sight repository for instance, where we do not tag each application.

Closes #798 (closed)

How to test it?

You may try the different scenarios by adding temporary tags. You might also check out this MR on a child project and verify the name of packages.

Edited by Flavien BRIDAULT

Merge request reports