bamboo setup for transifex


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:

I asked the helpdesk, but they say that the engineering team can do this.

1 Like

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.)


1 Like

You were going in the right direction.

The bamboo agents are puppetised. The puppet and a vagrant box can be found in ( 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).

1 Like

@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.

1 Like

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 ( 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

As far as I understood, transifex configuration lives on the project github repositories, like,, 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’?

(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 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

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)

@teamprojekt were you able to get bamboo access?

-Darius (by phone)

Yes today I have got access to bamboo. On Thursday morning I can start tests.


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):

  1. (automatically pull in translation changes, frequently:
  • as part of a module’s usual build, add a phase that does: tx pull, check if any changes, if so git commit + push
  • or alternately do this as its own build that runs nightly
  • @cintiadr, if we’re going down this path, which approach would be the least maintenance work to apply to many modules?
  1. leave it up to the module owner to apply changes manually, but don’t let them release unless they have done this:
  • as part of a modules release step, do a tx pull and fail if there are any changes

(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.


A few options:

  • create a script in and do a checkout of that repo before running the script. That means every commit to the script will be pick by the next build (make sure to remove the build trigger from the contrib repo commits). It looks simpler to me.
  • create the script in, and add the script to the agent running the builds. This will mean that the changes will be propagated only after we re-apply puppet to Bamboo agents.

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 :confused: 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.