Open Nicolas-Peiffer opened 4 days ago
@Nicolas-Peiffer Do you know how well Git submodules play with Go modules? For example, consider we want to embed schema files from the submodule via //go:embed
. Will consumers of cyclonedx-go
still be able to use the library (because Go automatically clones submodules), or will this cause issues (because Go doesn't automatically clone submodules)?
@nscuro you make a very good point that I completely missed. Thank you very much for this :+1: .
Indeed, after a quick search with ChatGPT4 and the web, I came to the conclusion that GoLang packages on Github.com does not support git submodules natively.
There is an open issue since 2016 somehow similar to this topic: https://github.com/golang/go/issues/17522
And the workarounds based on git clone --recurse-submodules [...]
are not satisfactory, since they are not supported by go install
and go get
.
I think the only viable short term solution (outside of patching GoLang to add support for git submodules) it to mimic what is already done on the python implementation:
github.com/CycloneDX/specification
with a bash script tests/_data/schemaTestData/fetch.sh
;tests/_data/own
;What do you think?
As of today, I noticed
cyclonedx-go/testdata
only providesvalid-*
sample test BOM files in XML and JSON. It provides noinvalid-*
files, and no protobuf files.And files are not sorted by CycloneDX specification version, which makes it harder to list and to maintain.
But I noticed the
github.com/CycloneDX/specification
repository provides bothvalid-*
andinvalid-*
BOM sample files in XML, JSON and PROTOBUF formats. These files are useful to tests implementation of the CycloneDX, such asgithub.com/CycloneDX/cyclonedx-go
.I suggest using a git submodule to fetch tests files from the CycloneDX specification repository.
This would give access to the full list of
valid-*
andinvalid-*
BOMs files in*.xml
,*.json
and*.textproto
with no efforts. This would be available at this path:cyclonedx-go/specification/tools/src/test/resources
.And if there are tests files dedicated to one particular language (Go, python, or Java), then either keep a folder for custom test files, or contribute to the tests files in the
CycloneDX/specification
repo.All CycloneDX Implementation Python, Golang, Java could do the same
The same principle could be applied to any CycloneDX implementation:
github.com/CycloneDX/cyclonedx-go
github.com/CycloneDX/cyclonedx-core-java
github.com/CycloneDX/cyclonedx-python-lib
Use the git submodule for Schema Files as well?
Once the git submodules for
CycloneDX/specification
are available in bothcyclonedx-go
,cyclonedx-core-java
andcyclonedx-python-lib
to fetch test files, this could also be used for fetching schema files (JSON Schema, XSD and protobuf).This would prevent issues such as this one where I noticed CycloneDX schema files are different from one CycloneDX implementation to another. https://github.com/CycloneDX/specification/pull/479#issuecomment-2180940956
CC @jkowalleck & @nscuro who helped me figure out how to explain this idea :smile: