Our current development infrastructure is aging and become more complicated to maintain.
Rietveld is mainly no more maintained. Our drone fork is stuck in version 0.8 when upstream is at 2.91. Roundup is not really good for searching.
There have been already many discussion about this:
- Taking care of infrastructure: code review
- Using a mono-repository - #5 by pokoli
- Replace Rietveld (#2178) · Issues · Tryton / Tryton · GitLab
Octobus tells us that we are eligible to be hosted freely on https://foss.heptapod.net/. But if we are going to be hosted there, we proposed to make an annual contribution in the form of support contract by the Foundation.
In order to benefit from the full GitLab feature, it is required that we merge the Tryton’s repository into a mono-repository. We have already discussed such possibility on Using a mono-repository - #5 by pokoli.
Globally the idea is to keep the directory structure we have with
tryton-env repository (to ease partial clone with ConvertExtension).
There are still some points that need to be clarified but Octobus has experiences with such tasks:
Tag naming convention
Clean content (remove .drone.yml, etc.)
Heptapod workflow is based on merge request. We think we should keep the strategy to have a linear history on merge.
We have identified one issue with the current workflow which is that there is no fork but a single repository with topics. So this force new user to request access to the repository in order to make a merge request. But this could be solved with the implementation of user namespaces for topics. We have a quotation from Octobus to implement this feature.
User namespaces for topics
The tests will be run by the CI/CD of Heptapod. According to Octobus the load of our tests should not be a problem for their hosting. But if necessary we could provide extra hosts to run some jobs.
Indeed the main difficulty with the tests is the management of the installation of locale dependencies when running inside
tox the tests of one module (that depends on other). For now we are relying on https://trydevpi.tryton.org/ to find and clone other modules. But it seems we could fill a directory with archives of every modules (probably just
sdist) and use it as
--find-links option of pip.
The second one is that the jobs run the tests only for modified modules. This could probably be done with a script that retrieve the list of modules from the mercurial output.
We may need an option (for core devs) to trigger the tests for all modules.
In addition to tests we need also jobs to run flake8 and isort on the modified files. And we could also add a weekly job to run tests for all modules (last Python version and sqlite only).
The issues need to be imported in Heptapod. Normally we should be able to keep the same ID for the issues (which may allow to rewrite the commit messages to include link to the migrated issues).
The attachment on the issue have also to be imported.
Roundup user will be automatically registered as Heptapod users.
GitLab can be integrated with readthedocs but as our documentation is divided per module. The generic plugin will probably need to be customized. Also we need that new module can be done from the configuration UI of Heptapod and readthedocs.
The scripts used to make a release must be adapted to use the mono-repository design.
The other projects like relatorio, python-sql, chronos and goocalendar will be migrated to Heptapod as sub-projects. The same migration for issues will be performed and the repository will be just pushed as-is.
We have a quotation that we will submit to the Foundation Board from Heptapod for the tasks:
- Repository migration
- Data import from roundup
- CI/CD configuration
- topics namespaces
I expect to have to spend about 3-4 days to follow the process and provide information with Octobus.