Difference between revisions of "On Boarding the Automation Job Without Jenkins Plugin"

From Lingoport Wiki
Jump to: navigation, search
(Created page with "=== LRM Pre-requisite: Licensed Group === The group must have been licensed prior to on-boarding projects for a Terms_and_Definitions#gr...")
 
(No difference)

Latest revision as of 16:47, 22 March 2018

LRM Pre-requisite: Licensed Group

The group must have been licensed prior to on-boarding projects for a group. For instance, to add a job to the group 'blue', the group 'blue' must be licensed. When LRM is installed, a group and license from Lingoport is required. If the system is installed by the Stack Installer, a valid license is required and the group is created automatically.

  • A Group is typically composed of projects using the same type of repositories (SVN for instance)
  • A Group's projects typically are sent to the same Translation Vendor (Lingotek for instance)
  • A Group's projects locales are typically the same (for instance, fr, de_DE, no, ja, es_SP)
  • A Group's locales mapping is unique! fr maps only to one possible locale in the translation process. It cannot map to both fr_CA and fr_FR

To see all groups installed and their details (from the command line):

>java -jar <HOME>/lrm-server-x.y/lrm-cli.jar --list-groups

To create a new group (must have the license from Lingoport):

>java -jar <HOME>/lrm-server-x.y/lrm-cli.jar --create-group --groupname <string> --number-of-licenses <number> --date <string> --license-key <number>

Jenkins Part

See one of:

    • $LRM_HOME/bin/job_automate.sh
    • $DASHBOARD_HOME/bin/job_lite.sh
    • $DASHBOARD_HOME/bin/job_lrm_and_lite.sh

In Jenkins, under the 1-Automation Tab, select New Item

Automation tab new item.jpg

  • Make a copy of
    • Lingoport.SampleLITELRM (if this project uses Globalyzer and LRM)
    • Lingoport.SampleLite (for Globalyzer only)
  • Set the name of the new job to <groupname>.<projectname>
  • Create the Job
  • Select the new job from the list and Configure new job

New project configure.jpg

  • Source Code Management: Set up Repository, Credentials, and Branch

Source code management.jpg

  • Under Build, comment out the script.
  • The LITE_PROJECT_DEFINITION is probably incorrect. This does not need to be corrected at this time.
  • Save

Build.jpg

  • Build Now

Build now.jpg

  • In a console window, make sure that <HOME_JENKINS>/jobs/<groupname.projectname>/workspace/ contains the information from the code repository

LRM Project Creation

Now that the files are on disk at the proper location, use lrm (an alias should have been created by the Stack Installer) to create the project, verify, and adjust the project definition:

  • Go to the command prompt on that machine and create the LRM project by copying the ProjectDefinition.xml of an existing LRM project and replacing the relevant elements:
    • group-name (In this example: Acme)
    • project_name (In this example: Weather)
    • top-level-dir (/var/lib/jenkins/jobs/Acme.Weather/workspace/Weather-master/resources)
    • pseudo-locale
    • target-locales
    • etc.
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<lrmconf>
  <model-version>3.2</model-version>
  <project-name>Weather</project-name>
  <group-name>Acme</group-name>
  <project-desc>This project contains resource files of all types for baseline testing</project-desc>
  <top-level-dir>/var/lib/jenkins/jobs/Acme.Weather/workspace/Weather-master/resources</top-level-dir>
  <detect-errors>
    <!--If set to '0' (false), then the 'missed translation' error will not be triggered-->
    <!--if the non-base file has the same text as the base file.-->
    <!--Missed Translation error will still occur if the base file has a different key or if-->
    <!--the base file has changed since it was last prepped.-->
    <missed-trans-error>0</missed-trans-error>
    <parameter-mismatch-error>1</parameter-mismatch-error>
  </detect-errors>
  <!--Target locales are the locales where the corresponding resource files will be translated. -->
  <!--These target locales are mutually exclusive of the base (default) locale-->
  <target-locales>
    <locale>fr_FR</locale>
    <locale>de_DE</locale>
  </target-locales>
  <track-back-locale>br</track-back-locale>
  <pseudo-locale>eo</pseudo-locale>
...


The lrm alias should have been set up by the Stack Installer. If not, set it up at the command line: alias lrm='java -jar /var/lib/jenkins/lingoport/lrm-server-x.y/lrm-cli.jar'

  • Run lrm -cp -gn <group_name> -f newProjectDefinition.xml
  • If the project has been created successfully, then Project Inspect reports should have been created for each locale. Open these and verify their contents
  • If necessary, modify the newProjectDefinition.xml file, run the update-project command, and verify again the results until you are satisfied.

lrm -up -f newProjectDefinition.xml

LRM Project Configuration

After creating a new project, some files need to be modified In the <HOME>/Lingoport_Data/L10nStreamlining/<group_name>/projects/<project_name>/config directory:

Edit <HOME>/Lingoport_Data/L10nStreamlining/<group_name>/projects/<project_name>/config/config_email_recipients.xml which specifies who will get messages (prep kits, import kits, errors, etc.)
Edit <HOME>/Lingoport_Data/L10nStreamlining/<group_name>/projects/<project_name>/config/config_vcs.properties. This specifies SVN or Git properties (Note: Beware of "origin/master", "master", and "origin master" for the VCS_GIT_BRANCH: It depends on the systems)

Other files may be copied under this directory if the project's configuration is more specific than the group configuration files, located under <HOME>/Lingoport_Data/L10nStreamlining/<group_name>/config:

Edit <HOME>/Lingoport_Data/L10nStreamlining/<group_name>/config/config_due_dates.xml: How the due dates are calculated.
Edit <HOME>/Lingoport_Data/L10nStreamlining/<group_name>/config/config_l10n_vendor.properties: The way to send files to a vendor (Lingotek, WorldServer, or FTP configuration)

Finally, update the <HOME>/Lingoport_Data/L10nStreamlining/config/config_email_global.xml file and the following values.

<email-sender>sender@acme.com</email-sender>
<sender-password encrypted="false">agoodpassword</sender-password>
<!--This is the Dashboard URL used as the link destination for the email Log In button -->
<dashboard-url>http://www.acme.com/dashboard</dashboard-url>

For more information, see Project Configuration Files

Jenkins Part Two

The underlying components have been initialized. Let's finish the Jenkins on-boarding process:

  • Go back to the new job Configuration and edit the Build - Execute Shell section.
    • Enable the commented out script by removing the preceding '#'. This might be:
      • $LRM_HOME/bin/job_automate.sh 30
      • $LRM_HOME/bin/job_lite.sh
      • $LRM_HOME/bin/job_lrm_and_lite.sh
    • Set the LITE_PROJECT_DEFINITION file to the correct location
    • Save
  • Build Now: The Lingoport Dashboard should be updated, some files may be pseudo-localized.
  • Check the console output for errors.

If the Lingoport Dashboard is not updated, then permissions need to be set.

  • On the Dashboard, login as admin with default password admin
  • On the console, edit <JENKINS_HOME>/Lingoport_Data/Dashboard/Projects/<groupname.projectname>/sonar-project.properties to get sonar.login and sonar.password.
  • On the Dashboard, go to Administration -> Security -> Users and add a user with the same login and password.
  • Back in Jenkins and the job, select Build Now again. The Lingoport Dashboard should be updated, some files may be pseudo-localized.
  • Check the console output for errors.

If things do not look correct or the Lingoport Dashboard has not updated then contact support@lingoport.com before trying to move forward.

Verification

  • Check the Jenkins job follows the form <group_name>.<project_name> (i.e. Lingoport.javademo)
  • Check that the job Configuration has
    • Multi-Project Throttle Category set (check box checked on MAIN for instance)
    • Build Trigger set(one must be set, either on each push or every day)
    • Set jenkins user build variables is indeed checked
    • Build is an Execute Shell and the shell contains $LRM_HOME/bin/job_automate.sh
  • Post Build Actions include the Discard Old Builds with "Days to keep builds" set to 10

Possible Job Creation Helper

If a set of repositories tend to follow the same resource structures, you may want to create a template project definition with some tokens to be replaced, so that a 'Job Creation Helper' can on-board the job from Jenkins in a more automated fashion. For instance, if you have a set of projects

  • with .properties,
  • with the base files in U.S. English,
  • with the base files ending in _en.properties
  • with the same target locales
  • with the same directories to ignore,

You could create a TemplateProjectDefinition.xml and a way to replace certain tokens so the projects are created from Jenkins. This requires a bit of customization. Lingoport may help you set that up.

Next Step

On Boarding the Nightly Job