Importing local go module of external service - go

Question

The background:
Two Applications - A and B
Application 'A' contains two go.mod files
A/pkg/test/go.mod: (I keep here application specific structures which are gonna be reused by another services willing to integrate)
module A/pkg/test
go 1.14
require (
some_dependencies vx.x.x
)
A/go.mod: (root module importing pkg/test as local module)
module A
go 1.14
require (
A/pkg/test v0.0.0
)
replace A/pkg/test => ./pkg/test/
Now Application 'B' would like to re-use Application's A pkg/test package by simply importing it
The Adventage:
This solution lets any integrating services pull only dependencies of pkg/test module instead of importing whole application A tree
Current Solution:
Application 'B' imports pkg/test module of Application 'A' using following go.mod:
module B
go 1.14
require(
some_dependencies vx.x.x
A/pkg/test v0.0.0
)
replace A/pkg/test => gitlab.com/A/pkg/test v0.0.0-02345798575346-72cs44671e34
Now I really do not like using commit-timestamp_commit-sha approach here.
The problem:
I would like to use TAGS in order to import A/pkg/test module.
Repository A has a tag, say v2.0.0, created. When I replace v0.0.0-02345798575346-72cs44671e34 with v2.0.0, after running go mod tidy/download I am getting following error output:
reading gitlab.com/A/pkg/test/pkg/test/go.mod at revision pkg/test/v2.0.0: unknown revision pkg/test/v2.0.0
The question:
I assume bad package naming/module naming/tagging etc. might lead to such error. The question is what am I missing here in order to make it clear and work?

Answer 1

To take a nested go-modules package within a git repo, just add a tag to the directory that contains the go.mod file - and then append your version.
So in your case, the directory is A/pkg/test and lets say you wanted to use semver v0.0.1 you tag like so:
git tag -a "A/pkg/test/v0.0.1" -m "initial test checkin"
git push origin --tags # push all local tags
# git push origin "A/pkg/test/v0.0.1" # push a single tag
Please Note: from the Go wiki Should I have multiple modules in a single repository? - Russ Cox (the creator of vgo i.e. today's go-modules) warns:
For all but power users, you probably want to adopt the usual
convention that one repo = one module. It's important for long-term
evolution of code storage options that a repo can contain multiple
modules, but it's almost certainly not something you want to do by
default.