Automate language pack export for deployment script

[Alexander Obuhovich]

Deployment script is a real time saver when it comes to deploying an update to dev/live servers.

However it still requires user actions in terms of exporting latest language pack and comparing it to one we have right now.

Right now I'm doing this (see below) to export language pack for each task:

1. click on "Regional" section in Admin Console
2. select English language
3. click on Export toolbar button
4. enter language pack filename
5. click on "Select None" to uncheck all modules
6. click on "Custom" to select module which I want to export
7. click on Export button on toolbar

These are horrible 7 clicks I need to make just to have "Custom" module's language pack being exported.

I'm proposing to perform an export of all language packs from modules, that have "project_upgrades.sql" file when "Synchronize" button is pressed in "System Tools" section.

As a result we'll have a separate language pack for every module, that is used by deployment script.

--
Best Regards,

http://www.in-portal.com
http://www.alex-time.com

[Alexander Obuhovich]

As of part 2 of my post I'm proposing to add "SSHCommand" setting to system settings or to /system/config.php

Then in deployment script we can use this setting to execute commands on Host OS (e.g. Windows/Mac) from Guest OS (e.g. Linux) installed on Virtual Machine, where In-Portal is installed.

If you're using Windows as your Host OS, then it you need to install SSH server separately.

However if anybody can find a way to run commands from Guest OS on Host OS via VMWare tools or something, then please let me know.

[Alexander Obuhovich]

Here is the patch and task: http://tracker.in-portal.org/view.php?id=1445

Ready for testing.

[Dmitry A.]

Hi Alex,

I am not sure I fully understand why Host OS is evolved here. Can you please explain in full details how it works?

The way I see it:

1. we add new phrases to DB where In-Portal is installed (Guest OS) by adding phrases via Admin or so

2. then we can automatically-dump/export the DB into language pack (english.lang) for each module (once you click Synchronize or we can have new button if needed) - ie. for custom module only

3. then it's Committed as part of all changed files in the task and Deployed to everyone else.

DA

[Alexander Obuhovich]

I am not sure I fully understand why Host OS is evolved here. Can you please explain in full details how it works?

Because tool, to compare changes made in new language pack (/system/export/Custom.lang) and old language pack (/modules/custom/install/english.lang) is located in Host OS. I'm too lasy to click multiple buttons, that's why I made ONE button to do both:

• language pack export for every module featuring in deployment script
• compare tool invoking that would as result update module's language pack file, that will be commited later

The way I see it:

1. we add new phrases to DB where In-Portal is installed (Guest OS) by adding phrases via Admin or so

2. then we can automatically-dump/export the DB into language pack (english.lang) for each module (once you click Synchronize or we can have new button if needed) - ie. for custom module only

3. then it's Committed as part of all changed files in the task and Deployed to everyone else.

Between 2 and 3 you actually compare exported language pack to one you have and add/remove phrase changes made by you. I can't automate that part.

[Dmitry A.]

Thank for reply Alex.

I still not clear why either of these two options don't work for us:

1. You can use DIFF too on GuestOS and compare 2 files (current and temporarily) or something like we do with Admin CSS on upgrade

2. Do we really need to compare anything - consider when Synchronize is pressed we Save all changes (overwrite current) from DB (all new and/or changed phrases) to /modules/custom/install/english.lang on Guest OS since it's setting there (an will be committed from there).

DA

[Alexander Obuhovich]

1. You can use DIFF too on GuestOS and compare 2 files (current and temporarily) or something like we do with Admin CSS on upgrade

Since this task is performed several times per day by each developer I seriously doubt that you want to work with b/w diff form command line (on guest os) comparing to nice looking GUI tool (on host os).

2. Do we really need to compare anything - consider when Synchronize is pressed we Save all changes (overwrite current) from DB (all new and/or changed phrases) to /modules/custom/install/english.lang on Guest OS since it's setting there (an will be committed from there).

Consider this test case:

• developer A performed SVN update, but haven't imported language pack changes made by developer B
  
• developer A adds some phrases
• developer A clicks on synchronize button and, as you suggest, overwrites all changes made by developer B
• developer A commits his changes even not looking at changes made to /modules/custom/install/english.lang file

I prefer to take precaution and let developer decide what gets overwritten and when. Plus /modules/custom/install/english.lang file isn't writable from web server.