baremetal-operator: pkg/hardwareutils module is not imported properly
When uplifting BMO apis modules in CAPM3, I am facing an issue where it tries to import BMO api but fails to read pkg/hardwareutils as follows:
go mod tidy
go: downloading github.com/metal3-io/baremetal-operator/pkg/hardwareutils v0.0.0
github.com/metal3-io/cluster-api-provider-metal3 imports
github.com/metal3-io/baremetal-operator/apis/metal3.io/v1alpha1 imports
github.com/metal3-io/baremetal-operator/pkg/hardwareutils/bmc: reading github.com/metal3-io/baremetal-operator/pkg/hardwareutils/pkg/hardwareutils/go.mod at revision pkg/hardwareutils/v0.0.0: unknown revision pkg/hardwareutils/v0.0.0
Looks like when fetching BMO apis from root go.mod of BMO, it tries to access github.com/metal3-io/baremetal-operator/pkg/hardwareutils and is not able to find it, because the path to the module is structured incorrectly for some reason, specifically see
reading github.com/metal3-io/baremetal-operator/pkg/hardwareutils/pkg/hardwareutils/go.mod at revision pkg/hardwareutils/v0.0.0
where pkg/hardwareutils is duplicated in the path.
Considering last uplift of BMO in CAPM3 went smooth and that was before https://github.com/metal3-io/baremetal-operator/commit/0197893937b01624850af453c56864622081dc82 landed where it reorganized the module a bit, it can be a culprit.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 1
- Comments: 33 (27 by maintainers)
This can be closed as solved, after tagging submodules properly, we can import BMO from the CAPM3 without workarounds. Thanks everyone.
/close
@s3rj1k, @goshlanguage apis/v0.1.0 and pkg/hardwareutils/v0.1.0 tags are added now.
yes, that’s the output of BMO uplift in CAPM3
@furkatgofurov7 I think we should not face that issue anymore if we try with v0.1.0
@furkatgofurov7 that is strange. I’ll investigate.
/assign
Hi, Thanks for the PR. If we will be able to get 1165 merged by tomorrow, sure thing. I was planning to cut a new patch release tomorrow as I notified already the community over the slack recently (xref https://kubernetes.slack.com/archives/CHD49TLE7/p1662582014489209) due to other reasons as well.
@fmuyassarov I see you just cut a new release, would you please add tags for the
apiandhardwareutilssubmodules?I do not see anything wrong with using hash commit, it will work, lots of golang modules out in the wild do not set proper tags, it is life, this is not convenient, I agree, but work fine.
Actually it does, you just need to set multiple tags on same commit, one for root go.mod, containing tagged release version and other tags must be prefixed with subfolder path of go.mod.
So I was referring that in this way project would want to set all tags for all go.mod files below the root and also for actual root and it should be same version.
Something like
And it is obviously a job for CI automation, the only thing that needs to be decided here by human is actual base version.
So general (proper) solution would still be linked to https://github.com/metal3-io/baremetal-operator/issues/746
Sadly 2+ years have passed and still no decision on making tagged release was made.
Unfortunately, nowadays I’m working on different projects and most probably I’ll not be able to find time to fix that.
/unassign