[tor-bugs] #32746 [Internal Services/Service - jenkins]: translations repo and jenkins: reduce builds
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Dec 16 09:50:09 UTC 2019
#32746: translations repo and jenkins: reduce builds
-------------------------------------------------+-------------------------
Reporter: emmapeel | Owner: hiro
Type: enhancement | Status:
| assigned
Priority: Medium | Milestone:
Component: Internal Services/Service - jenkins | Version:
Severity: Normal | Resolution:
Keywords: lektor, l10n, jenkins | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Changes (by emmapeel):
* status: new => assigned
* owner: weasel => hiro
Old description:
> i have been thinking on how to use our resources more wisely regarding
> the translations and the websites.
>
> At this moment we are building many branches anew each time we push
> changes to our translations repository.
>
> This results on a situation when if there is people translating the
> support portal to Malayalam, which is still not published, and therefore
> making changes to the translation repository, the website is rebuild
> several times when there have been no actual changes to it.
>
> On the other hand, the quick updates are very useful for translators, and
> they use the staging version of the site a lot, since most of the
> translators work happens _before_ the website is released.
>
> But the lots of updates from translators and the amount of yet-incomplete
> languages that are built on the staging site causes some trouble to other
> web developers and confuses tehir development, also it makes staging hard
> to update regarding master because of the language configurations, etc.
>
> So I propose the following scheduling in lektor-jenkins-translation
> branches:
>
> master/staging/develop ---> when there is a change on this branches,
> we pull the translation repo and update all
> together
>
> translations ---> we rebuild when there are changes on the
> branch
> AND changes on the translation repo branch as
> well
>
> If we would want to update the translations in branches
> master/staging/develop, we should be able to do it simply by building
> from the web interface or similar.
>
> This way we can reduce the builds and make development less cumbersome,
> while also providing a quick preview of their changes to active
> translators.
>
> We can also prevent accidentally publishing incomplete languages, or
> removing languages from the 'preview' website.
>
> So, for this to be implemented we need to:
>
> * Make sure that the 'translations' branches are updated when their
> corresponding branch at https://gitweb.torproject.org/translation.git/
> gets updated.
> * Stop building the master/develop/staging builds each time there is a
> commit in their corresponding
> https://gitweb.torproject.org/translation.git/ branch, and only build
> when a commit is pushed to lektor itself.
> * Remove extra languages in staging and develop, and leave them only in
> translations.
>
> Please let me know what you think
New description:
i have been thinking on how to use our resources more wisely regarding the
translations and the websites.
THE PROBLEM
* At this moment we are building our websites many branches anew each time
we push changes to our translations repository, even with languages still
not enabled on production.
This results on a situation when, if there is people translating the
support portal for example to Malayalam, which is still not published, and
therefore making changes to the translation repository, the website is
rebuild several times when there have been no actual changes to it (the
pages for the actual website show still no Malayalam translations)
On the other hand, the quick updates are very useful for translators, and
they use the staging version of the site a lot, learning to test their
translations and thus fixing problems by themselves.
* The translations configuration gets on the way with the development
process
It makes work on staging hard, because there are a lot of changes in the
configuration files (databags/alternatives.ini, $website.lektorproject,
.htaccess, configs/i18n.ini) that should not get in the production
website.
The local and jenkins builds get longer, as people using staging will have
to compile all this languages too.
* The content of the staging site gets outdated, and translators are
translating newer content that is not updated on staging
As it is so hard to merge master changes to staging, the staging website
gets outdated on other code and is not useful anymore as a quick preview
site.
SOLUTION
So I propose to:
* new branches for translators, called translations, that get updated when
the dedicated branch at https://gitweb.torproject.org/translation.git/ is
updated, and follow master closely, differing from it only in changes to
the configuration files (databags/alternatives.ini,
$website.lektorproject, .htaccess, configs/i18n.ini).
* the following scheduling in lektor-jenkins-translation branches:
* master/staging/develop: when there is a change on this branches, we
pull the new translations from the translation repo, and update all
together
* translations: we rebuild when there are changes on the website repo,
AND changes on the translation repo branch as well
If we want to update the translations in branches master/staging/develop,
we should be able to do it simply by triggering a build from the web
interface.
This way we can reduce the builds and make development less cumbersome,
while also providing a quick preview of their changes to active
translators.
We can also prevent accidentally publishing incomplete languages, or
removing languages from the 'preview' website.
So, for this to be implemented we need to:
* Make sure that the 'translations' branches are updated when their
corresponding branch at https://gitweb.torproject.org/translation.git/
gets updated.
* Stop building the master/develop/staging builds each time there is a
commit in their corresponding
https://gitweb.torproject.org/translation.git/ branch, and only build when
a commit is pushed to lektor itself.
* Remove extra languages in staging and develop, and leave them only in
translations.
Please let me know what you think
--
Comment:
Assigning to hiro cause we talked about this last weeks. Also tried to
improve description clarity
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32746#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list