Bonjour,
I’ve been informed today that a working group is studying software forges and how they could be used in academia in France. The summary of their progress is public (rare & appreciated ). It’s all in French but I will translate for the benefit of non-French speaking people participating in forgefriends so that they can comment and contribute (this is par of the effort to improve linguistic diversity).
https://www.ouvrirlascience.fr/the-free-and-open-source-software-expert-group/
@sibichakkaravarthy this may be of particular interest to you in the context of the ongoing involvement of AIR on the general topic of reproducible software?
Cheers
In the folllowing, HER means Higher Education and Research.
title: “Forges: needs analysis, identification of current limitations, proposals for action”.
author: "WG 2 : Tools and good technical and social practices
date: April 2022
Needs
Creation of public and private projects, to allow the design of the software internally and its public release when its level of maturity allows it.
Version management
- commit, branches, releases
- collaboration (merge request, history, sharing etc)
- backup/archiving
Ticket management
Continuous integration for various platforms (allow to easily create deliverables from the source code).
For developers, the goal/need is also to allow testing/validation of code for different OS/config as development proceeds. The “reproducible” aspect offered by the CI (via images in registries for example) is also very important.
Importance of the possibility to have interactions with users outside HER (tickets, code contribution, documentation).
Integration of the state of the art in software engineering (static code analysis, testing, quality assurance, documentation, etc.).
Also use these platforms for collaborative writing of documentation, web pages, using tools for transforming structured text files (markdown, asciidoc). Requires continuous integration with transformation tools and deployment on a public area (such as github/gitlab pages).
Use of standard tools to facilitate training, aculturation.
List of “public” HER forges
INRIA (gitlab)
CNRS (gitlab)
IRD (gitlab)
CIRAD (gitlab)
INRAE (Gitlab)
RENATER (fusionforge)
Laboratories or universities
*Put here the (public) forges of labs/universities, if you know any.
gitub.u-bordeaux.fr Accueil · Wiki · Administrator / infosgithub · GitLab
In Lille, to check (access without auth, where you can have an account and make projects) : gitlab.univ-lille.fr, gitlab.cristal.univ-lille.fr, gitlab-etu.fil.univ-lille.fr, gitlab-ens.univ-lille.fr, gitlab-fil.univ-lille.fr
Current forge features
Identification | Outside HER | Continuous integration | Other services |
---|---|---|---|
gitlab.inria.fr | Inria | external sponsored guests | GitLab-CI |
src.koda.cnrs.fr | CNRS (Janus) | No | |
gitlab.in2p3.fr | EduGAIN | external users | ? |
plmlab.math.cnrs.fr | Renater | No | ? |
forge.ird.fr | Renater | CRU accounts - others in progress | gitlab pages |
gitlab.cirad.fr | Renater | No | Gitlab-CI |
sourcesup.renater.fr | Renater | No | ? |
gricad-gitlab.univ-grenoble-alpes.fr | UGA | Yes : on simple registration (without validation) but with limited permissions. | Gitlab-CI (with shared runners) |
gitub.u-bordeaux.fr | Université de Bordeaux | After | |
gitlab.lip6.fr | LDAP LIP6 | No | GitLab-CI (without public runner) |
gitlab.huma-num.fr | HumanID | No (but flexible in reality) | GitLab-CI |
Limitations
The main current limitation of existing forges is that it is often not possible for someone outside of HER to access them. Most of the forges require an identity federation type access (at the HER or structure level) to have access to all the functionalities.
Although some allow the creation of external accounts, they are often difficult to access (for example, for gitlab.inria.fr, an external account must be “sponsored” by a member of an Inria project team) and limited (gitlab external account operation which does not allow the creation of one’s own projects). It is therefore often impossible, or difficult, to propose changes with this kind of account (because it requires making a fork of the original project, thus creating a project of one’s own on the forge). Reporting a bug requires to have obtained an account beforehand, which can be very difficult.
It is possible to synchronize local forges (HER) with public forges (gitlab.com or github.com). However, you lose the centralization of information. You have to disable the public ticket system in this case to keep the tickets on the local forge. But this solution is not practical for contributors, who have to use two accounts (one for tickets, bug reports, suggestions) and another one for contributions (code, docs).
Another limitation is the absence of a single showcase for the software production of the HER, or even of a single EPST or university. This limitation can be compensated by a catalog of HER software production (see WG 1).
Speaking of showcases, there are currently many forges in which the creation of public projects is not “validated”. So we find public projects that range from “hello word” to a big application that has been maintained for years. There is no filter. This is a problem for a showcase (which is meant to highlight projects of a certain “quality”). It is not a problem if you want to provide a technical platform.
The lack of control (or the weak control) of the project creations makes the management of these complicated. It is difficult (impossible?) for administrators to determine which projects should be kept or not. Another difficulty: the management of user accounts according to the evolution of their status (departure/arrival from/in the HER etc ).
Another complicated point to manage (due to the possibility of registering on the platform without validation) is spam via snippets and issues for public projects.
Another important point: offering runners for continuous integration raises security issues. Public forges have reduced or simply disabled accounts that allow free use of CPU time on runners.
Actions
- To be discussed Encourage HER forges to adopt identity federation such as eduGAIN. This would facilitate contribution to existing projects among HER staff. (N.B. For non-HER contributions, would allowing OAuth authentication via GitHub.com be feasible?)
- To be discussed Support Forgefriends, a project to enable forge federation. The federation of forges could, in the long run, solve some of the limitations mentioned above, by allowing people to contribute to a project from the forge of their choice. There is also ForgeFed, linked to fediverse, to be seen.
- Identify possible training courses in the HER concerning the use of forges (licenses, git, continuous integration, quality assurance, etc.) for a technical audience (computer scientist) or not (non computer scientist): DevLog, GDR GPL, internal training IRD, CNRS, INRIA (experimentation and development service, SED). (see Je code : Les bonnes pratiques de développement logiciel)
- To provide ideas for a policy regarding the opening of the code
Ideas (to be explored)
Use of OpenID? OpenID Connect OmniAuth provider | GitLab
What about GitHub?
The CodeGouv platform references 2351 repositories under the HER.
93% of these repositories are hosted on GitHub. The 168 remaining repositories use mostly gitlab instances : forgemia.inra.fr (16), framagit.org (11), git.unicaen.fr (21), gitlab.inria.fr (76), gitlab.com (27)…