Possibility to not fail if there isn't a git repo yet

[ckipp01]

I hit on this every time I start a new project. When I set up a new project, for example using a template like https://github.com/ckipp01/mill-plugin.g8, it uses mill-vcs-version by default. When you start coding and want to test your plugin for the first time with itest it will fail with:

fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
1 targets failed
de.tobiasroeser.mill.vcs.version.VcsVersion.vcsState.overridden.de.tobiasroeser.mill.vcs.version.VcsVersion.vcsState /Users/ckipp/Documents/scratch-workspace/g8-testing/my-mill-plugin is not a git repository.

Even if you do a git init it will still fail. The docs say:

noTagFallback: String = "0.0.0" - will be used when no tag was found

So I'd expect that if no tag is found or no git repository, this fallback would be used. However I see that this will fail before it even gets to that point. Would you be open to a change where that if publishVersion is called before a git repo is set up that it falls back to this? This is also the behavior that https://github.com/sbt/sbt-dynver uses, which a lot of users coming from sbt might be used to.

[lefou]

I'd like to link a previous discussion about this topic: https://gitter.im/lihaoyi/mill?at=6229f4726b9124232029373a

Tobias Roeser
@lefou
März 10 13:52
Hi to all mill-vcs-version users. How should the plugin behave, when there is no valid git repo found? This can happen, if you just start a project, but also, if you use a project export/snapshot, which typically does not contain versioning infos. Should it just fail? Or fall back to base version 0.0.0 and the typical commit count + hash?
Lorenzo Gabriele
@lolgab
März 10 13:56
I'm fine with the current 0.0.0-hash which should be the current behaviour.
If I clone a repo with --depth 1 to save space I don't want the build tool to crash and then I need to tweak the build to put a random string to compile the code.
Actually this happens when there is no repo
Which for me is the same. Sometimes I download the zip files from Github releases. I don't know if they have a git history inside.
Tobias Roeser
@lefou
März 10 13:59
@lolgab thanks
_
I released mill-integrationtest 0.5.0 which supports to set env variables. Now, that I can test this behavior in mill-vcs-version, I was surprised that the already existing but commented-out test case failed instead of providing a 0.0.0. So, I myself was unsure what the current behavior is.
Lorenzo Gabriele
@lolgab
März 10 14:25
Actually you're right! It currently fails when there is no git repository 🙈

./mill --no-server show __.publishVersion
[1/1] show
[1/1] show > [1/3] de.tobiasroeser.mill.vcs.version.VcsVersion.vcsState
fatal: not a git repository (or any of the parent directories): .git
1 targets failed
show 1 targets failed
de.tobiasroeser.mill.vcs.version.VcsVersion.vcsState os.SubprocessException: CommandResult 128

   os.proc.call(ProcessOps.scala:85)
   de.tobiasroeser.mill.vcs.version.VcsVersion.$anonfun$vcsState$2(VcsVersion.scala:19)
   mill.define.Applicative$Applyer.$anonfun$zipMap$1(Applicative.scala:35)
   mill.define.Task$MappedDest.evaluate(Task.scala:396)

So currently it generates 0.0.0-hash when there are no tags but there is a git repository with at least one commit, otherwise it fails.
Tobias Roeser
@lefou
März 10 14:34
Hm, so what would be a good behavoir. Thing is, it's hard to come up with a valid VcsState instance without a repo. Maybe, we can fallback to some env variable. If defined, we use that, if not we fail.
Or we provide a new target, which returns an option.
Lorenzo Gabriele
@lolgab
März 10 14:37
@lefou Since it's an edge case it can also be a magic string like "no-version" and just log an error to the stdout. So people can do other things without bothering about the version
Tobias Roeser
@lefou
März 10 14:39
You mean:

VcsState(currentRevision = "no-version", lastTag = None, commitsSinceLastTag = 0, dirtyHash = None)

?
Or we include the vcs, if any

VcsState(currentRevision = "no-version", lastTag = None, commitsSinceLastTag = 0, dirtyHash = None, vcs = None)

in contrast to vcs = Some("git")
Lorenzo Gabriele
@lolgab
März 10 14:43
I have to admit I haven't digged into the internals of mill-vcs-version, I just use VcsVersion.vcsState().format() which could return something like: 0.0.0-SNAPSHOT or no-version.
If you don't have a git project I guess you can't assume it is Git.
If you have a Git project with no commits you probably can.
Tobias Roeser
@lefou
März 10 14:45
Thanks for your input.

[ckipp01]

Ah cool thanks for the link, although it's still not clear where it left off or what the desired outcome is then. Would it be ok that instead of curHead failing we just return 0.0.0-SNAPSHOT like was mentioned, and maybe log that no version was found? Then we just document that's the behavior? I think it's desirable that someone can just def publishVersion = VcsVersion.vcsState().format() when they get started and still get something usable before they version without having to have any special settings. That'd be my goal with this change.

[lefou]

I think we have two use cases.

1. We just want to not fail the build, even if we just started the project (and don't have a git repo yet) or used a zipped download of it
2. We want a publish/release process to fail, when there is no correct version information, e.g. the git repo was not properly checked out.

We should provide solutions for both use cases. Currently we only support case 2. But your described issue clearly falls into use case 1.

Here are some more considerations:

• currently, mill-vcs-version can be used without any configuration
• use case 1. is an edge-case but can also happen at any time, and I would assume it happens to users who are not very familiar with the build, so forcing them to change the build.sc is not an option.
• use case 2 should be the default, as we don't want to succeed a release/publish process with incorrect (and hard to roll back) versioning information.

What about a fallback env variable (MILL_VSC_VERSION_OVERRIDE), which can be used when no git repo is found or even always? We could add a hint to such a variable in the error message, so that there is no need to fully read the documentation.

Example:

sh$ MILL_VSC_VERSION_OVERRIDE=0.1.2-overridden mill showNamed "{de.tobiasroeser.mill.vcs.version.VcsVersion/vcsState,foo.publishVersion}"
{
  "de.tobiasroeser.mill.vcs.version.VcsVersion.vcsState": {
    "currentRevision": "none",
    "lastTag": [
      "0.1.2-overridden"
    ],
    "commitsSinceLastTag": 0,
    "dirtyHash": [
      
    ]
  },
  "foo.publishVersion": "0.1.2-overridden"
}

[ckipp01]

We should provide solutions for both use cases. Currently we only support case 2. But your described issue clearly falls into use case 1.

🤔 so I guess I'm sort of viewing mill-vcs-version in isolation, meaning it shouldn't be concerned about publishing or knowing anything at all about it. I feel that sort of simplifies things because they if there is a tag, it knows what to do with it, if there isn't it falls back to X no matter if it's local, in CI, etc.

What about a fallback env variable (MILL_VSC_VERSION_OVERRIDE), which can be used when no git repo is found or even always?

I don't think this would be a win. It still requires manual action from the user when they might simply just be getting started, set up their repo, and want to know the version. I think this behavior should just be defaulted without an env variable.

[lefou]

I created a new PR which implements support for missing version control systems.

• Support projects not yet under version control #80

You can check for proper version control with VcsVersion.vcsState().vcs: Option[Vcs].