Add GitLab functionalities

[alessandrozago]

add code to handle Gitlab repository, add axios to project packages, add env variables for Gitlab

[alessandrozago]

Here the list of file changed or added in order to add the ability to use GitLab instead of GitHub as store repo. For each file, a simple description is given to describe its purpose within the application and the changes made for GitLab:

package.json (and package-lock.json)
added axios library and related dependencies for gitlab API calls.
.env.example
It's the file that contains the tokens for the repositories.
In addition to the original OTA_ENGINE_GITHUB_TOKEN variable, 2 new variables were added, OTA_ENGINE_GITLAB_TOKEN (used for the declarations-related repository) and OTA_ENGINE_GITLAB_RELEASES_TOKEN (used for the versions-related repository on which to save datasets in ZIP file format).
config/default.json
The file was modified by adding some new elements within the JSON structure of the file. In the "reporter" element, the same structure as "githubIssues" is expected for gitlab, but with the name "gitlabIssues". In the "declaration" field the name of the repository should be given in the form "<owner_name>/<project_name>"
engine/src/index.js
The file is the module related to the declarations tracking procedure (performed with the "npx ota track" command).
It has been modified by adding checks for the presence of GitHub and GitLab tokens. In either case, the relevant Reporter (for GitHub) or ReporterGitLab (for GitLab) classes are instantiated.
engine/src/reporterGitlab/gitlab.js
This file contains the definition of the Gitlab class and all its related methods for operating on a repository: getRepositoryLabels, createLabel, createIssues, setIssueLabels, openIssue, closeIssue, getIssue, addCommentToIssue, closeIssueWithCommentIfExists, and createOrUpdateIssue. It contains some settings such as the url where to reach the API of the GitLab repo you want to use (for example: https://gitlab.com/api/v4 )
engine/src/reporterGitlab/index.js
This file contains the definition of the Reporter class related to the use of GitLab. Within it, the related methods of the GitLab class described above are invoked.
engine/src/reporterGitlab/labels.json
This file contains, via a JSON structure, the list of labels that must be present on the repository in order to properly create issues. In case no labels are present in the repository thanks to this file they are automatically created during the first run.
engine/src/reporterGitlab/labels.test.js
It's a Javascript file used to test the file "labels.json" to verify that all the info inserted complains with the GitLab constraints.
engine/scripts/dataset/index.js
The file is the module related to the creation of releases and datasets (performed with the "npx ota dataset" command). It has been modified by adding checks for the presence of GitHub and GitLab tokens.
In either case, the relevant publishRelease (for GitHub) or publishReleaseGitLab (for GitLab) classes are instantiated.
engine/scripts/dataset/assets/README.templateGitLab.js
This file contains the template with all the texts and links that are used into every releases created during the "dataset" process.
engine/scripts/dataset/publishGitLab/index.js
The file contains the function to publish a release on a GitLab repository. This function creates a release and the zip file that is attached as asset link to the release.

[MattiSG]

Hello,
This pull request seems to be a duplicate of #1095, without handling the requested changes. In particular, #1095 (comment) and #1098 (comment) are copy-pasted.
As explained in #1095 (review), squashing commits is not welcome. Please have a look at the CONTRIBUTING guidelines.

@fabianospinelli @alessandrozago could you please clarify what is the relationship between #1095 and #1098, and close the potentially obsolete PR? The European Commission that employs you certainly provides enough resources to minimise the burden on maintainers 🙂

In general, introducing yourselves and your intentions is a welcome first step in open source collaboration before requesting maintainers to allocate time to review your work. You can find a good introduction to open source collaboration on the Open Source Guide, in particular for the case at hand in section 5, “How to submit a contribution”:

Before you open an issue or pull request, check the project’s contributing docs (usually a file called CONTRIBUTING, or in the README), to see whether you need to include anything specific. For example, they may ask that you follow a template, or require that you use tests. If you want to make a substantial contribution, open an issue to ask before working on it.

I am happy to have a video call with your team if useful.

[MattiSG]

Since merging code into the codebase entails long-term maintenance commitment, we will also need automated tests to pass before considering review.
If you'd like to speed up the review process for this GitLab integration to be available within your organisation, please consider sponsoring!

[MattiSG]

The account p2b on GitLab is reserved. Do you own it? If not, it does not seem appropriate to send notifications to that account by default.

[alessandrozago]

The url was only used as an example, but it was our mistake since we did not realize it was pointing to an existing account. This was removed, and replaced with an obvious fake url as an example. It will be available when the pull request will be updated.

[MattiSG]

Adding a dependency is not a lightweight change as it introduces security risks and maintenance burden. It seems this dependency is used only for 3 HTTP calls. Please use the native http module or one of the existing dependencies.
Please also use npm install --save to maintain alphabetical order and avoid future churn.

[alessandrozago]

This is solved and will be available when the pull request will be updated. Axios was removed and was replaced with node-fetch (already used in the project).

[MattiSG]

Do not keep commented-out lines, please erase them.

[alessandrozago]

This is solved (along with other similar cases) and will be available when the pull request will be updated

[alessandrozago]

Hi @MattiSG , thank you for the feedback and the resources provided.
As discussed, the obsolete pull request #1095 was closed, I opened an issue: #1099 and I am working on fixing the issues mentioned in the comments.
We expect to complete the issues for the first weeks of September. I will update the pull request when ready, or if there is any other update.

[MattiSG]

This still mentions GitHub when it's related to GitLab 😉

[alessandrozago]

This is solved and will be available when the pull request will be updated.

[MattiSG]

Do you really need to duplicate this file? It seems to be a complete duplicate of the GitHub reporter labels. Why not simply import the same file? 🙂

[alessandrozago]

The color format is different; although it is just the "#" character at the beginning of the color code.
We could find some way to use the same test file and simply add the "#" character via code for GitLab, but I do not think this is a good solution.
Considering GitHub and GitLab use different formats, it's also possible they might change in the future. To us, it makes sense to have them separate.
Please let us know if you prefer to unify the tests anyway. In this case, it might also make sense to move the "labels.json" in a more generic directory/path.

[MattiSG]

This seems to be a complete duplicate from the GitHub template. Duplicating this file means that they are more likely to not be updated properly. Is there a reason for not simply importing the existing template? 🙂

[alessandrozago]

The only change in that file is, in fact, just a variable name (compared to the GitHub counterpart).
To use a single template, we could:

1. pass that variable as an input for the template and modify the code in the Release generation to handle both the GitHub and GitLab parts
2. use only one variable in the configuration file for "versionsRepositoryURL"; this will make the publishing part not consistent with the reporting part, where GitHub and GitLab use different configurations (reporter.githubIssues and reporter.gitlabIssues).

Please let us know if there is a preferred solution, otherwise we could proceed with n°1.