Today I manage to have the build of documentation with intersphinx to work only locally (this will avoid breakage when cross reference doc is added in the same topic).
Also I made it skip to check the demo URL (sometimes the server is not available and anyway this does not ensure that the URL is correct).
I uploaded on Issue 445341003: tryton-cookiecutter: Migrate to Heptapod - Code Review the generic changes that will be needed for the modules.
I tested the first delivery of the migration script of the bugtracker.
The open questions are what to do with the status, type and priority. Iām in favor of just keeping the type as label like type::crash.
There are still some issue that prevent to migrate some issues and we need to find a way to make plain text message compatible with the markdown format of GitLab.
@htgoebel has started to work on triggering the readthedocs build.
We still need to update the release scripts and create a script for developers to relaunch pipe with the secrets (like Stripe keys etc).
What will be the usage of such labels? Do we keep just for historical reasons or the idea is to force new users to introduce such labels? Iām not sure if we can enforce new users to introduce them for new issues.
We can not force to fill them but the group can try to fill it.
Personally I find it useful to prioritize the work. A crash is much more important to me than a new feature for example.
Ok, but does it make sense to migrate both tree fields as label with all the selections values?
Probably we just need to have: crash, bug, wrong behaviour, feature request, wish, performance and then merge old values to new values.
For the status Iām wondering if it will be possible to just add a label when a MR is created related to the issue. That will be able to link the issues on ātestingā status but also āin-progressā if there is some WIP text in the MR description.
For now octobus is migrating the status also as a label. But I think we do not need anymore because the open/close of GitLab is enough. So we will remove them after the migration.
I do not think we need neither something for the merge-request as a link will be made automatically (and they are displayed on the list) but also with GitLab we have assignation, reviewers etc. So the workflow and notification will be simpler as they are integrated.
Any way Iām in favor to try to minimize as much as possible to customization of GitLab to simplify the maintenance. The usage will tell us if we really need something more.
The CI configuration is almost ready (thanks to the help of @htgoebel). There is just a minor detail about the condition to trigger the documentation build.
For the record, we will need to create a doc/conf.py file for all modules (even if it is not yet updated to the current guidelines) and the configuration on readthedocs must be updated to define the python configuration file.
I finished testing the conversion, gitlab-ci and release scripts.
So there is just the bugtracker migration that is still pending before we can schedule the migration.
We will have a last check on the bugtracker migration on Monday. If everything is OK, we will schedule the migration to start on Friday 16th and except to finish it for Monday 19th.
I will post an announce Tuesday 13rd with the planning and some recommandation.