[meta] VersionEye integration
We're going to integrate the capabilities of versioneye into GitLab. It can report for every commit:
- CE: version
- CE: security
- EE Option: License
This can be achieved by sending a dependency file (like
Gemfile.lock) from GitLab to VersionEye.
GitLab Version Service
The GitLab Version Service has a database with version, security and license information. It is simply an instance of VersionEye Enterprise.
GitLab instances will send it their dependency files and it will return whether those are outdated, whether there is a security vulnerability for one of them and what their licenses are.
The information returned depends on the type of instance:
- GitLab CE instances will need to sign up with the service and will only receive version and security information
- GitLab EE instance should not need to sign up with the service (use the license instead) and receive the same information UNLESS they are..
- GitLab EE instances with an EE option for License information. These instances also receive license information.
The API of VersionEye can be used to create API keys.
Changes to the License App
Ideally the license app triggers the versioneye API to create an API token.
Possibly the token is part of the license file, negating the need to exchange API tokens and making this functionality very much 'out of the box'. This does require more development time.
The license app needs a new product for the License-information EE option.
Changes to GitLab CE
GitLab CE will need the following additions
- a pre-sign up interface for version, security information that allows the user to register at version-service.gitlab.com (or whatever domain we choose to use)
- version and security information available in merge requests
- version and security information available for any commit (On demand for all branches but master, I'm thinking, to avoid intense load on the version servers)
- admin ability to opt-out of this feature to avoid sharing data externally in organisations that are not willing to send their dependency files to our version service
- same as CE
- plus the ability to automatically register to version-service.gitlab.com with a license
- plus license information available in merge requests and any commit
Enterprises have a lot of internal dependencies. To be able to have those, they'll need an internal version database. This is offered by versioneye enterprise.
We will start by building the EE option part:
- Set up GitLab's VersionEye instance
- Build the connection to the license app
- Build the integration of license information in GitLab
- in merge requests
- in commits
- ==> EE integration done
- Build an app to signup and get an API key to GitLab's version server
- Build the version and security integration in GitLab
- in merge requests
- in commits
- ==> Full CE integration done
Changes to EE/CE UI:
- EE: Display License information in Projects list view #857
- EE+CE: Display GitLab Service information in Merge requests list view #860
- EE+CE: Display GitLab Service information in Merge requests detail view #863
- EE+CE: Display GitLab Service information in Commits list view #861
- EE+CE: Display GitLab Service information in Commit detail view #862
- EE+CE: Add option to activate GitLab Version Service to the administration panel of a repository #864
- EE+CE: Settings panel for GitLab Version Service #865
New site: shield.gitlab.com
This is for CE users only.