autotag icon indicating copy to clipboard operation
autotag copied to clipboard

Support tag per subdirectory

Open sermojohn opened this issue 3 years ago • 3 comments

In a monorepo containing multiple go modules, versioning of each module is possible using the subdirectory prefix.

This way go get will use the version specific to the module of the monorepo, if the repo is tagged with the module directory.

Example:

Monorepo:
github.com/sermojohn/go-monorepo-importer
Module 1:
github.com/sermojohn/go-monorepo/mod1
Module 2:
github.com/sermojohn/go-monorepo/mod2

autotag could be provided with a flag referring to the subdirectory of a go module in a monorepo, in order to:

  • find the last tag of the subdirectory, e.g. mod1/v0.1.1
  • write the new tag for the subdirectory, e.g. mod1/v0.1.2

This way autotag can create tags that are compatible with Go modules. reference: https://go.dev/ref/mod#vcs-version

We are in need for this feature, so I have capacity to work on it and contribute to autotag, if you think this feature is valuable to this project.

sermojohn avatar Feb 23 '22 14:02 sermojohn

@sermojohn This is a good Idea I think. It would be good to be more compatible with a mono repo. Especially if you are willing to work on a PR.

I think the simplest thing would be flag to set a rootdir for the git repo. This way autotag wouldn't care if it was a mono repo or not. It opens up other use-cases where you may be building multiple projects in a workflow.

spheromak avatar Mar 27 '22 23:03 spheromak

I have a version where you can pass a prefix so the tool will know how to get the tags. Will this work?

ekirmayer avatar Apr 12 '22 09:04 ekirmayer

@sermojohn This is a good Idea I think. It would be good to be more compatible with a mono repo. Especially if you are willing to work on a PR.

I think the simplest thing would be flag to set a rootdir for the git repo. This way autotag wouldn't care if it was a mono repo or not. It opens up other use-cases where you may be building multiple projects in a workflow.

I worked on a fork a while ago in order to provide support for this. While I progressed the implementation I realised that native monorepo support was needed, because:

  1. Bump a project version should take into account only the commits that modify that project (subdirectory)
  2. Integrating monorepo auto-tagging with a CI, more information were needed, like the current tag and tag commit. The modified monorepo projects from a set of commits since their current version.

As a result, I moved to a hard-fork, by reimplementing this tool with native monorepo support, but re-using some work from this repo. The tool is named gitmono.

sermojohn avatar Apr 12 '22 13:04 sermojohn