Triggering rtd-merge job after release-merge?
|
Robert Varga
Hello,
while resolving docs.opendaylight.org links to MRI projects, I have come across a slight problem with having versions propagated. Since MRI projects produce versions rather more often than their documentation changes the admin interface does not see the new versions, for example in https://readthedocs.org/projects/odl-controller/versions/. The list of versions is updated by $project-rtd-merge jobs, hence for MRI projects (for example controller), I need to trigger https://jenkins.opendaylight.org/releng/view/controller/job/controller-rtd-merge-master/ whenever https://jenkins.opendaylight.org/releng/view/controller/job/controller-release-merge/ succeeds. The idea is that controller-release-merge produces the version tag in git repo, and controller-rtd-merge-master then picks it up and lets ReadTheDocs know about it. Is there a way to create this trigger in releng/builder's JJB? Thanks, Robert |
|
|
|
Anil Belur
Greetings Robert: I checked the JJB code for the controller rtd-merge-master, the Gerrit triggers seem to work as expected triggering the required jobs. Ex: Job #4 was triggered from a merge from the change request 94725. From what I understand, the release merge job are responsible for promoting the staging repo, which should create a new version ex: 3.0.6 in RTD.org/$project. Every new release on the self-managed projects would require activating the new version on RTD (as admin). That should trigger a new build to update the docs for the $project. I am not sure if triggering rtd-merge as a downstream job on every release merge would be the right way for this. Will need to dig in a bit and get back to you. +docs folks on any suggestions. Cheers, Anil On Wed, Jun 9, 2021 at 7:27 PM Robert Varga <nite@...> wrote: Hello, |
|
|
|
Guillaume Lambert
Hello
+docs ML
I’ve noticed too the issue pointed by Robert. Because of inter-sphinx cross-references, this sometimes prevents the docs project from building fine, when old subprojects versions are removed because objects.inv configured in docs/conf.py can become suddently unavailable.
So automating the whole process would definitely make sense in my opinion, at least when distributions are created from integration/distribution. To my knowledge, only the account “odl-rtd” have the admins rights on all OpenDaylight subprojects in RTD. And I cannot see how this can be automated.
Hope this helps Guillaume
De : Anil Belur [mailto:abelur@...]
Greetings Robert:
I checked the JJB code for the controller rtd-merge-master, the Gerrit triggers seem to work as expected triggering the required jobs. Ex: Job #4 was triggered from a merge from the change request 94725. From what I understand, the release merge job are responsible for promoting the staging repo, which should create a new version ex: 3.0.6 in RTD.org/$project. Every new release on the self-managed projects would require activating the new version on RTD (as admin). That should trigger a new build to update the docs for the $project.
I am not sure if triggering rtd-merge as a downstream job on every release merge would be the right way for this. Will need to dig in a bit and get back to you.
+docs folks on any suggestions.
Cheers, Anil
On Wed, Jun 9, 2021 at 7:27 PM Robert Varga <nite@...> wrote:
_________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. |
|
|