cartridge-cli icon indicating copy to clipboard operation
cartridge-cli copied to clipboard

pack: no way to retrieve app version during build within pack context

Open RunsFor opened this issue 5 years ago • 2 comments

When packing, cartridge CLI copies project into temprorary directory and does some cleanup there. It also removes .git directory.

In my application I'm building multiple artifacts which need to have version tag inside. Right now it seems there is no way to get app version from within pack context.

One way to workaround this is to keep version file in version control. But this is not always convenient. It would be more flexible to provide some context for the app when building (i.e. through environment variables like CARTRIDGE_<VARNAME>)

RunsFor avatar Dec 09 '20 07:12 RunsFor

I was able to workaround this with bypassing environment variables myself (VERSION="1.0.0" cartridge pack ...), but still it would be convenient if cartridge did it for me

RunsFor avatar Dec 09 '20 07:12 RunsFor

I propose to generally reflect packpack's behaviour:

  • A user can place (or generate) the VERSION file or can set the VERSION environment variable.
  • If neither is given, packpack defaults to git describe --long --always (first three numbers from it).
  • Whether the VERSION environment variable is set by a user or packpack itself, it is available in the build context and (if there is no VERSION file) is placed to the VERSION file (full git describe output, don't know why).
  • If the VERSION file is tracked by git, it is available in the build context without changes. So, if it is a generated file, one should explicitly call git add to add it to the build context.
  • A VERSION file content is not available in the environment variable (as I see from packpack's code), however it looks a bit inconsistent.

The relevant packpack's code:

https://github.com/packpack/packpack/blob/0154f5e5af03126744e3ff35648de7264a011fcd/packpack#L150 https://github.com/packpack/packpack/blob/0154f5e5af03126744e3ff35648de7264a011fcd/packpack#L196 https://github.com/packpack/packpack/blob/0154f5e5af03126744e3ff35648de7264a011fcd/pack/config.mk#L45-L48 https://github.com/packpack/packpack/blob/0154f5e5af03126744e3ff35648de7264a011fcd/pack/tarball.mk#L8-L16

So, in other words, what I propose:

  1. Read the --version option.
  2. If no option provided, read the VERSION environment variable.
  3. If neither of them provided, read the VERSION file.
  4. If nothing from those three sources available, try to autodetermine using git describe --long --always.
  5. If git describe fails, use 0.0.1-1.

/* The format should be the same for all sources. The README states the following: major.minor.patch[-count][-commit] normalized to major.minor.patch-count. Let's use it. */

  1. Write the VERSION file for the build context (issue a warning and don't touch it if it is already there and differs from the version determined above).
  2. Set the VERSION environemnt variable for the build context.

@RunsFor Will such approach solve your problem?

Totktonada avatar Jul 23 '21 14:07 Totktonada