Add gemnasium as a git submodule, move builder package
What does this MR do?
- Add
gemnasium
as a git submodule- Use Go module
replace
to compile using./gemnasium
directory - Copy
vrange/python
from./gemnasium
instead of fetching it over HTTP
- Use Go module
- Move
builder
package togemnasium
- Import
main.go
fromgemnasium
instead of usingcommon/v2/command.Run
- Remove code related to auto-remediation, for clarity; auto-remediation for Python isn't supported
- Force scanner information when generating the report, otherwise
.scan.scanner
would matchgemnasium
This depends on gemnasium!161 (merged) and gemnasium!159 (merged)
This is a code refactoring; behavior doesn't change and there's no new version for this.
gemnasium as a git submodule
Having gemnasium
has a git submodule has pros and cons.
Pros:
- For developers, it's easy to enter the
gemnasium
directory, create a branch, and push commits. They can then move up to the root directory ofgemnasium-python
and changes its codebase, and push everything at the same time: updates to the codebase ofgemnasium-python
as well as the new ref forgemnasium
. It's harder to achieve the same with git submodules. - Switching to a branch of
gemnasium
takes way less time than runninggo get
to depend on that branch. -
vrange
scripts can be copied directly from thegemnasium
directory.
Cons:
- The
gemnasium
file only contains a commit SHA, and it doesn't tell what branch we're tracking. - The version of
gemnasium/v2
that shows up ingo.mod
isn't relevant. - Developers can easily miss that
gemnasium
refers to a commit that's going to be removed when the corresponding branch is squashed into master. -
GIT_SUBMODULE_STRATEGY
must be set to fetch the git submodule only when needed, otherwise the submodule is scanned; see !93 (merged)
Also, using the use of the git submodule must be covered by dev docs. See !88 (merged). That said, handling the gemnasium
Go dependency should probably documented as well.
What doesn't change:
- It's still necessary to push branch to
gemnasium
, and create a MR in that project. But switching to that branch is easier, and faster.
I recommend we use a convention in the gemnasium
project to show that a MR is a dependency of another MR in gemnasium-maven
or gemnasium-python
, and make it a lightweight MR. See gemnasium!161 (merged)
What are the relevant issue numbers?
gitlab-org/gitlab#292950 (closed)
Does this MR meet the acceptance criteria?
Changelog entry added-
Documentation created/updated for GitLab EE, if necessary -
Documentation created/updated for this project, if necessary -
Documentation reviewed by technical writer or follow-up review issue created -
Tests added for this feature/bug -
Job definition updated, if necessary -
Conforms to the code review guidelines -
Conforms to the Go guidelines -
Security reports checked/validated by reviewer
Edited by Fabien Catteau