Hello,
is it possible to add a transifex task to bamboo to automatically pull reviewed translations for all module translations stored in the OpenMRS transifex account? I found a info page to do this: https://www.transifex.com/blog/2015/transifex-bamboo-integration/
I asked the helpdesk, but they say that the engineering team can do this.
To do this we need to install the ātxā command (i.e. the transifex client) on the bamboo agents. I have no idea what the right way is to do this, and I assumed thatās something the infrastructure team would do. (Maybe @cintiadr can comment.)
Once the tx client has been installed I see that I have privileges to add this as a server capability, but I would hope that someone can tell me the right way to do this for the different agents.
Can you provide a little more detail about what Bamboo jobs need to be created, and what theyād do? That will probably help guide where and how the command line client needs to be installed.
We havenāt decided exactly when these will run (e.g. will it be a step within the module build, the module release, or a scheduled daily task).
But this will need to be done for each of the 15+ resources in OpenMRS Transifex.
(The command is something like tx pull --mode=REVIEWED, perhaps followed
by a git commit.)
-Darius
You were going in the right direction.
The bamboo agents are puppetised. The puppet and a vagrant box can be found in (https://github.com/openmrs/openmrs-contrib-bambooagent/). The repository is private because there are some sensitive information required by the agents. Adding the Bamboo capability is done by puppet as well (yey for magic).
Installing a pip package, like tx client, should be pretty simple to do in puppet. What Iād like to ask is about credentials (use bamboo variables? Commit the password somewhere and checkout? Create the file with credentials direct on the agent?). And you have to remember that each time you run a build you could be possibly running in a completely different machine.
(Iām on holidays, wonāt have a computer with me, but if you want me to do, I can do in a few weeks).
@cintiadr I just remembered this topicā¦ do you have any time in the upcoming couple weeks to set this up? (We will talk about Translating OpenMRS on the June 2 dev forum, so it would be neat to make some progress before that.)
Alright, will do it this weekend.
( I just need the username/password ;), otherwise I will just leave for the build to set it. )
I added the transifex client and some temp credentials to half of our agents(gw108 ones). It updated chrome, firefox and known_hosts files, so I will wait a couple of builds before deploying to gw107.
You can see an example of a āhelpā command:
I still donāt have a bot credentials to put there (~/.transifexrc file), I will try to sort it out this week.
But the projects probably will need a similar file.
Thanks for moving this forwards.
I think you can create an openmrsbot user on transifex, and join the openmrs project. (AFAIK you donāt need an admin to do anything there, but if so just ping me.)
I did create a bot user, joined the community there, and rollout this change to both agents.
I checkedāout allerrgyUI-api and did a status, it appears to be working just fine.
Thanks @cintiadr, this is great!
@teamprojekt, will you have time to do a proof of concept with one module of how we might make this work, before the developers forum on June 9?
Thanks @cintiadr. Is there a way to download the build? Because it looks like to get taken from tranifex for the build progress. I want to figure out what makes the ci with the properties-files in the github project-folders? Are they in the build or not? Must they be excluded from the repository? and so onā¦ for this it would be good to have the result of the build.
@darius: i have some free time and working on it
Sorry, I didnāt understand what you mean. That example build I created is doing a clone of (GitHub - openmrs/openmrs-module-allergyapi) and running ātx statusā command on the cloned folder. And the colour is green because this command didnāt return an error.
(If you have admin access to bamboo, hereās the link https://ci.openmrs.org/build/admin/edit/editBuildTasks.action?buildKey=PP-TT-JOB1)
As far as I understood, transifex configuration lives on the project github repositories, like, https://github.com/openmrs/openmrs-module-allergyapi/blob/master/.tx/config, right? It was already there, I didnāt touch it.
Also, I donāt really know which transifex commands one is supposed to run. I believe āpushā or āpullā? Transifex Help Center
(Oh, donāt to ātx initā. That one Iāve already set up on bamboo agents, it was the credentials)
ok, i understand. i thought that build creaded a final file of the allergyapi module. i have no access to the bamboo to view the result i can only view the log.
to import the tranifex files into to project folder we need the āpullā command. āpushā is for update the transifex source files if someone have made changes of it in github.
can you run a test with the āpullā command and give me access to view the result if @darius aggree?
@teamprojekt, you will need access to Bamboo in order to create plans there.
Please send a request to https://help.openmrs.org/ requiring access to bamboo in order to be able to setup the Bamboo plans to connect with transifex.
Please correct me if Iām wrong.
tx pull will download reviewed strings from transifex, and update the message_*.properties files we have on the git repository. So, the skeleton of your bamboo builds will be something like
tx pull
if there_are_modified_files_in_git {
git add message*.properties
git commit -m "Commiting files from transifex"
git push
}
If thatās the case, you probably should take a look on this thread http://stackoverflow.com/questions/3878624/how-do-i-programmatically-determine-if-there-are-uncommited-changes
The commit and push should work fine.
(I discovered that the tx push command is not working, but Iām fixing it in a couple of hours)
Yes today I have got access to bamboo. On Thursday morning I can start tests.
Great!
There are two different approaches (and it would be great to see a proof of concept of one or both by the Dev Forum on Thursday):
(I would start with the first one, and I think itās okay to do this to a module like Reference Application.)
+1 to option 1 above.
Mark
A few options:
If itās during release, the release scripts can be changed (note that it applies to all modules using the release from Bamboo).
You still have the work to get the job(or task) to the existent builds. And
here Bamboo doesnāt really help you 
When adding a job, you have the
choice to clone a job from another plan, but Iām not sure thatās what youād
want. Each job can run in possibly different machine, and they run in
parallel inside the same stage.
You either want a different stage with the new job, or a new task on the existent clean/install job. It could be a manual stage too, if desired.
Sebastian, you can send me the link to the script/bamboo plans you create, Iām happy to review them and give any tips that come to my mind.