Skip to content

Add gemnasium as a git submodule, move builder package

Fabien Catteau requested to merge gemnasium-as-submodule into master

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
  • Move builder package to gemnasium
  • Import main.go from gemnasium instead of using common/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 match gemnasium

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 of gemnasium-python and changes its codebase, and push everything at the same time: updates to the codebase of gemnasium-python as well as the new ref for gemnasium. It's harder to achieve the same with git submodules.
  • Switching to a branch of gemnasium takes way less time than running go get to depend on that branch.
  • vrange scripts can be copied directly from the gemnasium 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 in go.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?

Edited by Fabien Catteau

Merge request reports