We would like to implement a better testing-system for transifex (and other Fedora tg apps?), and not directly push untested stuff to the production instance(s).
Is it possible to set up a test server for transifex where we could
1) push a new RPM update of transifex to a Yum repository
2) yum update transifex
3) Set up test data, e.g. run a script to sync VCS instances from live server (save having to check out every single module again)
4) Do testing
We could do all this locally, but it's a LOT of data (sandboxes) involved, which would be easier to move around if it was on a test server..
I'm also open to suggestion to better approaches of handling this :)
This can all be done on publictest10 to anyone who's in the sysadmin-web or sysadmin-test can do it.
Concerns I have:
1) in the past transifex was run in production but on a test box. thats a no no
2) How will you test vcs instances exactly? You could set up one locally. Also the production ssh keys need to not be on the testing server for security reasons. Its probably best to also setup test vcs instances, one less documented feature about fedorahosted is that the repos are exported via rsync: rsync fedorahosted.org::
Replying to [comment:1 mmcgrath]:
Ok, I'll look more into this :)
Concerns I have: 1) in the past transifex was run in production but on a test box. thats a no no
Agreed, this is impractical anyway as we don't have the keys on the test boxes.
Creating a set of test vcs instances is probably a better solution, and using rsync is a great idea! Then we can test commits and changes in the 'upstream' repo much easier, and still use very similar settings to our live instance. From there we can develop a set of test-cases that can also be semi-automated.
I am a bit concerned though about the amount of data we're moving around with rsync, as this will bring in all history&branches for a repo. I'm not too familiar yet with how these systems are linked, so this might just be me being overly careful.
We probably have to choose a wise subset (e.g. one of each vcs). We're also porting some of the statistics functionality over to tx, so we need not only one of each vcs, but one of each "build-system" such as intltool, gnome-doc-utils and publican.
Side note about this, we now have a staging environment we can use to test this. Next time it's needed (and we'll be using it for the deployment coming up) let me know and I'll make sure whoever needs it gets trained. They just need to be in sysadmin-web.
Login to comment on this ticket.