https://wiki.lingoport.com/api.php?action=feedcontributions&feedformat=atom&user=RwilliamsLingoport Wiki - User contributions [en]2026-04-30T19:04:51ZUser contributionsMediaWiki 1.43.3https://wiki.lingoport.com/index.php?title=Transform_Framework&diff=99871Transform Framework2026-04-03T19:12:47Z<p>Rwilliams: /* Use the transform framework */</p>
<hr />
<div>Localyzer supports a number of file types out of the box (See [[Supported Resource Bundles]]). However, other file types may represent user facing strings to be translated. In that case, some customization is required to on-board those projects. <br />
The '''bash script transform framework''' facilitates the customization. <br />
<br />
= Analyze the file types = <br />
If the file types fall into a category not supported by Localyzer out of the box, the first thing to do is to see what is the closest file types supported by Localyzer and TMSs/LSPs/MTs.<br />
<br />
= Use the transform framework =<br />
The transform framework needs '''three scripts'''. The three scripts need to be in a repository, under a directory whose name will be used to identify the transform. <br />
<br />
The three scripts to write are:<br />
* '''transform_from_repo.sh''': How to transform the files from the repository so they fit into an LRM supported file type<br />
* '''transform_to_repo.sh''': How to transform translated/pseudo-localized files in an LRM supported file type into the repository file type<br />
* '''transform_files_list.sh''': How to transform the file names from the LRM supported file naming into the repository file naming<br />
<br />
Each of these script can in turn call other scripts as required.<br />
Be sure that when calling other bash shell scripts to use "source" or "." to do so. Command Center will automatically set the above three mentioned scripts to executable when used but does not do so for other scripts that may be added as part of the transform.<br />
<br />
if source "${TRANSFORM_DIR}/additional_code.sh" "${arg1}" ; then<br />
echo "Successfully executed ${TRANSFORM_DIR}/additional_code.sh"<br />
else<br />
echo "Failed to execute ${TRANSFORM_DIR}/additional_code.sh"<br />
fi<br />
<br />
For example, under<br />
* https://github.com/Lingoport/CommandCenterConfig, the main branch<br />
a number of transform directories indicate what transform are available, in other words, what directories have those three scripts. <br />
<br />
For example, for the <code>txt2prop</code> transform, the directory is located :<br />
* https://github.com/Lingoport/CommandCenterConfig/tree/main/transforms/txt2prop<br />
<br />
<br />
== Bash Variables ==<br />
A few Bash variables are available when called from the Lingoport Jenkins jobs that use the transform framework. <br />
They are set before calling the transform framework.<br />
<br />
<br />
=== Transform from repository variables ===<br />
'''CLIENT_SOURCE_DIR''' : The top level directory of the workspace for this project<br />
'''TRANSFORM_DIR''' : The directory of the transform, the .sh are underneath this directory<br />
'''PROJECT_TMP_DIR''' : A tmp directory<br />
<br />
=== Transform to repository variables ===<br />
<br />
'''CLIENT_SOURCE_DIR''' : The top level directory of the workspace for this project<br />
'''TRANSFORM_DIR''' : The transform scripts directory where the scripts are executed from.<br />
'''PROJECT_TMP_DIR''' : Where temporary files can be stashed for this project during the script execution<br />
'''$1''' : The first parameter is the list of all the files to be transformed from the translated files back to the repository<br />
<br />
== Example: txt2propfiles ==<br />
<br />
<br />
For a simple example, say the repository contains resource files like the following <code>strings.txt</code> file:<br />
<pre><br />
# Strings for use in GUI<br />
#################################################<br />
PushIfCommits,Push if commits<br />
CloseButtonText,Close<br />
ApplyButtonText,Apply<br />
CancelButtonText,Cancel<br />
</pre><br />
<br />
The file may not be in ASCII, UTF format, etc.; For instance this file is in UTF-8<br />
<br />
A supported file format that is close to this one is <code>properties</code>. So the transform script will change the file name, extension, and content, so as to be a standard resource file:<br />
<br />
<code>strings.properties</code><br />
<pre><br />
# Strings for use in GUI<br />
#################################################<br />
PushIfCommits=Push if commits<br />
CloseButtonText=Close<br />
ApplyButtonText=Apply<br />
CancelButtonText=Cancel<br />
</pre><br />
<br />
=== transform_from_repo.sh ===<br />
An <i>example</i> snippet of bash code for this type of file may be something like:<br />
<pre><br />
#!/bin/bash<br />
find . -name "string*\.txt" -type f > "${PROJECT_TMP_DIR}/input_files.txt"<br />
<br />
cat "${PROJECT_TMP_DIR}/input_files.txt" | while read -r FILEPATH<br />
do<br />
FILENAME=`basename $FILEPATH`<br />
DIRNAME=`dirname $FILEPATH`<br />
SUFFIX=".txt"<br />
ROOTNAME=${FILENAME%$SUFFIX}<br />
TARGET_NAME="${ROOTNAME//-/_}.properties"<br />
TARGET_PATH="${DIRNAME}/${TARGET_NAME}"<br />
echo " Transform [$FILENAME] -> [$TARGET_NAME]"<br />
<br />
rm $TARGET_PATH 2> /dev/null<br />
touch $TARGET_PATH<br />
<br />
sed -i 's/,,/, ,/' $FILEPATH <br />
cat $FILEPATH | while read -r LINE<br />
do<br />
IFS=',' tokens=( $LINE )<br />
<br />
if [ -z "${tokens[1]}" ]<br />
then<br />
echo "${LINE}" >> $TARGET_PATH<br />
else<br />
KEY=${tokens[0]}<br />
VALUE=${LINE#"${KEY},"}<br />
echo "${KEY}=${VALUE}" >> $TARGET_PATH<br />
fi<br />
done<br />
IFS=' '<br />
<br />
done <br />
</pre><br />
<br />
=== transform_to_repo.sh ===<br />
An <i>example</i> snippet of bash code for this type of file may be something like:<br />
<pre><br />
#!/bin/bash<br />
find . -name "string*\.txt" -type f > "${PROJECT_TMP_DIR}/input_files.txt"<br />
<br />
cat "${PROJECT_TMP_DIR}/input_files.txt" | while read -r FILEPATH<br />
do<br />
FILENAME=`basename $FILEPATH`<br />
DIRNAME=`dirname $FILEPATH`<br />
SUFFIX=".txt"<br />
ROOTNAME=${FILENAME%$SUFFIX}<br />
TARGET_NAME="${ROOTNAME//-/_}.properties"<br />
TARGET_PATH="${DIRNAME}/${TARGET_NAME}"<br />
echo " Transform [$FILENAME] -> [$TARGET_NAME]"<br />
<br />
rm $TARGET_PATH 2> /dev/null<br />
touch $TARGET_PATH<br />
<br />
sed -i 's/,,/, ,/' $FILEPATH <br />
cat $FILEPATH | while read -r LINE<br />
do<br />
IFS=',' tokens=( $LINE )<br />
<br />
if [ -z "${tokens[1]}" ]<br />
then<br />
echo "${LINE}" >> $TARGET_PATH<br />
else<br />
KEY=${tokens[0]}<br />
VALUE=${LINE#"${KEY},"}<br />
echo "${KEY}=${VALUE}" >> $TARGET_PATH<br />
fi<br />
done<br />
IFS=' '<br />
<br />
done <br />
</pre><br />
<br />
=== transform_files_list.sh ===<br />
An <i>example</i> snippet of bash code for this type of file may be something like:<br />
<pre><br />
#!/bin/bash<br />
if [ -z "$1" ]<br />
then<br />
echo "Error: Missing the argument like /<path>/pseudo_files.txt"<br />
exit 1<br />
fi<br />
<br />
if [ -f "$1" ]; then<br />
echo " File to rewrite: $1"<br />
else<br />
echo " $1 not found"<br />
exit 1<br />
fi<br />
<br />
<br />
echo " "<br />
echo " --------------------------------------------"<br />
echo " Files to Modify: $1"<br />
echo " for repository formatted files, not LRM OOTB ones"<br />
<br />
# strings<locale>.properties -> strings<locale>.txt<br />
echo " >> strings<locale>.properties to strings<locale>.txt"<br />
sed -i 's/\.properties/.txt/' "$1"<br />
sed -i 's/strings_/strings-/' "$1"<br />
sed -i 's/strings-zh_Hans/strings-zh-Hans/' "$1"<br />
sed -i 's/strings-zh_Hant/strings-zh-Hant/' "$1"<br />
sed -i 's/_/-/g' "$1"<br />
<br />
echo " " <br />
ls -l "$1"<br />
cat "$1"<br />
echo " --------------------------------------------"<br />
</pre><br />
<br />
== Command Center Settings ==<br />
<br />
=== Transform System Files ===<br />
The transform is retrieved like any system file from the repository and set as a system file. <br />
<br />
* Put Command Center in Maintenance Mode<br />
* Go to Settings<br />
* Go to System Files<br />
* Add the Transform from the repository<br />
<br />
For example:<br />
<br />
[[File:Transform System File.jpg|center|600px]]<br />
<br />
When the repository is updated and the transform scripts are modified, update from the Edit button above to get the latest. The commit hash indicates which commit was last.<br />
<br />
=== Set the Transform for a Project ===<br />
Now that the Transform is ready to be used, a project can be configured to run the transform. To do so, either during the creation or the edit of the project. <br />
1. Make sure the project resource format is that of the transformed file, not the files in the repository. Here, that's .properties files. <br />
2. Click the 'Use transform script' checkbox and select the transform of your choice, here 'txt2prop'<br />
<br />
For example:<br />
[[File:Transform Project Configuration.jpg|center|600px]]<br />
<br />
<br />
Now whenever the project is analyzed or files are sent to translation, the repository is cloned or pulled, the files identified with .txt are transformed into .properties, then analyzed or sent to translation as properties. <br />
<br />
Files are received from translation as properties, are analyzed for correctness, etc. as properties, then if the validations are passed, the files are transformed back in to .txt files and pushed to the repository.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Pull_Requests&diff=99811Pull Requests2026-02-25T19:00:06Z<p>Rwilliams: /* Upgrade Procedure */</p>
<hr />
<div>= Introduction =<br />
For GitHub, GitLab and Bitbucket, commits, Pull Requests / Merge Requests code changes can be analyzed using the Globalyzer Scanner.<br />
<br />
A Webhook lets a Jenkins job know to scan the code committed. Only the code modified is analyzed by the Globalyzer scanner. The result is a comment in GitHub, GitLab or Bitbucket showing issues detected. <br />
<br />
In the example below, one line was modified and the Globalyzer scan shows an i18n issue. The developer can decide how to handle it. <br />
<br />
[[File:PullRequestExample.png|600px|center]]<br />
<br />
This is unobtrusive and provides actionable i18n information to developers.<br />
<br />
<br />
= Video Introduction to GitHub, GitLab, and Bitbucket =<br />
Below are short introductions of the functionality around Globalyzer scanning for Git repository:<br />
<br />
* '''GitHub''' https://vimeo.com/817611647<br />
<br />
* '''GitLab''' https://vimeo.com/817610534<br />
<br />
* '''Bitbucket''' https://vimeo.com/826230267<br />
<br />
= Pull Requests via Jenkins Running on Docker =<br />
<br />
== Prerequisites ==<br />
<ol><br />
<li> VM running Linux and Docker<br />
<li> JQ JSON Parser - Statically compiled binary version<br />
<ol><br />
<li> https://stedolan.github.io/jq/<br />
</ol><br />
<li> GitHub PAT credentials to connect to GitHub<br />
<ol><br />
<li> The user for these PAT credentials has read access to the repository<br />
</ol><br />
<li> Globalyzer.com credentials for logging in to globalyzer.com<br />
<ol><br />
<li> username<br />
<li> password<br />
</ol><br />
<li> Obtain a copy of Globalyzer Lite from https://www.globalyzer.com/gzserver/home/installclient (requires Globalyzer.com credentials)<br />
<li> A copy of your Globalyzer.license from globalyzer.com or your local globalyzer server instance.<br />
<li> Jenkins will use the following URL to download all plugins required during the installation. This URL is required to be reachable from the VM Jenkins is being installed on prior to starting the install. <br />
<ol><br />
<li> https://updates.jenkins.io/update-center.json <br />
</li><br />
</ol><br />
<li> Optional:<br />
<ol><br />
<li> Apache or nginx could be installed and running on the VM itself as a reverse proxy to front the Jenkins instance </li><br />
</ol><br />
</ol><br />
<br />
== File System Configuration ==<br />
<p><br />
If Apache is installed as per normal for many Lingoport systems, the following is required to configure Apache to permit proper connection to the Jenkins Docker container<br />
</p><br />
<ol><br />
<li> Create the directory structure for the volume storage used by jenkins. Be sure there is sufficient space. Base install will consume 650MB of space for the volume itself. </li><br />
<code> mkdir ~/docker/jenkins/lingoport/bin </code><br />
<li> Place the Globalyzer License into the lingoport directory created </li><br />
<code> cp ~/PRC-Docker/Globalyzer.license ~/docker/jenkins/lingoport/ </code><br />
<li> Copy the downloaded copy of Globalyzer Lite into the lingoport directory </li><br />
<code> cp ~/PRC-Docker/globalyzer-lite-VERSION.zip ~/docker/jenkins/lingoport/ </code><br />
<li> Copy the jq binary into the bin directory and set the permissions </li><br />
<code> <br />
cp -p ~/PRC-Docker/jq ~/docker/jenkins/lingoport/bin/<br />
chmod +x ~/docker/jenkins/lingoport/bin/jq<br />
</code><br />
<li> Unzip the Globalyzer Lite zip file in the lingoport directory and remove the zip file once complete </li> <br />
<code><br />
cd ~/docker/jenkins/lingoport<br />
unzip globalyzer-lite-VERSION.zip<br />
rm ./globalyzer-lite-VERSION.zip<br />
</code><br />
<li> Create the .globalyzerrc file in the jenkins home directory, add the proper credentials and set the permissions </li><br />
<code><br />
vi .globalyzerrc<br />
chmod 600 .globalyzerrc<br />
</code><br />
<li> Confirm the contents of the .globalyzerrc file are entered like this: (Note no equals or colon, just whitespace between key and value) </li><br />
<code><br />
username <GLOBALYZER LOGIN USERNAME><br />
password <GLOBALYZER LOGIN PASSWORD><br />
server <URL of Globalyzer Server> <br />
</code><br />
</ol><br />
<br />
== Launching the Jenkins Docker Container ==<br />
<br />
<p> Retrieve these two items as they are now required to proceed </p><br />
<ol><br />
<li> Obtain the UID and GID for the user that Docker is being ran by.<br />
<li> Identify the the port that Jenkins should be listening on.<br />
<ol><br />
<li> In the example below it was determined to be 8085 </li><br />
</ol><br />
</li><br />
</ol><br />
<p> The next command line is an example of what would be used to start the docker instance for Jenkins. Here is an explanation of the switches being used when no proxy is required for the container to reach required destinations. </p><br />
<p><br />
The command string will create a new container instance that will automatically restart the container unless specifically<br />
stopped. It will also reuse the existing container on a restart of the OS. If the container is stopped before the<br />
reboot is performed using <i> sudo docker stop "CONTAINTER ID" </i>, it will need to be started using <i>sudo docker start "CONTAINER ID"</i><br />
</p><br />
<ol><br />
<li> The -d detaches the command being run from the terminal. Normally this is something that will only be used<br />
once everything is in place and confirmed to be working. For initial startup, its use can be ignored. </li><br />
<li> The -u is for setting the uid/gid of the user that owns the volume storage identified earlier. This user<br />
should also be the user that is starting the docker instance. </li><br />
<li> The -p 8085:8080 is the port external to internal mapping identified earlier. The 8080 would never change,<br />
only the external port is modifiable </li><br />
<li> The -p 50000:50000 is for mapping between Jenkins instances only. Not required for standalone systems. </li><br />
<li> The JENKINS_OPTS sets the baseurl for the application </li><br />
<li> The -v mounts the prior locally created file system to the running docker instance as a volume and mas it. </li><br />
<li> The jenkins/jenkins:lts-jdk17 is the long term support image for Jenkins. Currently, it is Jenkins 2.452.2 </li><br />
</ol><br />
<br />
<code><br />
sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \<br />
--env JENKINS_OPTS="--prefix=/jenkins" --restart=unless-stopped \<br />
-v /USER_HOME_DIR/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk17<br />
</code><br />
<br />
<p> <br />
If a proxy is required to be leveraged by the container to reach destinations the next command line would be used to start the docker instance for Jenkins instead of the previous one. Note the additional env variables that are added to support the proxy.<br />
</p><br />
<br />
<code><br />
sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \<br />
--env JENKINS_OPTS="--prefix=/jenkins" \<br />
--env http_proxy="http://<PROXY_URL>:<PORT>" \<br />
--env https_proxy="http://<PROXY_URL>:<PORT>" \<br />
--restart=unless-stopped \<br />
-v /home/centos/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk17<br />
</code><br />
<br />
<p><br />
This will download the required images and start the container. There will be a message about initial password, <br />
make note of it as it will be used to log into Jenkins<br />
</p><br />
<br />
<br />
<br />
<code><br />
*************************************************************<br />
*************************************************************<br />
*************************************************************<br />
Jenkins initial setup is required. An admin user has been created and a password generated.<br />
Please use the following password to proceed to installation:<br />
<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
<br />
This may also be found at: /var/jenkins_home/secrets/initialAdminPassword<br />
<br />
*************************************************************<br />
*************************************************************<br />
*************************************************************<br />
</code><br />
<br />
== Browser Connected Configuration ==<br />
<p> Go to application using the browser and use the above password to log in initially </p><br />
[[File:Unlock-jenkins.png|noframe|500px]]<br />
<br />
<p> At this screen select Install Suggested Plugins </p><br />
[[File:Customize-jenkins.png|noframe|500px]]<br />
<br />
<p> The plugins will begin to install, this will only be a few minutes. </p><br />
[[File:Getting-started-jenkins.png|noframe|500px]]<br />
<br />
<p> Create the Admin account. This will be a new account outside of what was used to connect initially. It will be the administrator account. </p><br />
[[File:Create-first-admin-user-jenkins.png|noframe|500px]]<br />
<br />
<p> This sets up the URL with a path to the instance. It will include /jenkins so it should be something like “http(s)://<YOUR FQDN/jenkins/ </p><br />
[[File:Instance-config-jenkins.png|noframe|500px]]<br />
<br />
<p> The base Jenkins system install is complete at this point. </p><br />
[[File:Jenkins-ready.png|noframe|500px]]<br />
<br />
<p> Click Start using Jenkins and the Dashboard appears </p><br />
[[File:Dashboard-jenkins.png|noframe|500px]]<br />
<br />
<p> The alert is caused by this running locally and not using nodes. Click on it and select “Dismiss” </p><br />
[[File:Node-details-jenkins.png|noframe|500px]]<br />
<br />
<p> If once this is cleared, this message appears. It is due to a reverse proxy being used that needs to have some additional configuration. </p><br />
[[File:Proxy-error-jenkins.png|noframe|500px]]<br />
<br />
<p> When using Apache as a reverse proxy, adding these two entries to the virtual host SSL configuration should correct the error. </p><br />
<br />
<code><br />
RequestHeader set X-Forwarded-Proto "https"<br />
<br />
RequestHeader set X-Forwarded-Port "443"<br />
</code><br />
<br />
== Add GUI Configuration Items for Pull Requests and Commits ==<br />
<br />
<p> Install and additional plugin called “Discard Old Builds” by going to Manage Jenkins → Manage Plugins → Available Plugins and search for “Discard old builds” </p><br />
[[File:Plugins1-jenkins.png|noframe|500px]]<br />
<br />
<p> Install an additional plugin called “Throttle Concurrent Builds” by going to Manage Jenkins → Manage Plugins → Available Plugins and search for “Throttle Concurrent Builds”</p><br />
[[File:Plugins2-jenkins.png|noframe|500px]]<br />
<br />
<p> Once plugin is installed to go Manage Jenkins → Configure System → Throttle Concurrent Builds and select Add Category: </p><br />
<br />
<p> Create Category Name PRC_THROTTLE and set Maximum Total Concurrent Builds = 1 and Maximum Concurrent Builds Per Node = 1. </p><br />
<br />
<p> Select “Apply” to save </p><br />
<br />
<p> Set up the environment variables in Jenkins: </p><br />
<br />
<ol><br />
<li> Select the Environment Variables checkbox<br />
<li> Select Add and add the following<br />
<ol><br />
<li> For a GitHub Installation<br />
<ol> <br />
<li> GITHUB_PRC_FILES = $JENKINS_HOME/lingoport/<globalyzer-lite-dir>/GitHub_PRC </li><br />
</ol><br />
<li> PATH = $PATH:$JENKINS_HOME/lingoport/bin<br />
<li> If https is to be used for connecting to the git repos set to true. If ssh is to be used to connect to git repos set to false.<br />
<ol><br />
<li> useHTTPS = true or false </li><br />
</ol><br />
</li><br />
<li> Optional - If Proxy is required: <br />
<ol> <br />
<li> Add entry _JAVA_OPTIONS with proxy details as shown in screenshot below </li><br />
<li> Dhttp.proxyHost=<FQDN> Dhttp.proxyPort=<PORT> Dhttps.proxyHost=<FQDN> Dhttps.proxyPort=<PORT> </li><br />
</ol><br />
</li> <br />
</ol><br />
</li><br />
</ol><br />
<br><br />
<p></p><br />
[[File:Env-var1-jenkins.png|noframe|500px]]<br />
<br><br />
[[File:Env-var2-jenkins.png|noframe|500px]]<br />
<br><br />
[[File:Jenkins_proxy_for_java.png|noframe|500px]]<br />
<br><br />
<p> Click Apply and Save </p><br />
<br><br />
<p> Add new API token to be used by GitHub Webhook </p><br />
<p> In Jenkins create a new API token for the user that will be running the build. This will be required to be added to the webhook to permit connection back to the Jenkins instance </p><br />
The credentials used for GitHub will require read access to the git repository.<br />
<ol><br />
<li> Select Dashboard → Manage Jenkins → Manage Users → Select the gear icon on the right side of the Admin user (Admin user created earlier)<br />
<li> In the API Token section, select Add new Token<br />
<li> Set the name of the new token to GitHub-PRC-TOKEN or something that is memorable and can identify with the PRC action.<br />
<ol><br />
<li> Be sure to copy the token value as it will never be displayed beyond this time. </li><br />
</ol><br />
</li><br />
</ol><br />
<p></p><br />
[[File:Api-token-2.png|noframe|500px]]<br />
<br />
==Add File System Configuration Items for Pull Requests and Commits==<br />
<p>Leave the GUI and go back to the file system </p><br />
<ol><br />
<li> Edit the github.properties file:<br />
<ol><br />
<li> /HOME_DIR/docker/jenkins/lingoport/globalyzer-lite-VERSION/GitHub_PRC/github.properties.<br />
<li> Update the github.login and github.oauth with the appropriate PAT values that were created ahead of time.<br />
</li><br />
</ol><br />
<li> When using https there will need to be a .netrc file placed in the jenkins_home directory inside of the container. This can be placed in the volume directory at /HOME_DIR/docker/jenkins/.netrc<br />
<ol><br />
<li> login <GitHub login ID> (Not email)<br />
<li> password PAT<br />
</li><br />
</ol><br />
<li> When using ssh there will need to be the ssh public and private keys stored in the /HOME_DIR/docker/jenkins/.ssh directory. Also with ssh be sure to manually connect to the git repo prior to using the PRC scripts. The known_hosts file needs to be updated and that is a manual process that requires manually accepting the key. This should only be needed to be performed once.<br />
<li> Run the installer for Globalyzer-Lite. This must be done inside of the contains so everything is properly set up in that environment<br />
<ol> <br />
<li> Obtain the container id<br />
<ol> <br />
<li> <code> sudo docker container ps </code><br />
</li><br />
</ol><br />
<li> <code> sudo docker exec -it CONTAINER ID /bin/bash </code><br />
<li> <code> cd ~/lingoport/globalyzer-lite-VERSION </code><br />
<li> <code>./install-lite.sh </code> (Should return Globalyzer Lite installation completed successfully)<br />
</li><br />
</ol><br />
</li><br />
</ol><br />
<br />
== Create Jenkins Build for Pull Requests and Commits via GitHub ==<br />
<br />
<ol><br />
<li> Log into Jenkins and go to the Dashboard<br />
<li> Select New Item<br />
<li> Create an item name for the PRC build. <br />
<li> Use an item name that is memorable, something like GitHub-PRC is fine.<br />
<li> Select Freestyle Project<br />
<li> Select OK<br />
<li> Add a description (optional)<br />
<li> Select “This project is parameterized”<br />
<li> Add two string parameters<br />
<ol> <br />
<li> payload = NOT_SET<br />
<li> LITE_PROJECT_DEFINITION = DEFAULT<br />
<ol><br />
<li> DEFAULT looks for the project definition to exist in the lingoport directory of the working branch as such: lingoport/LiteProjectDefinition.xml<br />
</li><br />
</ol><br />
<li> Select “Throttle Concurrent Builds”<br />
<ol><br />
<li> Set Maximum Total Concurrent Builds to 1<br />
<li> Set Maximum Concurrent Builds Per Node to 1<br />
</li><br />
</ol><br />
<li> In Build Triggers Section<br />
<ol><br />
<li> Select Trigger builds remotely (e.g., from scripts)<br />
<li> In the Authentication Token place a token you wish to use. Something like HOOK for example.<br />
</li><br />
</ol><br />
<li> In Build Steps Section<br />
<ol><br />
<li> Select Execute Shell<br />
<li> Place the following shell code<br />
<ul><br />
<li> <code> set +x </code><br />
<li> <code> $GITHUB_PRC_FILES/job_lite_pr.sh $GITHUB_PRC_FILES/pr_message.html </code><br />
</li><br />
</ul><br />
<li> In the Post-build Actions<br />
<ol><br />
<li> Select Discard Old Builds<br />
<li> Set Days to keep builds to 14<br />
</li><br />
</ol><br />
<li> Save the configuration<br />
</li><br />
</ol><br />
</li><br />
</ol><br />
<br />
=== GitHub Configuration ===<br />
<br />
<p> <br />
Webhooks are calls made from the GitHub side down to the Jenkins instance. They provide information required by the Jenkins build to properly scan the files that were either committed or had a pull request performed on them. This is discussed in detail in the Videos found in earlier sections of this page. <br />
</p><br />
<p><br />
Below is a summary of the steps. <br />
</p><br />
<ol><br />
<li> Log into GitHub<br />
<li> Navigate to the repository that will have pull requests and commits applied to it<br />
<li> Click on Settings → Webhooks→ Add webhook<br />
<li> Enter the following:<br />
<ol><br />
<li> Payload URL <br />
<ol><br />
<li> URL found in Build Triggers Section of the Jenkins Build<br />
<li> It will likely require the API Token generated prior along with the username that the build in Jenkins was created<br />
<li> ht<span>tps://USER:TOKEN@JENKINS_URL/jenkins/job/BUILD_NAME/buildWithParameters?token=BUILD_TOKEN</span><br />
</li><br />
</ol><br />
<li> Content Type application/x-www-form-urlencoded<br />
<li> Radio button: Let me select individual events<br />
<ol><br />
<li> Pushes<br />
<li> Pull Requests<br />
<li> Pushes, Pull Requests<br />
</li><br />
</ol><br />
</li><br />
</ol><br />
<li> Using the Recent Deliveries tab it's possible to check the status of a web hook call to confirm that it worked correctly.<br />
<ol><br />
<li> There should be a build triggered for each webhook called submitted<br />
<li> If there are issues use the Redeliver button to resend<br />
</li><br />
</ol><br />
</li><br />
</ol><br />
<br />
=== Install Validation ===<br />
<p> This completes the basic installation. To confirm that everything is working correctly. </p><br />
<ol><br />
<li> Log into GitHub and navigate to a repository<br />
<li> Make a change directly to a file in the GitHub repository and “Commit” the change (assuming Commits are enabled). <br />
<li> Switch to Jenkins and confirm that the build was triggered and successfully completed<br />
<li> Switch back to GitHub and click on the commit id for the modification in and confirm that there is an associated summary.<br />
<li> Clicking on the File/Line link in the summary should show the code line and modification made.<br />
</li><br />
</ol><br />
<br />
<br><br />
<br />
<p> This is an image of the Analysis Summary in GitHub for a commit </p><br />
[[File:Intall-validation-1.png|noframe|500px]]<br />
<br />
<br><br />
<br />
<p> This image shows the line of code that is presented when clicking on the link in the Analysis Summary </p><br />
[[File:Install-validation-2.png|noframe|500px]]<br />
<br />
== SAML Integration (Optional) ==<br />
<p><br />
To optionally leverage SAML in place of the local user login system, follow the instructions found on this page<br />
<p><br />
<br />
[[Docker Jenkins SAML Configuration]]<br />
<br />
= Jenkins Upgrade when using Docker =<br />
<br />
== Upgrade Required Indication ==<br />
<br />
When logging into Jenkins, there will be a message on the Manage Jenkins page indicating that a new version is available.<br />
<br />
[[file:Before_Upgrade.png |800px]]<br />
<br />
== Upgrade Procedure ==<br />
<br />
1. Log into the VM containing docker with a user that has sudo privileges.<br />
<br />
2. Stop the existing jenkins/jenkins:lts-jdk17 container (this may be lts-jdk21 as well)<br />
sudo docker stop <CONTAINER ID><br />
<br />
3. Make a backup of the existing Jenkins directory that is mounted as a volume. All Jenkins files are contained on the file system, there is no associated DB.<br />
$ cp -pr /home/<USER_DIR>/docker/jenkins /home/USER_DIR/docker/jenkins_<MMDDYYYY><br />
<br />
4. Pull the latest version of the jenkins/jenkins:lts-jdk21 from docker.io. Note that it will indicate a newer image has been downloaded.<br />
sudo docker pull jenkins/jenkins:lts-jdk21<br />
lts-jdk21: Pulling from jenkins/jenkins<br />
53c88f1dfeb7: Pull complete<br />
1354b1aa1de9: Pull complete<br />
0c31487ae971: Pull complete<br />
3c9c60b56010: Pull complete<br />
5681e84d3308: Pull complete<br />
a2375046a225: Pull complete<br />
967448ab02b6: Pull complete<br />
7eb8b3c92c00: Pull complete<br />
24446a3ce816: Pull complete<br />
f63b11f22c5e: Pull complete<br />
650135881854: Pull complete<br />
f703dc66a915: Pull complete<br />
Digest: sha256:23b84d1066dbe69f2c17288c83ac071127092d726f14b3b80444d868468619c7<br />
Status: Downloaded newer image for jenkins/jenkins:lts-jdk21<br />
docker.io/jenkins/jenkins:lts-jdk21<br />
<br />
5. Start the new container with the updated image using one of the two options below depending upon whether a proxy is required to be leveraged from inside of the container or not. Adjust the home directory location as needed for the particular installation.<br />
<br />
'''Option #1''' - Run the newly updated container to start Jenkins with the latest<br />
version (Command is the same as the one used initially to run) <br />
<br />
$ sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \<br />
--env JENKINS_OPTS="--prefix=/jenkins" \<br />
--restart=unless-stopped \<br />
-v /home/centos/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk21<br />
$<br />
$ sudo docker container ls<br />
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES<br />
f9fe867b7c00 jenkins/jenkins:lts-jdk21 "/usr/bin/tini -- /u…" 16 seconds ago Up 15 seconds 0.0.0.0:50000->50000/tcp, :::50000->50000/tcp, 0.0.0.0:8086->8080/tcp, :::8086->8080/tcp heuristic_proskuriakova<br />
<br />
'''Option #2''' - Run the newly updated container to start Jenkins with<br />
the latest version of Jenkins when a proxy is needed for outgoing communications<br />
version (Command is the same as the one used initially to run) <br />
<br />
$ sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \<br />
--env JENKINS_OPTS="--prefix=/jenkins" \<br />
--env http_proxy="http://<PROXY_URL>:<PORT>" \<br />
--env https_proxy="http://<PROXY_URL>:<PORT>" \<br />
--restart=unless-stopped \<br />
-v /home/centos/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk21<br />
$<br />
$ sudo docker container ls<br />
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES<br />
9e2650b5ec1c jenkins/jenkins:lts-jdk21 "/usr/bin/tini -- /u…" 33 seconds ago Up 32 seconds 0.0.0.0:50000->50000/tcp, :::50000->50000/tcp, 0.0.0.0:8085->8080/tcp, :::8085->8080/tcp elegant_engelbart<br />
<br />
<br />
6. Confirm that the new version is running properly by logging in the web interface and going to the manage jenkins section. There should not be mention of a new version being available. <br />
<br />
[[file:After_Upgrade.png |800px]]<br />
<br />
7. At the bottom of this page, the current version will be displayed in the footer.<br />
<br />
8. The old container can be removed if desired at this point.<br />
sudo docker rm <CONTAINER ID><br />
<br />
9. The old image can also be removed if desired at this point.<br />
sudo docker rmi <IMAGE ID><br />
<br />
10. The system will now be running the latest version of the Jenkins docker image and both the old images and containers will have been removed.<br />
<br />
= Historical Version of the Pull Request/Commit Globalyzer Scanning =<br />
<br />
[[ Historical Pull Request | Historical Pull Request ]]</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Pull_Requests&diff=99810Pull Requests2026-02-25T18:59:19Z<p>Rwilliams: /* Upgrade Procedure */</p>
<hr />
<div>= Introduction =<br />
For GitHub, GitLab and Bitbucket, commits, Pull Requests / Merge Requests code changes can be analyzed using the Globalyzer Scanner.<br />
<br />
A Webhook lets a Jenkins job know to scan the code committed. Only the code modified is analyzed by the Globalyzer scanner. The result is a comment in GitHub, GitLab or Bitbucket showing issues detected. <br />
<br />
In the example below, one line was modified and the Globalyzer scan shows an i18n issue. The developer can decide how to handle it. <br />
<br />
[[File:PullRequestExample.png|600px|center]]<br />
<br />
This is unobtrusive and provides actionable i18n information to developers.<br />
<br />
<br />
= Video Introduction to GitHub, GitLab, and Bitbucket =<br />
Below are short introductions of the functionality around Globalyzer scanning for Git repository:<br />
<br />
* '''GitHub''' https://vimeo.com/817611647<br />
<br />
* '''GitLab''' https://vimeo.com/817610534<br />
<br />
* '''Bitbucket''' https://vimeo.com/826230267<br />
<br />
= Pull Requests via Jenkins Running on Docker =<br />
<br />
== Prerequisites ==<br />
<ol><br />
<li> VM running Linux and Docker<br />
<li> JQ JSON Parser - Statically compiled binary version<br />
<ol><br />
<li> https://stedolan.github.io/jq/<br />
</ol><br />
<li> GitHub PAT credentials to connect to GitHub<br />
<ol><br />
<li> The user for these PAT credentials has read access to the repository<br />
</ol><br />
<li> Globalyzer.com credentials for logging in to globalyzer.com<br />
<ol><br />
<li> username<br />
<li> password<br />
</ol><br />
<li> Obtain a copy of Globalyzer Lite from https://www.globalyzer.com/gzserver/home/installclient (requires Globalyzer.com credentials)<br />
<li> A copy of your Globalyzer.license from globalyzer.com or your local globalyzer server instance.<br />
<li> Jenkins will use the following URL to download all plugins required during the installation. This URL is required to be reachable from the VM Jenkins is being installed on prior to starting the install. <br />
<ol><br />
<li> https://updates.jenkins.io/update-center.json <br />
</li><br />
</ol><br />
<li> Optional:<br />
<ol><br />
<li> Apache or nginx could be installed and running on the VM itself as a reverse proxy to front the Jenkins instance </li><br />
</ol><br />
</ol><br />
<br />
== File System Configuration ==<br />
<p><br />
If Apache is installed as per normal for many Lingoport systems, the following is required to configure Apache to permit proper connection to the Jenkins Docker container<br />
</p><br />
<ol><br />
<li> Create the directory structure for the volume storage used by jenkins. Be sure there is sufficient space. Base install will consume 650MB of space for the volume itself. </li><br />
<code> mkdir ~/docker/jenkins/lingoport/bin </code><br />
<li> Place the Globalyzer License into the lingoport directory created </li><br />
<code> cp ~/PRC-Docker/Globalyzer.license ~/docker/jenkins/lingoport/ </code><br />
<li> Copy the downloaded copy of Globalyzer Lite into the lingoport directory </li><br />
<code> cp ~/PRC-Docker/globalyzer-lite-VERSION.zip ~/docker/jenkins/lingoport/ </code><br />
<li> Copy the jq binary into the bin directory and set the permissions </li><br />
<code> <br />
cp -p ~/PRC-Docker/jq ~/docker/jenkins/lingoport/bin/<br />
chmod +x ~/docker/jenkins/lingoport/bin/jq<br />
</code><br />
<li> Unzip the Globalyzer Lite zip file in the lingoport directory and remove the zip file once complete </li> <br />
<code><br />
cd ~/docker/jenkins/lingoport<br />
unzip globalyzer-lite-VERSION.zip<br />
rm ./globalyzer-lite-VERSION.zip<br />
</code><br />
<li> Create the .globalyzerrc file in the jenkins home directory, add the proper credentials and set the permissions </li><br />
<code><br />
vi .globalyzerrc<br />
chmod 600 .globalyzerrc<br />
</code><br />
<li> Confirm the contents of the .globalyzerrc file are entered like this: (Note no equals or colon, just whitespace between key and value) </li><br />
<code><br />
username <GLOBALYZER LOGIN USERNAME><br />
password <GLOBALYZER LOGIN PASSWORD><br />
server <URL of Globalyzer Server> <br />
</code><br />
</ol><br />
<br />
== Launching the Jenkins Docker Container ==<br />
<br />
<p> Retrieve these two items as they are now required to proceed </p><br />
<ol><br />
<li> Obtain the UID and GID for the user that Docker is being ran by.<br />
<li> Identify the the port that Jenkins should be listening on.<br />
<ol><br />
<li> In the example below it was determined to be 8085 </li><br />
</ol><br />
</li><br />
</ol><br />
<p> The next command line is an example of what would be used to start the docker instance for Jenkins. Here is an explanation of the switches being used when no proxy is required for the container to reach required destinations. </p><br />
<p><br />
The command string will create a new container instance that will automatically restart the container unless specifically<br />
stopped. It will also reuse the existing container on a restart of the OS. If the container is stopped before the<br />
reboot is performed using <i> sudo docker stop "CONTAINTER ID" </i>, it will need to be started using <i>sudo docker start "CONTAINER ID"</i><br />
</p><br />
<ol><br />
<li> The -d detaches the command being run from the terminal. Normally this is something that will only be used<br />
once everything is in place and confirmed to be working. For initial startup, its use can be ignored. </li><br />
<li> The -u is for setting the uid/gid of the user that owns the volume storage identified earlier. This user<br />
should also be the user that is starting the docker instance. </li><br />
<li> The -p 8085:8080 is the port external to internal mapping identified earlier. The 8080 would never change,<br />
only the external port is modifiable </li><br />
<li> The -p 50000:50000 is for mapping between Jenkins instances only. Not required for standalone systems. </li><br />
<li> The JENKINS_OPTS sets the baseurl for the application </li><br />
<li> The -v mounts the prior locally created file system to the running docker instance as a volume and mas it. </li><br />
<li> The jenkins/jenkins:lts-jdk17 is the long term support image for Jenkins. Currently, it is Jenkins 2.452.2 </li><br />
</ol><br />
<br />
<code><br />
sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \<br />
--env JENKINS_OPTS="--prefix=/jenkins" --restart=unless-stopped \<br />
-v /USER_HOME_DIR/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk17<br />
</code><br />
<br />
<p> <br />
If a proxy is required to be leveraged by the container to reach destinations the next command line would be used to start the docker instance for Jenkins instead of the previous one. Note the additional env variables that are added to support the proxy.<br />
</p><br />
<br />
<code><br />
sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \<br />
--env JENKINS_OPTS="--prefix=/jenkins" \<br />
--env http_proxy="http://<PROXY_URL>:<PORT>" \<br />
--env https_proxy="http://<PROXY_URL>:<PORT>" \<br />
--restart=unless-stopped \<br />
-v /home/centos/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk17<br />
</code><br />
<br />
<p><br />
This will download the required images and start the container. There will be a message about initial password, <br />
make note of it as it will be used to log into Jenkins<br />
</p><br />
<br />
<br />
<br />
<code><br />
*************************************************************<br />
*************************************************************<br />
*************************************************************<br />
Jenkins initial setup is required. An admin user has been created and a password generated.<br />
Please use the following password to proceed to installation:<br />
<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
<br />
This may also be found at: /var/jenkins_home/secrets/initialAdminPassword<br />
<br />
*************************************************************<br />
*************************************************************<br />
*************************************************************<br />
</code><br />
<br />
== Browser Connected Configuration ==<br />
<p> Go to application using the browser and use the above password to log in initially </p><br />
[[File:Unlock-jenkins.png|noframe|500px]]<br />
<br />
<p> At this screen select Install Suggested Plugins </p><br />
[[File:Customize-jenkins.png|noframe|500px]]<br />
<br />
<p> The plugins will begin to install, this will only be a few minutes. </p><br />
[[File:Getting-started-jenkins.png|noframe|500px]]<br />
<br />
<p> Create the Admin account. This will be a new account outside of what was used to connect initially. It will be the administrator account. </p><br />
[[File:Create-first-admin-user-jenkins.png|noframe|500px]]<br />
<br />
<p> This sets up the URL with a path to the instance. It will include /jenkins so it should be something like “http(s)://<YOUR FQDN/jenkins/ </p><br />
[[File:Instance-config-jenkins.png|noframe|500px]]<br />
<br />
<p> The base Jenkins system install is complete at this point. </p><br />
[[File:Jenkins-ready.png|noframe|500px]]<br />
<br />
<p> Click Start using Jenkins and the Dashboard appears </p><br />
[[File:Dashboard-jenkins.png|noframe|500px]]<br />
<br />
<p> The alert is caused by this running locally and not using nodes. Click on it and select “Dismiss” </p><br />
[[File:Node-details-jenkins.png|noframe|500px]]<br />
<br />
<p> If once this is cleared, this message appears. It is due to a reverse proxy being used that needs to have some additional configuration. </p><br />
[[File:Proxy-error-jenkins.png|noframe|500px]]<br />
<br />
<p> When using Apache as a reverse proxy, adding these two entries to the virtual host SSL configuration should correct the error. </p><br />
<br />
<code><br />
RequestHeader set X-Forwarded-Proto "https"<br />
<br />
RequestHeader set X-Forwarded-Port "443"<br />
</code><br />
<br />
== Add GUI Configuration Items for Pull Requests and Commits ==<br />
<br />
<p> Install and additional plugin called “Discard Old Builds” by going to Manage Jenkins → Manage Plugins → Available Plugins and search for “Discard old builds” </p><br />
[[File:Plugins1-jenkins.png|noframe|500px]]<br />
<br />
<p> Install an additional plugin called “Throttle Concurrent Builds” by going to Manage Jenkins → Manage Plugins → Available Plugins and search for “Throttle Concurrent Builds”</p><br />
[[File:Plugins2-jenkins.png|noframe|500px]]<br />
<br />
<p> Once plugin is installed to go Manage Jenkins → Configure System → Throttle Concurrent Builds and select Add Category: </p><br />
<br />
<p> Create Category Name PRC_THROTTLE and set Maximum Total Concurrent Builds = 1 and Maximum Concurrent Builds Per Node = 1. </p><br />
<br />
<p> Select “Apply” to save </p><br />
<br />
<p> Set up the environment variables in Jenkins: </p><br />
<br />
<ol><br />
<li> Select the Environment Variables checkbox<br />
<li> Select Add and add the following<br />
<ol><br />
<li> For a GitHub Installation<br />
<ol> <br />
<li> GITHUB_PRC_FILES = $JENKINS_HOME/lingoport/<globalyzer-lite-dir>/GitHub_PRC </li><br />
</ol><br />
<li> PATH = $PATH:$JENKINS_HOME/lingoport/bin<br />
<li> If https is to be used for connecting to the git repos set to true. If ssh is to be used to connect to git repos set to false.<br />
<ol><br />
<li> useHTTPS = true or false </li><br />
</ol><br />
</li><br />
<li> Optional - If Proxy is required: <br />
<ol> <br />
<li> Add entry _JAVA_OPTIONS with proxy details as shown in screenshot below </li><br />
<li> Dhttp.proxyHost=<FQDN> Dhttp.proxyPort=<PORT> Dhttps.proxyHost=<FQDN> Dhttps.proxyPort=<PORT> </li><br />
</ol><br />
</li> <br />
</ol><br />
</li><br />
</ol><br />
<br><br />
<p></p><br />
[[File:Env-var1-jenkins.png|noframe|500px]]<br />
<br><br />
[[File:Env-var2-jenkins.png|noframe|500px]]<br />
<br><br />
[[File:Jenkins_proxy_for_java.png|noframe|500px]]<br />
<br><br />
<p> Click Apply and Save </p><br />
<br><br />
<p> Add new API token to be used by GitHub Webhook </p><br />
<p> In Jenkins create a new API token for the user that will be running the build. This will be required to be added to the webhook to permit connection back to the Jenkins instance </p><br />
The credentials used for GitHub will require read access to the git repository.<br />
<ol><br />
<li> Select Dashboard → Manage Jenkins → Manage Users → Select the gear icon on the right side of the Admin user (Admin user created earlier)<br />
<li> In the API Token section, select Add new Token<br />
<li> Set the name of the new token to GitHub-PRC-TOKEN or something that is memorable and can identify with the PRC action.<br />
<ol><br />
<li> Be sure to copy the token value as it will never be displayed beyond this time. </li><br />
</ol><br />
</li><br />
</ol><br />
<p></p><br />
[[File:Api-token-2.png|noframe|500px]]<br />
<br />
==Add File System Configuration Items for Pull Requests and Commits==<br />
<p>Leave the GUI and go back to the file system </p><br />
<ol><br />
<li> Edit the github.properties file:<br />
<ol><br />
<li> /HOME_DIR/docker/jenkins/lingoport/globalyzer-lite-VERSION/GitHub_PRC/github.properties.<br />
<li> Update the github.login and github.oauth with the appropriate PAT values that were created ahead of time.<br />
</li><br />
</ol><br />
<li> When using https there will need to be a .netrc file placed in the jenkins_home directory inside of the container. This can be placed in the volume directory at /HOME_DIR/docker/jenkins/.netrc<br />
<ol><br />
<li> login <GitHub login ID> (Not email)<br />
<li> password PAT<br />
</li><br />
</ol><br />
<li> When using ssh there will need to be the ssh public and private keys stored in the /HOME_DIR/docker/jenkins/.ssh directory. Also with ssh be sure to manually connect to the git repo prior to using the PRC scripts. The known_hosts file needs to be updated and that is a manual process that requires manually accepting the key. This should only be needed to be performed once.<br />
<li> Run the installer for Globalyzer-Lite. This must be done inside of the contains so everything is properly set up in that environment<br />
<ol> <br />
<li> Obtain the container id<br />
<ol> <br />
<li> <code> sudo docker container ps </code><br />
</li><br />
</ol><br />
<li> <code> sudo docker exec -it CONTAINER ID /bin/bash </code><br />
<li> <code> cd ~/lingoport/globalyzer-lite-VERSION </code><br />
<li> <code>./install-lite.sh </code> (Should return Globalyzer Lite installation completed successfully)<br />
</li><br />
</ol><br />
</li><br />
</ol><br />
<br />
== Create Jenkins Build for Pull Requests and Commits via GitHub ==<br />
<br />
<ol><br />
<li> Log into Jenkins and go to the Dashboard<br />
<li> Select New Item<br />
<li> Create an item name for the PRC build. <br />
<li> Use an item name that is memorable, something like GitHub-PRC is fine.<br />
<li> Select Freestyle Project<br />
<li> Select OK<br />
<li> Add a description (optional)<br />
<li> Select “This project is parameterized”<br />
<li> Add two string parameters<br />
<ol> <br />
<li> payload = NOT_SET<br />
<li> LITE_PROJECT_DEFINITION = DEFAULT<br />
<ol><br />
<li> DEFAULT looks for the project definition to exist in the lingoport directory of the working branch as such: lingoport/LiteProjectDefinition.xml<br />
</li><br />
</ol><br />
<li> Select “Throttle Concurrent Builds”<br />
<ol><br />
<li> Set Maximum Total Concurrent Builds to 1<br />
<li> Set Maximum Concurrent Builds Per Node to 1<br />
</li><br />
</ol><br />
<li> In Build Triggers Section<br />
<ol><br />
<li> Select Trigger builds remotely (e.g., from scripts)<br />
<li> In the Authentication Token place a token you wish to use. Something like HOOK for example.<br />
</li><br />
</ol><br />
<li> In Build Steps Section<br />
<ol><br />
<li> Select Execute Shell<br />
<li> Place the following shell code<br />
<ul><br />
<li> <code> set +x </code><br />
<li> <code> $GITHUB_PRC_FILES/job_lite_pr.sh $GITHUB_PRC_FILES/pr_message.html </code><br />
</li><br />
</ul><br />
<li> In the Post-build Actions<br />
<ol><br />
<li> Select Discard Old Builds<br />
<li> Set Days to keep builds to 14<br />
</li><br />
</ol><br />
<li> Save the configuration<br />
</li><br />
</ol><br />
</li><br />
</ol><br />
<br />
=== GitHub Configuration ===<br />
<br />
<p> <br />
Webhooks are calls made from the GitHub side down to the Jenkins instance. They provide information required by the Jenkins build to properly scan the files that were either committed or had a pull request performed on them. This is discussed in detail in the Videos found in earlier sections of this page. <br />
</p><br />
<p><br />
Below is a summary of the steps. <br />
</p><br />
<ol><br />
<li> Log into GitHub<br />
<li> Navigate to the repository that will have pull requests and commits applied to it<br />
<li> Click on Settings → Webhooks→ Add webhook<br />
<li> Enter the following:<br />
<ol><br />
<li> Payload URL <br />
<ol><br />
<li> URL found in Build Triggers Section of the Jenkins Build<br />
<li> It will likely require the API Token generated prior along with the username that the build in Jenkins was created<br />
<li> ht<span>tps://USER:TOKEN@JENKINS_URL/jenkins/job/BUILD_NAME/buildWithParameters?token=BUILD_TOKEN</span><br />
</li><br />
</ol><br />
<li> Content Type application/x-www-form-urlencoded<br />
<li> Radio button: Let me select individual events<br />
<ol><br />
<li> Pushes<br />
<li> Pull Requests<br />
<li> Pushes, Pull Requests<br />
</li><br />
</ol><br />
</li><br />
</ol><br />
<li> Using the Recent Deliveries tab it's possible to check the status of a web hook call to confirm that it worked correctly.<br />
<ol><br />
<li> There should be a build triggered for each webhook called submitted<br />
<li> If there are issues use the Redeliver button to resend<br />
</li><br />
</ol><br />
</li><br />
</ol><br />
<br />
=== Install Validation ===<br />
<p> This completes the basic installation. To confirm that everything is working correctly. </p><br />
<ol><br />
<li> Log into GitHub and navigate to a repository<br />
<li> Make a change directly to a file in the GitHub repository and “Commit” the change (assuming Commits are enabled). <br />
<li> Switch to Jenkins and confirm that the build was triggered and successfully completed<br />
<li> Switch back to GitHub and click on the commit id for the modification in and confirm that there is an associated summary.<br />
<li> Clicking on the File/Line link in the summary should show the code line and modification made.<br />
</li><br />
</ol><br />
<br />
<br><br />
<br />
<p> This is an image of the Analysis Summary in GitHub for a commit </p><br />
[[File:Intall-validation-1.png|noframe|500px]]<br />
<br />
<br><br />
<br />
<p> This image shows the line of code that is presented when clicking on the link in the Analysis Summary </p><br />
[[File:Install-validation-2.png|noframe|500px]]<br />
<br />
== SAML Integration (Optional) ==<br />
<p><br />
To optionally leverage SAML in place of the local user login system, follow the instructions found on this page<br />
<p><br />
<br />
[[Docker Jenkins SAML Configuration]]<br />
<br />
= Jenkins Upgrade when using Docker =<br />
<br />
== Upgrade Required Indication ==<br />
<br />
When logging into Jenkins, there will be a message on the Manage Jenkins page indicating that a new version is available.<br />
<br />
[[file:Before_Upgrade.png |800px]]<br />
<br />
== Upgrade Procedure ==<br />
<br />
1. Log into the VM containing docker with a user that has sudo privileges.<br />
<br />
2. Stop the existing jenkins/jenkins:lts-jdk17 container (this may be lts-jdk21 as well)<br />
sudo docker stop <CONTAINER ID><br />
<br />
3. Make a backup of the existing Jenkins directory that is mounted as a volume. All Jenkins files are contained on the file system, there is no associated DB.<br />
$ cp -pr /home/<USER_DIR>/docker/jenkins /home/USER_DIR/docker/jenkins_<MMDDYYYY><br />
<br />
4. Pull the latest version of the jenkins/jenkins:lts-jdk21 from docker.io. Note that it will indicate a newer image has been downloaded.<br />
sudo docker pull jenkins/jenkins:lts-jdk21<br />
lts-jdk21: Pulling from jenkins/jenkins<br />
53c88f1dfeb7: Pull complete<br />
1354b1aa1de9: Pull complete<br />
0c31487ae971: Pull complete<br />
3c9c60b56010: Pull complete<br />
5681e84d3308: Pull complete<br />
a2375046a225: Pull complete<br />
967448ab02b6: Pull complete<br />
7eb8b3c92c00: Pull complete<br />
24446a3ce816: Pull complete<br />
f63b11f22c5e: Pull complete<br />
650135881854: Pull complete<br />
f703dc66a915: Pull complete<br />
Digest: sha256:23b84d1066dbe69f2c17288c83ac071127092d726f14b3b80444d868468619c7<br />
Status: Downloaded newer image for jenkins/jenkins:lts-jdk21<br />
da080ad7c1d0: Pull complete<br />
<br />
5. Start the new container with the updated image using one of the two options below depending upon whether a proxy is required to be leveraged from inside of the container or not. Adjust the home directory location as needed for the particular installation.<br />
<br />
'''Option #1''' - Run the newly updated container to start Jenkins with the latest<br />
version (Command is the same as the one used initially to run) <br />
<br />
$ sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \<br />
--env JENKINS_OPTS="--prefix=/jenkins" \<br />
--restart=unless-stopped \<br />
-v /home/centos/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk21<br />
$<br />
$ sudo docker container ls<br />
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES<br />
f9fe867b7c00 jenkins/jenkins:lts-jdk21 "/usr/bin/tini -- /u…" 16 seconds ago Up 15 seconds 0.0.0.0:50000->50000/tcp, :::50000->50000/tcp, 0.0.0.0:8086->8080/tcp, :::8086->8080/tcp heuristic_proskuriakova<br />
<br />
'''Option #2''' - Run the newly updated container to start Jenkins with<br />
the latest version of Jenkins when a proxy is needed for outgoing communications<br />
version (Command is the same as the one used initially to run) <br />
<br />
$ sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \<br />
--env JENKINS_OPTS="--prefix=/jenkins" \<br />
--env http_proxy="http://<PROXY_URL>:<PORT>" \<br />
--env https_proxy="http://<PROXY_URL>:<PORT>" \<br />
--restart=unless-stopped \<br />
-v /home/centos/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk21<br />
$<br />
$ sudo docker container ls<br />
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES<br />
9e2650b5ec1c jenkins/jenkins:lts-jdk21 "/usr/bin/tini -- /u…" 33 seconds ago Up 32 seconds 0.0.0.0:50000->50000/tcp, :::50000->50000/tcp, 0.0.0.0:8085->8080/tcp, :::8085->8080/tcp elegant_engelbart<br />
<br />
<br />
6. Confirm that the new version is running properly by logging in the web interface and going to the manage jenkins section. There should not be mention of a new version being available. <br />
<br />
[[file:After_Upgrade.png |800px]]<br />
<br />
7. At the bottom of this page, the current version will be displayed in the footer.<br />
<br />
8. The old container can be removed if desired at this point.<br />
sudo docker rm <CONTAINER ID><br />
<br />
9. The old image can also be removed if desired at this point.<br />
sudo docker rmi <IMAGE ID><br />
<br />
10. The system will now be running the latest version of the Jenkins docker image and both the old images and containers will have been removed.<br />
<br />
= Historical Version of the Pull Request/Commit Globalyzer Scanning =<br />
<br />
[[ Historical Pull Request | Historical Pull Request ]]</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Pull_Requests&diff=99809Pull Requests2026-02-25T18:58:52Z<p>Rwilliams: /* Upgrade Procedure */</p>
<hr />
<div>= Introduction =<br />
For GitHub, GitLab and Bitbucket, commits, Pull Requests / Merge Requests code changes can be analyzed using the Globalyzer Scanner.<br />
<br />
A Webhook lets a Jenkins job know to scan the code committed. Only the code modified is analyzed by the Globalyzer scanner. The result is a comment in GitHub, GitLab or Bitbucket showing issues detected. <br />
<br />
In the example below, one line was modified and the Globalyzer scan shows an i18n issue. The developer can decide how to handle it. <br />
<br />
[[File:PullRequestExample.png|600px|center]]<br />
<br />
This is unobtrusive and provides actionable i18n information to developers.<br />
<br />
<br />
= Video Introduction to GitHub, GitLab, and Bitbucket =<br />
Below are short introductions of the functionality around Globalyzer scanning for Git repository:<br />
<br />
* '''GitHub''' https://vimeo.com/817611647<br />
<br />
* '''GitLab''' https://vimeo.com/817610534<br />
<br />
* '''Bitbucket''' https://vimeo.com/826230267<br />
<br />
= Pull Requests via Jenkins Running on Docker =<br />
<br />
== Prerequisites ==<br />
<ol><br />
<li> VM running Linux and Docker<br />
<li> JQ JSON Parser - Statically compiled binary version<br />
<ol><br />
<li> https://stedolan.github.io/jq/<br />
</ol><br />
<li> GitHub PAT credentials to connect to GitHub<br />
<ol><br />
<li> The user for these PAT credentials has read access to the repository<br />
</ol><br />
<li> Globalyzer.com credentials for logging in to globalyzer.com<br />
<ol><br />
<li> username<br />
<li> password<br />
</ol><br />
<li> Obtain a copy of Globalyzer Lite from https://www.globalyzer.com/gzserver/home/installclient (requires Globalyzer.com credentials)<br />
<li> A copy of your Globalyzer.license from globalyzer.com or your local globalyzer server instance.<br />
<li> Jenkins will use the following URL to download all plugins required during the installation. This URL is required to be reachable from the VM Jenkins is being installed on prior to starting the install. <br />
<ol><br />
<li> https://updates.jenkins.io/update-center.json <br />
</li><br />
</ol><br />
<li> Optional:<br />
<ol><br />
<li> Apache or nginx could be installed and running on the VM itself as a reverse proxy to front the Jenkins instance </li><br />
</ol><br />
</ol><br />
<br />
== File System Configuration ==<br />
<p><br />
If Apache is installed as per normal for many Lingoport systems, the following is required to configure Apache to permit proper connection to the Jenkins Docker container<br />
</p><br />
<ol><br />
<li> Create the directory structure for the volume storage used by jenkins. Be sure there is sufficient space. Base install will consume 650MB of space for the volume itself. </li><br />
<code> mkdir ~/docker/jenkins/lingoport/bin </code><br />
<li> Place the Globalyzer License into the lingoport directory created </li><br />
<code> cp ~/PRC-Docker/Globalyzer.license ~/docker/jenkins/lingoport/ </code><br />
<li> Copy the downloaded copy of Globalyzer Lite into the lingoport directory </li><br />
<code> cp ~/PRC-Docker/globalyzer-lite-VERSION.zip ~/docker/jenkins/lingoport/ </code><br />
<li> Copy the jq binary into the bin directory and set the permissions </li><br />
<code> <br />
cp -p ~/PRC-Docker/jq ~/docker/jenkins/lingoport/bin/<br />
chmod +x ~/docker/jenkins/lingoport/bin/jq<br />
</code><br />
<li> Unzip the Globalyzer Lite zip file in the lingoport directory and remove the zip file once complete </li> <br />
<code><br />
cd ~/docker/jenkins/lingoport<br />
unzip globalyzer-lite-VERSION.zip<br />
rm ./globalyzer-lite-VERSION.zip<br />
</code><br />
<li> Create the .globalyzerrc file in the jenkins home directory, add the proper credentials and set the permissions </li><br />
<code><br />
vi .globalyzerrc<br />
chmod 600 .globalyzerrc<br />
</code><br />
<li> Confirm the contents of the .globalyzerrc file are entered like this: (Note no equals or colon, just whitespace between key and value) </li><br />
<code><br />
username <GLOBALYZER LOGIN USERNAME><br />
password <GLOBALYZER LOGIN PASSWORD><br />
server <URL of Globalyzer Server> <br />
</code><br />
</ol><br />
<br />
== Launching the Jenkins Docker Container ==<br />
<br />
<p> Retrieve these two items as they are now required to proceed </p><br />
<ol><br />
<li> Obtain the UID and GID for the user that Docker is being ran by.<br />
<li> Identify the the port that Jenkins should be listening on.<br />
<ol><br />
<li> In the example below it was determined to be 8085 </li><br />
</ol><br />
</li><br />
</ol><br />
<p> The next command line is an example of what would be used to start the docker instance for Jenkins. Here is an explanation of the switches being used when no proxy is required for the container to reach required destinations. </p><br />
<p><br />
The command string will create a new container instance that will automatically restart the container unless specifically<br />
stopped. It will also reuse the existing container on a restart of the OS. If the container is stopped before the<br />
reboot is performed using <i> sudo docker stop "CONTAINTER ID" </i>, it will need to be started using <i>sudo docker start "CONTAINER ID"</i><br />
</p><br />
<ol><br />
<li> The -d detaches the command being run from the terminal. Normally this is something that will only be used<br />
once everything is in place and confirmed to be working. For initial startup, its use can be ignored. </li><br />
<li> The -u is for setting the uid/gid of the user that owns the volume storage identified earlier. This user<br />
should also be the user that is starting the docker instance. </li><br />
<li> The -p 8085:8080 is the port external to internal mapping identified earlier. The 8080 would never change,<br />
only the external port is modifiable </li><br />
<li> The -p 50000:50000 is for mapping between Jenkins instances only. Not required for standalone systems. </li><br />
<li> The JENKINS_OPTS sets the baseurl for the application </li><br />
<li> The -v mounts the prior locally created file system to the running docker instance as a volume and mas it. </li><br />
<li> The jenkins/jenkins:lts-jdk17 is the long term support image for Jenkins. Currently, it is Jenkins 2.452.2 </li><br />
</ol><br />
<br />
<code><br />
sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \<br />
--env JENKINS_OPTS="--prefix=/jenkins" --restart=unless-stopped \<br />
-v /USER_HOME_DIR/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk17<br />
</code><br />
<br />
<p> <br />
If a proxy is required to be leveraged by the container to reach destinations the next command line would be used to start the docker instance for Jenkins instead of the previous one. Note the additional env variables that are added to support the proxy.<br />
</p><br />
<br />
<code><br />
sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \<br />
--env JENKINS_OPTS="--prefix=/jenkins" \<br />
--env http_proxy="http://<PROXY_URL>:<PORT>" \<br />
--env https_proxy="http://<PROXY_URL>:<PORT>" \<br />
--restart=unless-stopped \<br />
-v /home/centos/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk17<br />
</code><br />
<br />
<p><br />
This will download the required images and start the container. There will be a message about initial password, <br />
make note of it as it will be used to log into Jenkins<br />
</p><br />
<br />
<br />
<br />
<code><br />
*************************************************************<br />
*************************************************************<br />
*************************************************************<br />
Jenkins initial setup is required. An admin user has been created and a password generated.<br />
Please use the following password to proceed to installation:<br />
<br />
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx<br />
<br />
This may also be found at: /var/jenkins_home/secrets/initialAdminPassword<br />
<br />
*************************************************************<br />
*************************************************************<br />
*************************************************************<br />
</code><br />
<br />
== Browser Connected Configuration ==<br />
<p> Go to application using the browser and use the above password to log in initially </p><br />
[[File:Unlock-jenkins.png|noframe|500px]]<br />
<br />
<p> At this screen select Install Suggested Plugins </p><br />
[[File:Customize-jenkins.png|noframe|500px]]<br />
<br />
<p> The plugins will begin to install, this will only be a few minutes. </p><br />
[[File:Getting-started-jenkins.png|noframe|500px]]<br />
<br />
<p> Create the Admin account. This will be a new account outside of what was used to connect initially. It will be the administrator account. </p><br />
[[File:Create-first-admin-user-jenkins.png|noframe|500px]]<br />
<br />
<p> This sets up the URL with a path to the instance. It will include /jenkins so it should be something like “http(s)://<YOUR FQDN/jenkins/ </p><br />
[[File:Instance-config-jenkins.png|noframe|500px]]<br />
<br />
<p> The base Jenkins system install is complete at this point. </p><br />
[[File:Jenkins-ready.png|noframe|500px]]<br />
<br />
<p> Click Start using Jenkins and the Dashboard appears </p><br />
[[File:Dashboard-jenkins.png|noframe|500px]]<br />
<br />
<p> The alert is caused by this running locally and not using nodes. Click on it and select “Dismiss” </p><br />
[[File:Node-details-jenkins.png|noframe|500px]]<br />
<br />
<p> If once this is cleared, this message appears. It is due to a reverse proxy being used that needs to have some additional configuration. </p><br />
[[File:Proxy-error-jenkins.png|noframe|500px]]<br />
<br />
<p> When using Apache as a reverse proxy, adding these two entries to the virtual host SSL configuration should correct the error. </p><br />
<br />
<code><br />
RequestHeader set X-Forwarded-Proto "https"<br />
<br />
RequestHeader set X-Forwarded-Port "443"<br />
</code><br />
<br />
== Add GUI Configuration Items for Pull Requests and Commits ==<br />
<br />
<p> Install and additional plugin called “Discard Old Builds” by going to Manage Jenkins → Manage Plugins → Available Plugins and search for “Discard old builds” </p><br />
[[File:Plugins1-jenkins.png|noframe|500px]]<br />
<br />
<p> Install an additional plugin called “Throttle Concurrent Builds” by going to Manage Jenkins → Manage Plugins → Available Plugins and search for “Throttle Concurrent Builds”</p><br />
[[File:Plugins2-jenkins.png|noframe|500px]]<br />
<br />
<p> Once plugin is installed to go Manage Jenkins → Configure System → Throttle Concurrent Builds and select Add Category: </p><br />
<br />
<p> Create Category Name PRC_THROTTLE and set Maximum Total Concurrent Builds = 1 and Maximum Concurrent Builds Per Node = 1. </p><br />
<br />
<p> Select “Apply” to save </p><br />
<br />
<p> Set up the environment variables in Jenkins: </p><br />
<br />
<ol><br />
<li> Select the Environment Variables checkbox<br />
<li> Select Add and add the following<br />
<ol><br />
<li> For a GitHub Installation<br />
<ol> <br />
<li> GITHUB_PRC_FILES = $JENKINS_HOME/lingoport/<globalyzer-lite-dir>/GitHub_PRC </li><br />
</ol><br />
<li> PATH = $PATH:$JENKINS_HOME/lingoport/bin<br />
<li> If https is to be used for connecting to the git repos set to true. If ssh is to be used to connect to git repos set to false.<br />
<ol><br />
<li> useHTTPS = true or false </li><br />
</ol><br />
</li><br />
<li> Optional - If Proxy is required: <br />
<ol> <br />
<li> Add entry _JAVA_OPTIONS with proxy details as shown in screenshot below </li><br />
<li> Dhttp.proxyHost=<FQDN> Dhttp.proxyPort=<PORT> Dhttps.proxyHost=<FQDN> Dhttps.proxyPort=<PORT> </li><br />
</ol><br />
</li> <br />
</ol><br />
</li><br />
</ol><br />
<br><br />
<p></p><br />
[[File:Env-var1-jenkins.png|noframe|500px]]<br />
<br><br />
[[File:Env-var2-jenkins.png|noframe|500px]]<br />
<br><br />
[[File:Jenkins_proxy_for_java.png|noframe|500px]]<br />
<br><br />
<p> Click Apply and Save </p><br />
<br><br />
<p> Add new API token to be used by GitHub Webhook </p><br />
<p> In Jenkins create a new API token for the user that will be running the build. This will be required to be added to the webhook to permit connection back to the Jenkins instance </p><br />
The credentials used for GitHub will require read access to the git repository.<br />
<ol><br />
<li> Select Dashboard → Manage Jenkins → Manage Users → Select the gear icon on the right side of the Admin user (Admin user created earlier)<br />
<li> In the API Token section, select Add new Token<br />
<li> Set the name of the new token to GitHub-PRC-TOKEN or something that is memorable and can identify with the PRC action.<br />
<ol><br />
<li> Be sure to copy the token value as it will never be displayed beyond this time. </li><br />
</ol><br />
</li><br />
</ol><br />
<p></p><br />
[[File:Api-token-2.png|noframe|500px]]<br />
<br />
==Add File System Configuration Items for Pull Requests and Commits==<br />
<p>Leave the GUI and go back to the file system </p><br />
<ol><br />
<li> Edit the github.properties file:<br />
<ol><br />
<li> /HOME_DIR/docker/jenkins/lingoport/globalyzer-lite-VERSION/GitHub_PRC/github.properties.<br />
<li> Update the github.login and github.oauth with the appropriate PAT values that were created ahead of time.<br />
</li><br />
</ol><br />
<li> When using https there will need to be a .netrc file placed in the jenkins_home directory inside of the container. This can be placed in the volume directory at /HOME_DIR/docker/jenkins/.netrc<br />
<ol><br />
<li> login <GitHub login ID> (Not email)<br />
<li> password PAT<br />
</li><br />
</ol><br />
<li> When using ssh there will need to be the ssh public and private keys stored in the /HOME_DIR/docker/jenkins/.ssh directory. Also with ssh be sure to manually connect to the git repo prior to using the PRC scripts. The known_hosts file needs to be updated and that is a manual process that requires manually accepting the key. This should only be needed to be performed once.<br />
<li> Run the installer for Globalyzer-Lite. This must be done inside of the contains so everything is properly set up in that environment<br />
<ol> <br />
<li> Obtain the container id<br />
<ol> <br />
<li> <code> sudo docker container ps </code><br />
</li><br />
</ol><br />
<li> <code> sudo docker exec -it CONTAINER ID /bin/bash </code><br />
<li> <code> cd ~/lingoport/globalyzer-lite-VERSION </code><br />
<li> <code>./install-lite.sh </code> (Should return Globalyzer Lite installation completed successfully)<br />
</li><br />
</ol><br />
</li><br />
</ol><br />
<br />
== Create Jenkins Build for Pull Requests and Commits via GitHub ==<br />
<br />
<ol><br />
<li> Log into Jenkins and go to the Dashboard<br />
<li> Select New Item<br />
<li> Create an item name for the PRC build. <br />
<li> Use an item name that is memorable, something like GitHub-PRC is fine.<br />
<li> Select Freestyle Project<br />
<li> Select OK<br />
<li> Add a description (optional)<br />
<li> Select “This project is parameterized”<br />
<li> Add two string parameters<br />
<ol> <br />
<li> payload = NOT_SET<br />
<li> LITE_PROJECT_DEFINITION = DEFAULT<br />
<ol><br />
<li> DEFAULT looks for the project definition to exist in the lingoport directory of the working branch as such: lingoport/LiteProjectDefinition.xml<br />
</li><br />
</ol><br />
<li> Select “Throttle Concurrent Builds”<br />
<ol><br />
<li> Set Maximum Total Concurrent Builds to 1<br />
<li> Set Maximum Concurrent Builds Per Node to 1<br />
</li><br />
</ol><br />
<li> In Build Triggers Section<br />
<ol><br />
<li> Select Trigger builds remotely (e.g., from scripts)<br />
<li> In the Authentication Token place a token you wish to use. Something like HOOK for example.<br />
</li><br />
</ol><br />
<li> In Build Steps Section<br />
<ol><br />
<li> Select Execute Shell<br />
<li> Place the following shell code<br />
<ul><br />
<li> <code> set +x </code><br />
<li> <code> $GITHUB_PRC_FILES/job_lite_pr.sh $GITHUB_PRC_FILES/pr_message.html </code><br />
</li><br />
</ul><br />
<li> In the Post-build Actions<br />
<ol><br />
<li> Select Discard Old Builds<br />
<li> Set Days to keep builds to 14<br />
</li><br />
</ol><br />
<li> Save the configuration<br />
</li><br />
</ol><br />
</li><br />
</ol><br />
<br />
=== GitHub Configuration ===<br />
<br />
<p> <br />
Webhooks are calls made from the GitHub side down to the Jenkins instance. They provide information required by the Jenkins build to properly scan the files that were either committed or had a pull request performed on them. This is discussed in detail in the Videos found in earlier sections of this page. <br />
</p><br />
<p><br />
Below is a summary of the steps. <br />
</p><br />
<ol><br />
<li> Log into GitHub<br />
<li> Navigate to the repository that will have pull requests and commits applied to it<br />
<li> Click on Settings → Webhooks→ Add webhook<br />
<li> Enter the following:<br />
<ol><br />
<li> Payload URL <br />
<ol><br />
<li> URL found in Build Triggers Section of the Jenkins Build<br />
<li> It will likely require the API Token generated prior along with the username that the build in Jenkins was created<br />
<li> ht<span>tps://USER:TOKEN@JENKINS_URL/jenkins/job/BUILD_NAME/buildWithParameters?token=BUILD_TOKEN</span><br />
</li><br />
</ol><br />
<li> Content Type application/x-www-form-urlencoded<br />
<li> Radio button: Let me select individual events<br />
<ol><br />
<li> Pushes<br />
<li> Pull Requests<br />
<li> Pushes, Pull Requests<br />
</li><br />
</ol><br />
</li><br />
</ol><br />
<li> Using the Recent Deliveries tab it's possible to check the status of a web hook call to confirm that it worked correctly.<br />
<ol><br />
<li> There should be a build triggered for each webhook called submitted<br />
<li> If there are issues use the Redeliver button to resend<br />
</li><br />
</ol><br />
</li><br />
</ol><br />
<br />
=== Install Validation ===<br />
<p> This completes the basic installation. To confirm that everything is working correctly. </p><br />
<ol><br />
<li> Log into GitHub and navigate to a repository<br />
<li> Make a change directly to a file in the GitHub repository and “Commit” the change (assuming Commits are enabled). <br />
<li> Switch to Jenkins and confirm that the build was triggered and successfully completed<br />
<li> Switch back to GitHub and click on the commit id for the modification in and confirm that there is an associated summary.<br />
<li> Clicking on the File/Line link in the summary should show the code line and modification made.<br />
</li><br />
</ol><br />
<br />
<br><br />
<br />
<p> This is an image of the Analysis Summary in GitHub for a commit </p><br />
[[File:Intall-validation-1.png|noframe|500px]]<br />
<br />
<br><br />
<br />
<p> This image shows the line of code that is presented when clicking on the link in the Analysis Summary </p><br />
[[File:Install-validation-2.png|noframe|500px]]<br />
<br />
== SAML Integration (Optional) ==<br />
<p><br />
To optionally leverage SAML in place of the local user login system, follow the instructions found on this page<br />
<p><br />
<br />
[[Docker Jenkins SAML Configuration]]<br />
<br />
= Jenkins Upgrade when using Docker =<br />
<br />
== Upgrade Required Indication ==<br />
<br />
When logging into Jenkins, there will be a message on the Manage Jenkins page indicating that a new version is available.<br />
<br />
[[file:Before_Upgrade.png |800px]]<br />
<br />
== Upgrade Procedure ==<br />
<br />
1. Log into the VM containing docker with a user that has sudo privileges.<br />
<br />
2. Stop the existing jenkins/jenkins:lts-jdk17 container (this may be lts-jdk21 as well)<br />
sudo docker stop <CONTAINER ID><br />
<br />
3. Make a backup of the existing Jenkins directory that is mounted as a volume. All Jenkins files are contained on the file system, there is no associated DB.<br />
$ cp -pr /home/<USER_DIR>/docker/jenkins /home/USER_DIR/docker/jenkins_<MMDDYYYY><br />
<br />
4. Pull the latest version of the jenkins/jenkins:lts-jdk21 from docker.io. Note that it will indicate a newer image has been downloaded.<br />
sudo docker pull jenkins/jenkins:lts-jdk21<br />
lts-jdk21: Pulling from jenkins/jenkins<br />
53c88f1dfeb7: Pull complete<br />
1354b1aa1de9: Pull complete<br />
0c31487ae971: Pull complete<br />
3c9c60b56010: Pull complete<br />
5681e84d3308: Pull complete<br />
a2375046a225: Pull complete<br />
967448ab02b6: Pull complete<br />
7eb8b3c92c00: Pull complete<br />
24446a3ce816: Pull complete<br />
f63b11f22c5e: Pull complete<br />
650135881854: Pull complete<br />
f703dc66a915: Pull complete<br />
Digest: sha256:23b84d1066dbe69f2c17288c83ac071127092d726f14b3b80444d868468619c7<br />
Status: Downloaded newer image for jenkins/jenkins:lts-jdk21<br />
da080ad7c1d0: Pull complete<br />
Digest: sha256:90f7f78a7e114516216b6c0a06e00c597d6490597caec9d7bd7a95ce5c7dada0<br />
Status: Downloaded newer image for jenkins/jenkins:lts-jdk17<br />
docker.io/jenkins/jenkins:lts-jdk17<br />
<br />
5. Start the new container with the updated image using one of the two options below depending upon whether a proxy is required to be leveraged from inside of the container or not. Adjust the home directory location as needed for the particular installation.<br />
<br />
'''Option #1''' - Run the newly updated container to start Jenkins with the latest<br />
version (Command is the same as the one used initially to run) <br />
<br />
$ sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \<br />
--env JENKINS_OPTS="--prefix=/jenkins" \<br />
--restart=unless-stopped \<br />
-v /home/centos/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk21<br />
$<br />
$ sudo docker container ls<br />
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES<br />
f9fe867b7c00 jenkins/jenkins:lts-jdk21 "/usr/bin/tini -- /u…" 16 seconds ago Up 15 seconds 0.0.0.0:50000->50000/tcp, :::50000->50000/tcp, 0.0.0.0:8086->8080/tcp, :::8086->8080/tcp heuristic_proskuriakova<br />
<br />
'''Option #2''' - Run the newly updated container to start Jenkins with<br />
the latest version of Jenkins when a proxy is needed for outgoing communications<br />
version (Command is the same as the one used initially to run) <br />
<br />
$ sudo docker run -d -u 1000:1000 -p 8085:8080 -p 50000:50000 \<br />
--env JENKINS_OPTS="--prefix=/jenkins" \<br />
--env http_proxy="http://<PROXY_URL>:<PORT>" \<br />
--env https_proxy="http://<PROXY_URL>:<PORT>" \<br />
--restart=unless-stopped \<br />
-v /home/centos/docker/jenkins:/var/jenkins_home jenkins/jenkins:lts-jdk21<br />
$<br />
$ sudo docker container ls<br />
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES<br />
9e2650b5ec1c jenkins/jenkins:lts-jdk21 "/usr/bin/tini -- /u…" 33 seconds ago Up 32 seconds 0.0.0.0:50000->50000/tcp, :::50000->50000/tcp, 0.0.0.0:8085->8080/tcp, :::8085->8080/tcp elegant_engelbart<br />
<br />
<br />
6. Confirm that the new version is running properly by logging in the web interface and going to the manage jenkins section. There should not be mention of a new version being available. <br />
<br />
[[file:After_Upgrade.png |800px]]<br />
<br />
7. At the bottom of this page, the current version will be displayed in the footer.<br />
<br />
8. The old container can be removed if desired at this point.<br />
sudo docker rm <CONTAINER ID><br />
<br />
9. The old image can also be removed if desired at this point.<br />
sudo docker rmi <IMAGE ID><br />
<br />
10. The system will now be running the latest version of the Jenkins docker image and both the old images and containers will have been removed.<br />
<br />
= Historical Version of the Pull Request/Commit Globalyzer Scanning =<br />
<br />
[[ Historical Pull Request | Historical Pull Request ]]</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Globalyzer_and_ChatGPT&diff=99473Globalyzer and ChatGPT2025-10-08T13:04:07Z<p>Rwilliams: /* Cost of Incorporation */</p>
<hr />
<div>== ChatGPT Use in Globalyzer ==<br />
<br />
=== Enabling ChatGPT Support for a Globalyzer Project ===<br />
<br />
In the Globalyzer Settings of each project locate "Apply ChatGPT prediction to Globalyzer reports" select "Yes". This will bring up a ChatGPT token form entry. <br />
* Copy your ChatGPT Token in this field. <br />
* The ChatGPT token will start with "sk-" and is generally around 50 characters in length.<br />
<br/><br />
<br />
[[File:Chatgpt-GZ-Enable.png|1024px|center]]<br />
<br />
=== ChatGPT Functionality ===<br />
<br />
Once the Token has been added to the configuration, the next time a project analysis is performed there will be an automatic query to ChatGPT for every item identified as an issue by Globalyzer. This occurs post Globalyzer Scan and the run details are logged in the same way as a project run. It is important to note that the scan will only occur if a particular issue has not been previously scanned. This means that if an analysis is performed again immediately after an analysis run, only issues which are new or changed since the previous analysis will be sent to ChatGPT. This reduces the overall cost of incorporating ChatGPT into a Globalyzer environment. <br />
<br />
==== Issues Page ChatGPT Indicators ====<br />
Once an analysis has completed, opening up the Issues page will show there is a new icon being provided for each issue detected as highlighted below. This icon indicates the ChatGPT determined result for each issue as to whether ChatGPT identifies the issue as either:<br />
* True positive "Orange" <br />
* False positive "Green".<br />
<br />
[[File:IssuesChatgptIcons.png|1024px|center]]<br />
<br />
==== Issues Page Individual Issue ChatGPT Indicators ====<br />
<br />
When expanding a single issue as shown below, in addition to the normally found items, there is an indicator for AI Prediction similar to what was shown prior to expanding the issue. Also, below the code snippet there is a new button "AI prediction reason". Selecting this button will send another request to ChatGPT asking for a more detailed explanation of why the line item was determined to be a true or false positive. Using this functionality will provide more information on what the determining factor was as additional time is taken by ChatGPT to analyze the reasoning. This can sometimes result in a change from true positive to false positive or the reverse. <br />
<br />
[[File:IssuesAiPredictive.png|1024px|center]]<br />
<br />
==== AI Prediction Reason ====<br />
<br />
*Currently In Progress<br />
<br />
=== Cost of Incorporation ===<br />
<br />
Although it is impossible to be completely accurate regarding the costs of leveraging ChatGPT in Globalyzer, below are some real use data collecting that should prove useful. The Prediction Type of "AI Prediction" is the automated prediction that is obtained after each project analysis is performed. The AI Prediction Reason is the more in-depth query to determine the reasoning that a true positive or false positive was arrived at in the AI Prediction Scan.<br />
<br />
*The below data was captured in October of 2025 for reference.<br />
<br />
{| border="1" class="wikitable" style="text-align:left; width=50%;"<br />
! Prediction Type !! Issues Checked !! Tokens Used !! Tokens/Issue !! Positive Issues !! Negative Issues !! Input Cost !! Output Cost !! Total Cost !! Cost/Issue<br />
|-<br />
| AI Prediction || 96 || 5417 || 56.43 || 48 || 48 || $0.014 || $0.015 || $0.03 || $0.003125 <br />
|-<br />
| AI Prediction Reason|| TBD || TBD || TBD || TBD || TBD || TBD || TBD || TBD || TBD<br />
|}</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Globalyzer_and_ChatGPT&diff=99469Globalyzer and ChatGPT2025-10-07T20:55:18Z<p>Rwilliams: /* AI Prediction Reason */</p>
<hr />
<div>== ChatGPT Use in Globalyzer ==<br />
<br />
=== Enabling ChatGPT Support for a Globalyzer Project ===<br />
<br />
In the Globalyzer Settings of each project locate "Apply ChatGPT prediction to Globalyzer reports" select "Yes". This will bring up a ChatGPT token form entry. <br />
* Copy your ChatGPT Token in this field. <br />
* The ChatGPT token will start with "sk-" and is generally around 50 characters in length.<br />
<br/><br />
<br />
[[File:Chatgpt-GZ-Enable.png|1024px|center]]<br />
<br />
=== ChatGPT Functionality ===<br />
<br />
Once the Token has been added to the configuration, the next time a project analysis is performed there will be an automatic query to ChatGPT for every item identified as an issue by Globalyzer. This occurs post Globalyzer Scan and the run details are logged in the same way as a project run. It is important to note that the scan will only occur if a particular issue has not been previously scanned. This means that if an analysis is performed again immediately after an analysis run, only issues which are new or changed since the previous analysis will be sent to ChatGPT. This reduces the overall cost of incorporating ChatGPT into a Globalyzer environment. <br />
<br />
==== Issues Page ChatGPT Indicators ====<br />
Once an analysis has completed, opening up the Issues page will show there is a new icon being provided for each issue detected as highlighted below. This icon indicates the ChatGPT determined result for each issue as to whether ChatGPT identifies the issue as either:<br />
* True positive "Orange" <br />
* False positive "Green".<br />
<br />
[[File:IssuesChatgptIcons.png|1024px|center]]<br />
<br />
==== Issues Page Individual Issue ChatGPT Indicators ====<br />
<br />
When expanding a single issue as shown below, in addition to the normally found items, there is an indicator for AI Prediction similar to what was shown prior to expanding the issue. Also, below the code snippet there is a new button "AI prediction reason". Selecting this button will send another request to ChatGPT asking for a more detailed explanation of why the line item was determined to be a true or false positive. Using this functionality will provide more information on what the determining factor was as additional time is taken by ChatGPT to analyze the reasoning. This can sometimes result in a change from true positive to false positive or the reverse. <br />
<br />
[[File:IssuesAiPredictive.png|1024px|center]]<br />
<br />
==== AI Prediction Reason ====<br />
<br />
*Currently In Progress<br />
<br />
=== Cost of Incorporation ===<br />
<br />
Although it is impossible to be completely accurate regarding the costs of leveraging ChatGPT in Globalyzer, below are some real use data collecting that should prove useful. The Prediction Type of "AI Prediction" is the automated prediction that is obtained after each project analysis is performed. The AI Prediction Reason is the more in-depth query to determine the reasoning that a true positive or false positive was arrived at in the AI Prediction Scan.<br />
<br />
*The below data was captured in October of 2025 for reference.<br />
<br />
{| border="1" class="wikitable" style="text-align:left; width=50%;"<br />
! Prediction Type !! Issues Checked !! Tokens Used !! Positive Issues !! Negative Issues !! Input Cost !! Output Cost !! Total Cost<br />
|-<br />
| AI Prediction || 96 || 5417 || 48 || 48 || $0.014 || $0.015 || $0.03 <br />
|-<br />
| AI Prediction Reason|| TBD || TBD || TBD || TBD || TBD || TBD || TBD<br />
|}</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Creating_a_Globalyzer_Project&diff=99468Creating a Globalyzer Project2025-10-07T20:03:34Z<p>Rwilliams: </p>
<hr />
<div><br />
<br />
[[File:Step4GlobalyzerPDF.jpg|1024px|center]]<br />
<br />
Both of the prompts on this page depend on files in the '''Settings -> System Files -> Globalyzer Lite Files''' and '''Custom Scripts'''. If these are not set up then use the default settings.<br />
<br />
'''Script to Generate Globalyzer reports'''.<br />
<br />
'''Apply ChatGPT Prediction to Globalyzer Reports'''. Enables and disables the automatic prediction of ChatGPT to all issues detected by Globalyzer.<br />
<br />
'''ChatGPT Token'''. Token used by ChatGPT when leveraging ChatGPT predictions.<br />
<br />
For details on using ChatGPT with Globalyzer see [[Globalyzer and ChatGPT]]<br />
<br />
'''Project Definition File''' Where in the repository is the Globalyzer Lite Project Definition file? <br />
<br />
For example, if your repository is <br />
<nowiki>https://github.com/Acme/MyProject</nowiki><br />
<br />
and the Lite Project Definition File is in the '''lingoport''' folder and called '''PDF.xml'''<br />
<br />
then the entry for Project Definition File would be:<br />
<br />
/lingoport/PDF.xml<br />
<br />
If the path or the file is incorrect or the file is not a Globalyzer Lite Project Definition file, then the error will be: '''Invalid lite file'''. The file needs to be correct before moving forward.<br />
<br />
Select '''Next'''<br />
<br />
[[Confirm Globalyzer Configuration]]<br />
<br />
[[Name The Project and Type|<== Back to Step 3: Name the Project ]]</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Globalyzer_and_ChatGPT&diff=99467Globalyzer and ChatGPT2025-10-07T20:03:05Z<p>Rwilliams: /* AI Prediction Reason */</p>
<hr />
<div>== ChatGPT Use in Globalyzer ==<br />
<br />
=== Enabling ChatGPT Support for a Globalyzer Project ===<br />
<br />
In the Globalyzer Settings of each project locate "Apply ChatGPT prediction to Globalyzer reports" select "Yes". This will bring up a ChatGPT token form entry. <br />
* Copy your ChatGPT Token in this field. <br />
* The ChatGPT token will start with "sk-" and is generally around 50 characters in length.<br />
<br/><br />
<br />
[[File:Chatgpt-GZ-Enable.png|1024px|center]]<br />
<br />
=== ChatGPT Functionality ===<br />
<br />
Once the Token has been added to the configuration, the next time a project analysis is performed there will be an automatic query to ChatGPT for every item identified as an issue by Globalyzer. This occurs post Globalyzer Scan and the run details are logged in the same way as a project run. It is important to note that the scan will only occur if a particular issue has not been previously scanned. This means that if an analysis is performed again immediately after an analysis run, only issues which are new or changed since the previous analysis will be sent to ChatGPT. This reduces the overall cost of incorporating ChatGPT into a Globalyzer environment. <br />
<br />
==== Issues Page ChatGPT Indicators ====<br />
Once an analysis has completed, opening up the Issues page will show there is a new icon being provided for each issue detected as highlighted below. This icon indicates the ChatGPT determined result for each issue as to whether ChatGPT identifies the issue as either:<br />
* True positive "Orange" <br />
* False positive "Green".<br />
<br />
[[File:IssuesChatgptIcons.png|1024px|center]]<br />
<br />
==== Issues Page Individual Issue ChatGPT Indicators ====<br />
<br />
When expanding a single issue as shown below, in addition to the normally found items, there is an indicator for AI Prediction similar to what was shown prior to expanding the issue. Also, below the code snippet there is a new button "AI prediction reason". Selecting this button will send another request to ChatGPT asking for a more detailed explanation of why the line item was determined to be a true or false positive. Using this functionality will provide more information on what the determining factor was as additional time is taken by ChatGPT to analyze the reasoning. This can sometimes result in a change from true positive to false positive or the reverse. <br />
<br />
[[File:IssuesAiPredictive.png|1024px|center]]<br />
<br />
==== AI Prediction Reason ====<br />
TBD<br />
<br />
=== Cost of Incorporation ===<br />
<br />
Although it is impossible to be completely accurate regarding the costs of leveraging ChatGPT in Globalyzer, below are some real use data collecting that should prove useful. The Prediction Type of "AI Prediction" is the automated prediction that is obtained after each project analysis is performed. The AI Prediction Reason is the more in-depth query to determine the reasoning that a true positive or false positive was arrived at in the AI Prediction Scan.<br />
<br />
*The below data was captured in October of 2025 for reference.<br />
<br />
{| border="1" class="wikitable" style="text-align:left; width=50%;"<br />
! Prediction Type !! Issues Checked !! Tokens Used !! Positive Issues !! Negative Issues !! Input Cost !! Output Cost !! Total Cost<br />
|-<br />
| AI Prediction || 96 || 5417 || 48 || 48 || $0.014 || $0.015 || $0.03 <br />
|-<br />
| AI Prediction Reason|| TBD || TBD || TBD || TBD || TBD || TBD || TBD<br />
|}</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Globalyzer_and_ChatGPT&diff=99466Globalyzer and ChatGPT2025-10-07T20:02:52Z<p>Rwilliams: /* TBD */</p>
<hr />
<div>== ChatGPT Use in Globalyzer ==<br />
<br />
=== Enabling ChatGPT Support for a Globalyzer Project ===<br />
<br />
In the Globalyzer Settings of each project locate "Apply ChatGPT prediction to Globalyzer reports" select "Yes". This will bring up a ChatGPT token form entry. <br />
* Copy your ChatGPT Token in this field. <br />
* The ChatGPT token will start with "sk-" and is generally around 50 characters in length.<br />
<br/><br />
<br />
[[File:Chatgpt-GZ-Enable.png|1024px|center]]<br />
<br />
=== ChatGPT Functionality ===<br />
<br />
Once the Token has been added to the configuration, the next time a project analysis is performed there will be an automatic query to ChatGPT for every item identified as an issue by Globalyzer. This occurs post Globalyzer Scan and the run details are logged in the same way as a project run. It is important to note that the scan will only occur if a particular issue has not been previously scanned. This means that if an analysis is performed again immediately after an analysis run, only issues which are new or changed since the previous analysis will be sent to ChatGPT. This reduces the overall cost of incorporating ChatGPT into a Globalyzer environment. <br />
<br />
==== Issues Page ChatGPT Indicators ====<br />
Once an analysis has completed, opening up the Issues page will show there is a new icon being provided for each issue detected as highlighted below. This icon indicates the ChatGPT determined result for each issue as to whether ChatGPT identifies the issue as either:<br />
* True positive "Orange" <br />
* False positive "Green".<br />
<br />
[[File:IssuesChatgptIcons.png|1024px|center]]<br />
<br />
==== Issues Page Individual Issue ChatGPT Indicators ====<br />
<br />
When expanding a single issue as shown below, in addition to the normally found items, there is an indicator for AI Prediction similar to what was shown prior to expanding the issue. Also, below the code snippet there is a new button "AI prediction reason". Selecting this button will send another request to ChatGPT asking for a more detailed explanation of why the line item was determined to be a true or false positive. Using this functionality will provide more information on what the determining factor was as additional time is taken by ChatGPT to analyze the reasoning. This can sometimes result in a change from true positive to false positive or the reverse. <br />
<br />
[[File:IssuesAiPredictive.png|1024px|center]]<br />
<br />
==== AI Prediction Reason ====<br />
<br />
=== Cost of Incorporation ===<br />
<br />
Although it is impossible to be completely accurate regarding the costs of leveraging ChatGPT in Globalyzer, below are some real use data collecting that should prove useful. The Prediction Type of "AI Prediction" is the automated prediction that is obtained after each project analysis is performed. The AI Prediction Reason is the more in-depth query to determine the reasoning that a true positive or false positive was arrived at in the AI Prediction Scan.<br />
<br />
*The below data was captured in October of 2025 for reference.<br />
<br />
{| border="1" class="wikitable" style="text-align:left; width=50%;"<br />
! Prediction Type !! Issues Checked !! Tokens Used !! Positive Issues !! Negative Issues !! Input Cost !! Output Cost !! Total Cost<br />
|-<br />
| AI Prediction || 96 || 5417 || 48 || 48 || $0.014 || $0.015 || $0.03 <br />
|-<br />
| AI Prediction Reason|| TBD || TBD || TBD || TBD || TBD || TBD || TBD<br />
|}</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Creating_a_Globalyzer_Project&diff=99465Creating a Globalyzer Project2025-10-07T19:55:27Z<p>Rwilliams: </p>
<hr />
<div><br />
<br />
[[File:Step4GlobalyzerPDF.jpg|1024px|center]]<br />
<br />
Both of the prompts on this page depend on files in the '''Settings -> System Files -> Globalyzer Lite Files''' and '''Custom Scripts'''. If these are not set up then use the default settings.<br />
<br />
'''Script to Generate Globalyzer reports'''.<br />
<br />
'''Apply ChatGPT Prediction to Globalyzer Reports'''. Enables and disables the automatic prediction of ChatGPT to all issues detected by Globalyzer.<br />
<br />
'''ChatGPT Token'''. Token used by ChatGPT when leveraging ChatGPT predictions.<br />
<br />
'''Project Definition File''' Where in the repository is the Globalyzer Lite Project Definition file? <br />
<br />
For example, if your repository is <br />
<nowiki>https://github.com/Acme/MyProject</nowiki><br />
<br />
and the Lite Project Definition File is in the '''lingoport''' folder and called '''PDF.xml'''<br />
<br />
then the entry for Project Definition File would be:<br />
<br />
/lingoport/PDF.xml<br />
<br />
If the path or the file is incorrect or the file is not a Globalyzer Lite Project Definition file, then the error will be: '''Invalid lite file'''. The file needs to be correct before moving forward.<br />
<br />
Select '''Next'''<br />
<br />
[[Confirm Globalyzer Configuration]]<br />
<br />
[[Name The Project and Type|<== Back to Step 3: Name the Project ]]</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Creating_a_Globalyzer_Project&diff=99464Creating a Globalyzer Project2025-10-07T19:29:11Z<p>Rwilliams: </p>
<hr />
<div><br />
<br />
[[File:Step4GlobalyzerPDF.jpg|1024px|center]]<br />
<br />
Both of the prompts on this page depend on files in the '''Settings -> System Files -> Globalyzer Lite Files''' and '''Custom Scripts'''. If these are not set up then use the default setttings.<br />
<br />
'''Script to Generate Globalyzer reports'''. Select the default value unless a script has been uploaded already. Most of the time the default value will be the correct one.<br />
<br />
'''Project Definition File''' Where in the repository is the Globalyzer Lite Project Definition file? <br />
<br />
For example, if your repository is <br />
<nowiki>https://github.com/Acme/MyProject</nowiki><br />
<br />
and the Lite Project Definition File is in the '''lingoport''' folder and called '''PDF.xml'''<br />
<br />
then the entry for Project Definition File would be:<br />
<br />
/lingoport/PDF.xml<br />
<br />
If the path or the file is incorrect or the file is not a Globalyzer Lite Project Definition file, then the error will be: '''Invalid lite file'''. The file needs to be correct before moving forward.<br />
<br />
Select '''Next'''<br />
<br />
[[Confirm Globalyzer Configuration]]<br />
<br />
[[Name The Project and Type|<== Back to Step 3: Name the Project ]]</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=File:Step4GlobalyzerPDF.jpg&diff=99463File:Step4GlobalyzerPDF.jpg2025-10-07T19:27:10Z<p>Rwilliams: Rwilliams uploaded a new version of File:Step4GlobalyzerPDF.jpg</p>
<hr />
<div></div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Globalyzer_and_ChatGPT&diff=99462Globalyzer and ChatGPT2025-10-07T19:07:29Z<p>Rwilliams: Created page with "== ChatGPT Use in Globalyzer == === Enabling ChatGPT Support for a Globalyzer Project === In the Globalyzer Settings of each project locate "Apply ChatGPT prediction to Glob..."</p>
<hr />
<div>== ChatGPT Use in Globalyzer ==<br />
<br />
=== Enabling ChatGPT Support for a Globalyzer Project ===<br />
<br />
In the Globalyzer Settings of each project locate "Apply ChatGPT prediction to Globalyzer reports" select "Yes". This will bring up a ChatGPT token form entry. <br />
* Copy your ChatGPT Token in this field. <br />
* The ChatGPT token will start with "sk-" and is generally around 50 characters in length.<br />
<br/><br />
<br />
[[File:Chatgpt-GZ-Enable.png|1024px|center]]<br />
<br />
=== ChatGPT Functionality ===<br />
<br />
Once the Token has been added to the configuration, the next time a project analysis is performed there will be an automatic query to ChatGPT for every item identified as an issue by Globalyzer. This occurs post Globalyzer Scan and the run details are logged in the same way as a project run. It is important to note that the scan will only occur if a particular issue has not been previously scanned. This means that if an analysis is performed again immediately after an analysis run, only issues which are new or changed since the previous analysis will be sent to ChatGPT. This reduces the overall cost of incorporating ChatGPT into a Globalyzer environment. <br />
<br />
==== Issues Page ChatGPT Indicators ====<br />
Once an analysis has completed, opening up the Issues page will show there is a new icon being provided for each issue detected as highlighted below. This icon indicates the ChatGPT determined result for each issue as to whether ChatGPT identifies the issue as either:<br />
* True positive "Orange" <br />
* False positive "Green".<br />
<br />
[[File:IssuesChatgptIcons.png|1024px|center]]<br />
<br />
==== Issues Page Individual Issue ChatGPT Indicators ====<br />
<br />
When expanding a single issue as shown below, in addition to the normally found items, there is an indicator for AI Prediction similar to what was shown prior to expanding the issue. Also, below the code snippet there is a new button "AI prediction reason". Selecting this button will send another request to ChatGPT asking for a more detailed explanation of why the line item was determined to be a true or false positive. Using this functionality will provide more information on what the determining factor was as additional time is taken by ChatGPT to analyze the reasoning. This can sometimes result in a change from true positive to false positive or the reverse. <br />
<br />
[[File:IssuesAiPredictive.png|1024px|center]]<br />
<br />
==== AI Prediction Reason ====<br />
<br />
==TBD==<br />
<br />
=== Cost of Incorporation ===<br />
<br />
Although it is impossible to be completely accurate regarding the costs of leveraging ChatGPT in Globalyzer, below are some real use data collecting that should prove useful. The Prediction Type of "AI Prediction" is the automated prediction that is obtained after each project analysis is performed. The AI Prediction Reason is the more in-depth query to determine the reasoning that a true positive or false positive was arrived at in the AI Prediction Scan.<br />
<br />
*The below data was captured in October of 2025 for reference.<br />
<br />
{| border="1" class="wikitable" style="text-align:left; width=50%;"<br />
! Prediction Type !! Issues Checked !! Tokens Used !! Positive Issues !! Negative Issues !! Input Cost !! Output Cost !! Total Cost<br />
|-<br />
| AI Prediction || 96 || 5417 || 48 || 48 || $0.014 || $0.015 || $0.03 <br />
|-<br />
| AI Prediction Reason|| TBD || TBD || TBD || TBD || TBD || TBD || TBD<br />
|}</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=File:IssuesChatgptIcons.png&diff=99461File:IssuesChatgptIcons.png2025-10-07T18:24:58Z<p>Rwilliams: </p>
<hr />
<div></div>Rwilliamshttps://wiki.lingoport.com/index.php?title=File:IssuesAiPredictive.png&diff=99460File:IssuesAiPredictive.png2025-10-07T18:16:06Z<p>Rwilliams: Show API prediction results in issue</p>
<hr />
<div>== Summary ==<br />
Show API prediction results in issue</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=File:Chatgpt-GZ-Enable.png&diff=99459File:Chatgpt-GZ-Enable.png2025-10-07T17:29:14Z<p>Rwilliams: Show configuration for ChatGPT in Globalyzer</p>
<hr />
<div>== Summary ==<br />
Show configuration for ChatGPT in Globalyzer</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Custom_Git_Data_Source_Credential&diff=99455Custom Git Data Source Credential2025-09-26T20:06:29Z<p>Rwilliams: /* Bitbucket / Custom Git */</p>
<hr />
<div>= Bitbucket / Custom Git =<br />
[Administrator]<br />
<br />
For special git repositories, such as Bitbucket, use Custom Git. It provides flexibility for special Git systems.<br />
<br />
'''Bitbucket PAT Creation Notes'''<br />
<br />
Bitbucket allows PATs to be created at the Project or the Repository level. In this description the PAT was created at the repository level<br />
<br />
* Within the Bitbucket repository, go to Repository Settings -> Access Tokens select Create Repository Access Token <br />
[[File:BitbucketPATCreationForm.jpg|400px]]<br />
<br />
* Give the token a name that can be easily identified<br />
* Select the scopes of Read/Write/Delete<br />
* Press Create<br />
<br />
There should be a new screen that appears showing the newly created PAT and the various ways to leverage it. Be sure to save the contents of this screen as everything but the email user.email section will no longer be visible once closed.<br />
<br />
The sections that are of most importance have been marked in red. These will be referenced later when filling out the configuration in Command Center. They are, from top to bottom:<br />
* Repository access token<br />
* How to use this token with your Git Repository<br />
* The git config user.email<br />
<br />
[[File:BitbucketPATCreationDetails.jpg|400px]]<br />
<br />
Now that the PAT has been created, it can be incorporated into Command Center as follows.<br />
<br />
'''Create a new Data Source Credential'''<br />
* Open the Settings section (Gear Icon) from the Dashboard page<br />
* Select "Maintenance Mode" (Must be an Administrator to do this) to unlock the Data Source Credentials area<br />
* Select the Data Source Credentials<br />
* Select the [[File:CreateIcon.jpg|30px]] ('''Create new credential''') button on the Manage Data Source Credentials page. <br />
<br />
'''Select the Custom Git card'''<br />
<br />
[[File:BitbucketCard.jpg|100px]] <br />
<br />
'''The Custom Git Connection Form will open'''<br />
<br />
[[File:BitbucketGitCredentials.jpg|800px]]<br />
<br />
'''Enter the details for the Custom Git Form'''<br />
* Enter a Username.<br />
** The username will be x-token-auth as provided by Bitbucket as part of the git clone URL when the PAT was initially created. This can be found in the "How to use this token with your Git Repository" when the PAT was created marked in red in the screenshot prior.<br />
** Its from here: ''git clone https://'''x-token-auth''':<PAT>@bitbucket.org/<ACCOUNT>/<REPO>.git''<br />
* Enter the Personal access token<br />
** The PAT is the Token itself as provided by Bitbucket in the top text box marked in red in the screenshot prior marked as "Repository Access Token". This is the PAT itself.<br />
* Enter the Commit author - You can put whatever you wish here<br />
* Enter the Commit email<br />
** If the Bitbucket provided user.email is input here, when commits occur from Command Center, within Bitbucket commits from Command Center will show as the token name provided when the PAT was created in Bitbucket. This is the "git config user.email" token marked in red in the screenshot prior.<br />
* Enter the Git server URL, for example, ''https://bitbucket.org/account/'' <br />
* '''Next'''<br />
<br />
[[File:BitbucketCredentialName.jpg|800px]]<br />
<br />
'''Give the new credential a name'''<br />
* The name should be something that is easily identified when applied from a project as the being the correct PAT<br />
* Assign it to applicable managers<br />
* '''Create'''<br />
<br />
The system should return to the '''Manage Data Source Credentials''' page with "Credential created" note and the new credential should be listed.<br />
<br />
At this point, this credential can be added to a project in the same manner as any other source credential.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=LRM_strings_Support&diff=99454LRM strings Support2025-09-26T15:23:37Z<p>Rwilliams: /* Regular Expression */</p>
<hr />
<div>== Example .strings file ==<br />
<pre><br />
<br />
/* Class = "IBUILabel"; text = "or"; ObjectID = "DTz-P6-Y3D"; */<br />
"DTz-P6-Y3D.text" = "or";<br />
<br />
/* Class = "IBUITextField"; placeholder = "Username"; ObjectID = "FiC-Ph-wbo"; */<br />
"FiC-Ph-wbo.placeholder" = "Username";<br />
<br />
/* Class = "IBUILabel"; text = "The username or password was incorrect."; ObjectID = "tDx-oc-GBE"; */<br />
"tDx-oc-GBE.text" = "The username or \"password\" was incorrect.";<br />
</pre><br />
<br />
== ''strings'' parser type ==<br />
=== valid IOS .strings syntax ===<br />
Files that use the ''strings'' parser are expected to have valid IOS .strings syntax<br />
<br />
=== .strings uses the ''strings'' parser type===<br />
When defining a project containing LRM Standard .strings resource files, there is no need to define a ''&lt;parser-type&gt;'' as the ''strings'' parser will always be used.<br />
<br />
=== unique file extension needs to define ''strings'' parser type ===<br />
If a unique file extension is a valid .strings file, then the ''&lt;parser-type&gt;'' should be ''strings'' in the project definition file.<br />
<br />
== Missed Translations for new files ==<br />
By default, LRM will '''ignore''' missed translations; text that is the same in both the base resource file and the target resource file.<br />
The exception is for a new IOS file; a file that has never been processed by LRM. Typically, when a new IOS base resource file is created, the subsequent target locale files are also created. This means that the target file exists but contains text of the base locale rather than the target locale. <br />
In this case, for IOS files, if the file has not been processed by LRM, then any missed translation will be contained in the next prep kit. Once the file has been processed by LRM, any new missed translations will be ignored.<br />
<br />
== Regular Expression ==<br />
<br />
When working with and IOS resource file .strings format, the default parameter regex setting will be the following:<br />
<pre><br />
%([dsf]|(d$[dsf@])|(.df)|@)|%\{w+\}<br />
</pre><br />
<br />
This will handle most use cases correctly. However, if the TMS being used is XTM, please consider that XTM will automatically append an integer to the parameters in the returned translations if there currently is not one present in the base resource file. For details on this, please refer to the section :<br />
* [[XTM_Cloud#XTM_Special_Instructions_-_parameters_.28e.g._.25d.2C_etc.29]]<br />
<br />
As noted in the XTM Cloud Special Instructions, the correct course to handle this is to modify the base resource file so that it has the integers already applied in the parameter(s). At that point the returned translations will be allowed to import without causing a parameter mismatch error due to XTM modifying the parameter automatically.<br />
<br />
There is one additional change that should be made to the parameter regex setting in order to pull this all together. Modify the parameter regex in the project from the default to the below:<br />
<pre><br />
(%([dsf]|(\d+\$[dsf@])|(\.\d+f)|@))|%\{\w+\}<br />
</pre><br />
<br />
This change will take into account the possibility of there being an integer in the parameter as would be added by XTM so that the source and translations containing the XTM parameter with the integer will be correctly identified as a parameter by Localyzer allowing it to correctly validate parameter mismatches.<br />
<br />
Failure to make this change after both the base resource and translations have incorporated the additional integer within their respective parameter(s) will result in the inability to detect a legitimate parameter mismatch for these specific parameters as Localyzer will no longer see them as parameters and simply allow them to pass as normal strings. This results in not having the benefit of parameter mismatch checking for those specific parameters.<br />
<br />
== Bad IOS comments don't cause any errors. Why not?==<br />
If an IOS file has a comment that is <b>not ended properly</b>, no error is thrown.<br />
For example, if a comment doesn't have an ending '''*/''', such as '''/*Bad comment''', then no errors are found. <br />
In other words, the file is still parsed correctly even though the comment is missing the ending syntax. Since the file is parsed correctly, LRM is able to find the key/values.<br />
<br />
== Command Center Configuration ==<br />
<TO_DO><br />
<br />
<br />
<br />
<br />
== '''Internal''' Example of Project Definition for Resources ==<br />
<br />
'''This section is for internal checking only, not for Command Center.'''<br />
<br />
The following is an example of strings resource file definitions. See [[Supported_Resource_Bundles#Resource_Extensions| resource extensions]] for more information.<br />
<br />
<resource-extensions><br />
<resource-extension><br />
'''&lt;!-- parser-type not needed since .strings is a standard LRM extension that maps to the ''strings'' parser type --&gt;'''<br />
'''<extension>strings</extension>'''<br />
'''<file-name-pattern/>'''<br />
'''<use-pattern-on-dflt-locale>1</use-pattern-on-dflt-locale>'''<br />
'''<file-location-pattern>l_c_v</file-location-pattern>'''<br />
'''<use-location-pattern-on-dflt-locale>1</use-location-pattern-on-dflt-locale>'''<br />
'''<base-file-encoding>UTF-8</base-file-encoding>'''<br />
'''<localized-file-encoding>UTF-8</localized-file-encoding>'''<br />
'''<parameter-regex-pattern><![CDATA[(%([dsf]|(\d+\$[dsf@])|(\.\d+f)|@))|%\{\w+\}]]></parameter-regex-pattern>'''<br />
</resource-extension><br />
<resource-extension><br />
'''''&lt;!-- parser-type is required because .myext is not a standard LRM extension --&gt;'''''<br />
'''<extension>''myext''</extension>'''<br />
'''''<parser-type>strings</parser-type>'''''<br />
'''<file-name-pattern/>'''<br />
'''<use-pattern-on-dflt-locale>1</use-pattern-on-dflt-locale>'''<br />
'''<file-location-pattern>l_c_v</file-location-pattern>'''<br />
'''<use-location-pattern-on-dflt-locale>1</use-location-pattern-on-dflt-locale>'''<br />
'''<base-file-encoding>UTF-8</base-file-encoding>'''<br />
'''<localized-file-encoding>UTF-8</localized-file-encoding>'''<br />
'''<parameter-regex-pattern><![CDATA[(%([dsf]|(\d+\$[dsf@])|(\.\d+f)|@))|%\{\w+\}]]></parameter-regex-pattern>'''<br />
</resource-extension><br />
</resource-extensions></div>Rwilliamshttps://wiki.lingoport.com/index.php?title=LRM_strings_Support&diff=99453LRM strings Support2025-09-26T15:21:51Z<p>Rwilliams: /* Regular Expression */</p>
<hr />
<div>== Example .strings file ==<br />
<pre><br />
<br />
/* Class = "IBUILabel"; text = "or"; ObjectID = "DTz-P6-Y3D"; */<br />
"DTz-P6-Y3D.text" = "or";<br />
<br />
/* Class = "IBUITextField"; placeholder = "Username"; ObjectID = "FiC-Ph-wbo"; */<br />
"FiC-Ph-wbo.placeholder" = "Username";<br />
<br />
/* Class = "IBUILabel"; text = "The username or password was incorrect."; ObjectID = "tDx-oc-GBE"; */<br />
"tDx-oc-GBE.text" = "The username or \"password\" was incorrect.";<br />
</pre><br />
<br />
== ''strings'' parser type ==<br />
=== valid IOS .strings syntax ===<br />
Files that use the ''strings'' parser are expected to have valid IOS .strings syntax<br />
<br />
=== .strings uses the ''strings'' parser type===<br />
When defining a project containing LRM Standard .strings resource files, there is no need to define a ''&lt;parser-type&gt;'' as the ''strings'' parser will always be used.<br />
<br />
=== unique file extension needs to define ''strings'' parser type ===<br />
If a unique file extension is a valid .strings file, then the ''&lt;parser-type&gt;'' should be ''strings'' in the project definition file.<br />
<br />
== Missed Translations for new files ==<br />
By default, LRM will '''ignore''' missed translations; text that is the same in both the base resource file and the target resource file.<br />
The exception is for a new IOS file; a file that has never been processed by LRM. Typically, when a new IOS base resource file is created, the subsequent target locale files are also created. This means that the target file exists but contains text of the base locale rather than the target locale. <br />
In this case, for IOS files, if the file has not been processed by LRM, then any missed translation will be contained in the next prep kit. Once the file has been processed by LRM, any new missed translations will be ignored.<br />
<br />
== Regular Expression ==<br />
<br />
When working with and IOS resource file .strings format, the default parameter regex setting will be the following:<br />
<pre><br />
%([dsf]|(d$[dsf@])|(.df)|@)|%\{w+\}<br />
</pre><br />
<br />
This will handle most use cases correctly. However, if the TMS being used is XTM, please consider that XTM will automatically append an integer to the parameters in the returned translations if there currently is not one present in the base resource file. For details on this, please refer to the section :<br />
* [[XTM_Cloud#XTM_Special_Instructions_-_parameters_.28e.g._.25d.2C_etc.29]]<br />
<br />
As noted in the XTM Cloud Special Instructions, the correct course to handle this is to modify the base resource file so that it has the integers already applied in the parameter(s). At that point the returned translations will be allowed to import without causing a parameter mismatch error due to XTM modifying the parameter automatically.<br />
<br />
There is one additional change that should be made to the parameter regex setting in order to pull this all together. Modify the parameter regex in the project from the default to the below:<br />
<pre><br />
(%([dsf]|(\d+\$[dsf@])|(\.\d+f)|@))|%\{\w+\}<br />
</pre><br />
<br />
This change will take into account the possibility of there being an integer in the parameter as would be added by XTM so that the source and translations containing the XTM parameter with the integer will be correctly identified as a parameter by Localyzer allowing it to correctly validate parameter mismatches.<br />
<br />
Failure to make this change after both the base resource and translations have incorporated the additional integer within their respective parameter(s) will result in a failure to detect a legitimate parameter mismatch for these specific parameters as Localyzer will no longer see them as parameters and simply allow them to pass as normal strings. This results in not having the benefit of parameter mismatch checking for those specific parameters.<br />
<br />
== Bad IOS comments don't cause any errors. Why not?==<br />
If an IOS file has a comment that is <b>not ended properly</b>, no error is thrown.<br />
For example, if a comment doesn't have an ending '''*/''', such as '''/*Bad comment''', then no errors are found. <br />
In other words, the file is still parsed correctly even though the comment is missing the ending syntax. Since the file is parsed correctly, LRM is able to find the key/values.<br />
<br />
== Command Center Configuration ==<br />
<TO_DO><br />
<br />
<br />
<br />
<br />
== '''Internal''' Example of Project Definition for Resources ==<br />
<br />
'''This section is for internal checking only, not for Command Center.'''<br />
<br />
The following is an example of strings resource file definitions. See [[Supported_Resource_Bundles#Resource_Extensions| resource extensions]] for more information.<br />
<br />
<resource-extensions><br />
<resource-extension><br />
'''&lt;!-- parser-type not needed since .strings is a standard LRM extension that maps to the ''strings'' parser type --&gt;'''<br />
'''<extension>strings</extension>'''<br />
'''<file-name-pattern/>'''<br />
'''<use-pattern-on-dflt-locale>1</use-pattern-on-dflt-locale>'''<br />
'''<file-location-pattern>l_c_v</file-location-pattern>'''<br />
'''<use-location-pattern-on-dflt-locale>1</use-location-pattern-on-dflt-locale>'''<br />
'''<base-file-encoding>UTF-8</base-file-encoding>'''<br />
'''<localized-file-encoding>UTF-8</localized-file-encoding>'''<br />
'''<parameter-regex-pattern><![CDATA[(%([dsf]|(\d+\$[dsf@])|(\.\d+f)|@))|%\{\w+\}]]></parameter-regex-pattern>'''<br />
</resource-extension><br />
<resource-extension><br />
'''''&lt;!-- parser-type is required because .myext is not a standard LRM extension --&gt;'''''<br />
'''<extension>''myext''</extension>'''<br />
'''''<parser-type>strings</parser-type>'''''<br />
'''<file-name-pattern/>'''<br />
'''<use-pattern-on-dflt-locale>1</use-pattern-on-dflt-locale>'''<br />
'''<file-location-pattern>l_c_v</file-location-pattern>'''<br />
'''<use-location-pattern-on-dflt-locale>1</use-location-pattern-on-dflt-locale>'''<br />
'''<base-file-encoding>UTF-8</base-file-encoding>'''<br />
'''<localized-file-encoding>UTF-8</localized-file-encoding>'''<br />
'''<parameter-regex-pattern><![CDATA[(%([dsf]|(\d+\$[dsf@])|(\.\d+f)|@))|%\{\w+\}]]></parameter-regex-pattern>'''<br />
</resource-extension><br />
</resource-extensions></div>Rwilliamshttps://wiki.lingoport.com/index.php?title=GitHub_Pull_Requests&diff=99425GitHub Pull Requests2025-08-05T15:51:44Z<p>Rwilliams: /* Create The Github Webhook */</p>
<hr />
<div>= GitHub Pull Requests & Commits Globalyzer Analysis Webhook =<br />
<br />
Follow these steps to set up a Webhook to automate Globalyzer's analysis on your repository's pull requests and/or commits.<br />
<br />
* '''Video Guide:''' https://vimeo.com/817611647<br />
<br />
== Jenkins Set Up ==<br />
<br />
=== Install Globalyzer Lite ===<br />
1. If not done so already, move the root Globalyzer Lite folder to your Jenkins file system. Create a `lingoport` directory at the root of your Jenkins system and place the downloaded globalyzer-lite folder there (e.g., /var/lib/jenkins/lingoport/globalyzer-lite). ''To avoid any errors, please do not modify or move the files in this folder unless specifically directed to do so.''<br />
<br />
2. Install Globalyzer Lite on your Jenkins system by following the instructions in the `README.txt` file (located in the globalyzer-lite folder).<br />
<br />
'''Make sure to install Lite as the `jenkins` user!'''<br />
<br />
'''Note:''' You should see the success message "Globalyzer Lite installation completed successfully" before proceeding.<br />
<br />
3. You will need to download the Globalyzer.license file from here: https://www.globalyzer.com/gzserver/home/installclient (you may need to log in with your Globalyzer.com credentials). Once downloaded, place the Globalyzer.license file into the `lingoport` directory from step 1.<br />
<br />
=== Set Up GitHub Credentials ===<br />
4. In this folder, you will find the `github.properties` file. Your GitHub credentials will need to be set in this file before proceeding (failure to set these credentials will result in an error).<br />
<br />
* For `github.login`, enter your GitHub username. Note this is not your GitHub login email, it is the username as it appears after you sign in.<br />
* For `github.oauth`, you will need to enter a Personal Access Token created for your GitHub account. To generate an access token:<br />
** Sign in to GitHub.<br />
** Select your profile icon on the top right hand side and select "Settings".<br />
** Scroll down and select "Developer settings".<br />
** Select "Personal access tokens" > "Tokens (classic)".<br />
** Select "Generate new token" > "Generate new token (classic)".<br />
** Add a note and expiration date as desired.<br />
** Under "Select scopes", select "**repo**".<br />
** Select "Generate token".<br />
** Copy the generated token and paste it into the file. Note that the token will disappear after the window is closed/changed.<br />
<br />
=== Create & Configure Jenkins Job ===<br />
5. On Jenkins, navigate to "Manage Jenkins" > "Configure System" > "Global properties" > select the "Environment variables" box > select "Add".<br />
<br />
Under name, enter `GITHUB_PRC_FILES` and for the value, enter the file path to the webhook file directory in the globalyzer-lite folder, for example: `$JENKINS_HOME/lingoport/globalyzer-lite-*.*.*_*.*/GitHub_PRC`<br />
<br />
* '''Note''': Whenever a new version of Lite is downloaded, only this environment variable's value needs to be changed rather than having to reconfigure every Jenkins job.<br />
<br />
6. On Jenkins, select "New Item" and create a new "Freestyle project". Give it a name, we recommend the format "Team.RepoName-GitHub-COMMAND" where COMMAND could be PullRequest, Commit, or PRC (for both PRs and commits) depending on what you would like to be scanned.<br />
<br />
7. Configure the project:<br />
* '''General:'''<br />
** Check the "This project is parameterized" box. Two **string** parameters are needed for the job to run properly.<br />
** payload: The first parameter is named `payload` and the default value is `NOT_SET`. This parameter is NOT set by hand. GitHub's webhooks generate data based on the GitHub event and send the JSON data to Jenkins as the payload parameter. See the [GitHub Page](https://developer.github.com/webhooks/#payloads) for more details.<br />
** LITE_PROJECT_DEFINITION: The second parameter is named `LITE_PROJECT_DEFINITION` and it's default value is `DEFAULT`. This parameter is the location of the project definition file that will be used when scanning (such as: $JENKINS_HOME/jobs/$JOB_NAME/workspace/lingoport/LiteProjectDefinition.xml). If DEFAULT, it will use the lingoport/LiteProjectDefinition.xml file from the working branch of the pull request/commit. We highly recommend setting up concurrent build throttling as well to allow builds to process one at a time. Please refer to the [Throttle Concurrent Builds](#throttle-concurrent-builds) section at the bottom of the page for more details.<br />
** Source Code Management: You may leave this as "None". The job will locate the corresponding repo and branch through the webhook's payload data.<br />
** Build Triggers: Check the "Trigger builds remotely (e.g., from scripts)" box. Under "Authentication Token", enter a token to trigger the build remotely, we recommend `HOOK`. This token will be used to set up the webhook in the following section.<br />
'''Note:''' If your job does not have the "Trigger builds remotely" option, it is likely that your Jenkins user does not have the necessary permissions.<br />
** Build: Select "Add build step" and select the "Execute shell" option. Under "Command", enter the code to execute the `job_lite_pr.sh` file and pass `pr_message.html` as an argument. If you haven't already, configure the `GITHUB_PRC_FILES` environment variable (refer to step 5) before proceeding.<br />
bash<br />
set +x<br />
$GITHUB_PRC_FILES/job_lite_pr.sh $GITHUB_PRC_FILES/pr_message.html<br />
<br />
8. Select "Save" to save the project configuration.<br />
9. Install jq on the system (if not already done): https://stedolan.github.io/jq/download/. jq is used to process the incoming webhook's JSON data.<br />
<br />
=== Create The Github Webhook ===<br />
10. Navigate to the repository where the webhook will be created.<br />
<br />
11. Select "Settings" > "Webhooks" > "Add webhook".<br />
* '''Note:''' You will need admin access to the repository to be able to access the settings.<br />
<br />
12. Under "Payload URL", use the following URL to trigger the build remotely: `https://JENKINS_URL/buildByToken/buildWithParameters/build?job=JOB_NAME&token=TOKEN`<br />
* `JENKINS_URL` is the URL to your Jenkins instance.<br />
*`JOB_NAME` is the Jenkins job name you entered in step 6.<br />
*`TOKEN` is the the token you entered in the "Build Triggers" subsection of step 7.<br />
<br />
13. Under "Content type", select `application/x-www-form-urlencoded`.<br />
<br />
14. Under "Which events would you like to trigger this webhook?", select "Let me select individual events" and then check "Pull Requests" and/or "Pushes" depending on if you want Globalyzer to scan pull requests, commits, or both.<br />
<br />
15. Ensure that the webhook is set to "Active".<br />
<br />
16. Select "Add webhook".<br />
<br />
17. Navigate to the repository where the webhook was added.<br />
<br />
18. Open/update a pull request or perform a commit depending on the option(s) you selected in step 14.<br />
<br />
19. Once complete, navigate to the Jenkins job that was created in step 6. If all of the connections were completed correctly, a build should have automatically been started.<br />
* If the build did not start automatically, navigate to the Github repo and select "Settings" > "Webhooks". Locate and select the webhook created in the last section and click "Recent Deliveries". Check for any potential issues that may have prevented the webhook from delivering the payload before trying again. Once you are ready to try again, select "Redeliver" > "Yes, redeliver this payload".<br />
** If you see an error that says "We couldn’t deliver this payload: failed to connect to host", there may be a proxy or firewall issue that is blocking the webhook. See GitHub's guide to GitHub IP addresses [https://docs.github.com/en/enterprise-cloud@latest/authentication/keeping-your-account-and-data-secure/about-githubs-ip-addresses here], and check with your IT and networking departments to set up access or forwarding of GitHub's connections before trying again.<br />
** If you see a 403 error ("No valid crumb was included in the request"), you may need to use a Jenkins API token as an added security measure. From your Jenkins home page, select the user on the top right hand side of the page > select "Configure". Under API Tokens, select "Add New Token" > enter a name > select "Generate". Copy the token (note that it will disappear once the page is changed/closed). Navigate to the webhook created in step 16 and modify the URL to include the Jenkins credentials like so: `http://JENKINS_USERNAME:JENKINS_TOKEN@JENKINS_URL/...` (Note the : and @ characters.)<br />
*** `JENKINS_USERNAME`: The username used to log into Jenkins. Note that this is not the full name of the user.<br />
*** `JENKINS_TOKEN`: The API token generated from Jenkins.<br />
** If you see a 404 error, please double check your URL from step 12. If everything looks correct, you may need to use this URL format instead for the GitHub webhook: `https://JENKINS_URL/job/JOB_NAME/buildWithParameters?token=TOKEN`.<br />
<br />
20. If the build...<br />
* '''Finished Successfully:''' Navigate to the pull request/commit from step 18 and look at the comments.<br />
** If everything was set up correctly, you should see a new comment titled "Globalyzer Analysis Summary" with a concise summary of i18n issues detected by Globalyzer Lite. With that, '''you are done!''' Future pull requests and/or commits should automatically trigger the corresponding Jenkins job and run the Globalyzer analysis.<br />
** If a comment was not created on the corresponding pull request/commit, there may be an issue. Navigate to the Jenkins job > select the most recent build > select "Console Output" > locate and fix any errors that may have occurred. If there are no visible errors and the output "Globalyzer Analysis Summary added to {commit/pull-request}" is present but there is no comment, please contact support@lingoport.com for assistance.<br />
* '''Failed:''' Select the most recent build > select "Console Output". Locate and fix any errors that may have occurred before trying step 18 again.<br />
** If you see the error "Host key verification failed" or "git@github.com: Permission denied (publickey). fatal: Could not read from remote repository.", you will need to create an ssh key. If you do not already have a .ssh directory (it may be hidden) on the root of your Jenkins system, create the directory before proceeding.<br />
*** If you already have a .ssh directory, check if you have a file named `id_rsa.pub`. If so, you may skip this step. If you do not, navigate to the .ssh directory and run the command `ssh-keygen`. It will ask where you want to save the key, it should default to the .ssh directory (enter the path to the Jenkins .ssh directory if not). Enter a passphrase if desired (it will ask you to enter it twice) to proceed. Once the key has been saved, navigate to the .ssh folder and you should see two new files: `id_rsa.pub` and `id_rsa`.<br />
*** Next, sign in to GitHub > select your profile icon on the top right hand side and select "Settings" > select "SSH and GPG keys" > select "New SSH key". Enter a title and leave the "Key type" as Authentication Key. For the "Key" field, paste the contents of the `id_rsa.pub` file and select "Add SSH Key". It is also worth making sure that GitHub is on your list of known hosts. To check, navigate to the .ssh folder on your Jenkins system and view the `known_hosts` file. If github.com is not present in the file (or the file does not exist), you will need to add it either manually with the command: `ssh-keyscan -t rsa github.com >> <PATH_TO_SSH_FOLDER>/.ssh/known_hosts` or by letting ssh do it for you when you run a git command and entering "yes" when prompted. Once complete, try step 18 again.<br />
** If you see the error "Error: Lite failed, GlobalyzerLicense: Cannot find license file", refer to step 3. Ensure that the file is in the `lingoport` directory (the program will attempt to look here: `/var/lib/jenkins/lingoport` for the license file). If your license has expired, please download the license again.<br />
** If the build finished successfully but you see an error like so: "main ERROR Unable to create file /root/.globalyzer/log/globalyzer.log", you may have installed Globalyzer Lite as the root user instead of the jenkins user (refer to step 2). To fix this, navigate to your Jenkins file system > locate the Globalyzer Lite folder > locate the `log4j2.xml` file. Modify the LOG_DIR variable like so: `<Property name="LOG_DIR">/var/lib/jenkins/.globalyzer/log/globalyzer.log</Property>`.<br />
*** If you are using an older version of Lite, you may have a `log4j.properties` file instead. If so, you want to modify the log4j.appender.FILE.File variable like so: `log4j.appender.FILE.File=/var/lib/jenkins/.globalyzer/log/globalyzer.log`.<br />
*** If you see the error "File /var/lib/jenkins/.globalyzer/log/globalyzer.log exists and is not a directory. Unable to create directory" after this fix, you just need to delete the existing .globalyzer directory from your Jenkins system by running: `rm -rf /var/lib/jenkins/.globalyzer`.<br />
<br />
=== Optional Additions ===<br />
<br />
==== Throttle Concurrent Builds ====<br />
- We highly recommend installing the "Throttle Concurrent Builds" plugin: https://plugins.jenkins.io/throttle-concurrents/throttling if not done so already. This allows multiple webhook calls to this job to execute one after the other, rather than all at the same time.<br />
- After installing the plugin, navigate to the Jenkins job created in step 6 and select "Configure". Select the "Throttle Concurrent Builds" checkbox. Select the "Throttle this project alone" option and configure the "Maximum Total Concurrent Builds" and "Maximum Concurrent Builds Per Node", we recommend leaving both values as 1 to allow the job to process each build one at a time.<br />
<br />
==== Discard Old Builds ====<br />
- We also recommend installing the "Discard Old Build" Jenkins plugin: https://plugins.jenkins.io/discard-old-build/ to automatically remove old builds. This plugin is highly configurable and helps to reduce build clutter.<br />
- After installing the plugin, navigate to the Jenkins job created in step 6 and select "Configure". Under "Post-build Actions", select "Add post-build action", and select "Discard Old Builds". You can customize how the builds are discarded here (i.e., over a set number of days, keep a max number of builds, etc.).</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Localyzer_Instrumentation&diff=99424Localyzer Instrumentation2025-07-17T13:11:05Z<p>Rwilliams: /* InContext License & Version */</p>
<hr />
<div>= Introduction =<br />
To begin working with InContext Translation and InContext QA, the Localyzer version and license must be correct.<br />
<br />
= InContext License & Version =<br />
<br />
In order to use InContext Server, your system must have a valid license. To check the license, navigate to the Settings page<br />
<br />
[[File:InContextLicense.png|center|500px]]<br />
<br />
If the system does not have a valid license, please contact ''support @ lingoport dot com''.<br />
<br />
<br />
The version of InContext Server must correspond to the version of Command Center. <br />
* Command Center 3.1.35<br />
* InContext Server 2.0.9<br />
<br />
= Next Steps =<br />
To continue installation of InContext for Translation, proceed with [[InContext_Server_Installation| InContext Server Installation]]<br />
<br />
To learn more about Localyzer Instrumentation: <br />
[[LRM_Commands_Reference#Create_Instrumented_files| LRM Instrumentation]]</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Command_Center_SSH_Bitbucket&diff=99250Command Center SSH Bitbucket2025-05-15T14:12:17Z<p>Rwilliams: /* Background */</p>
<hr />
<div>= Connecting Command Center to Bitbucket using SSH =<br />
<br />
== Background ==<br />
Its possible to connect Command Center to Bitbucket without using HTTPS, but instead using SSH. This type of connection is not possible via the Custom Git Connector in the UI as that only supports HTTPS connections. Follow this procedure to leverage an SSH connection to Bitbucket.<br />
<br />
== Process Overview ==<br />
* Creation of a GitHub repo for storing three custom scripts (Using GitHub as example for this)<br />
* Creation of a pub/private key in the Command Center Container<br />
* Adding the public key to Bitbucket Cloud Repository<br />
* Adding three custom scripts to the GitHub Repo<br />
* Creating a Custom Data Source in Command Center to access the three scripts<br />
* Leveraging the Custom Data Source from the desired Command Center Project<br />
<br />
=== Additional Notes ===<br />
Although this page details the process for Bitbucket, the same technique can be applied to other repositories such as GitLab as well. The overall process would be the same.<br />
<br />
== GitHub Repository Initial Setup ==<br />
Create a new repository in GitHub that will be used for storing the three custom scripts.<br />
* Create top level directory for storing the scripts<br />
* This directory will contain the following three scripts as described later in the document.<br />
** clone.sh<br />
** pull.sh<br />
** pushfiles.sh<br />
<br />
== Bitbucket Cloud Repository Configuration ==<br />
<br />
=== Command Center Container ===<br />
<br />
The Bitbucket repo requires a public key be added to it that is created in Command Center by the connecting user. Below is the process for creating the key to be shared with the Bitbucket Cloud Repo.<br />
* Perform this within the container itself for Command Center<br />
* Do not add a password to the key pair when prompted<br />
* The key will be in the tomcatuser home directory so it must be created by the tomcatuser preferably.<br />
* You will need set tomcatuser to /bin/bash shell from /usr/sbin/nologin as part of the below actions<br />
<br />
Follow the below command after logging into the VM and then logging into the Command Center container as the root user.<br />
<br />
root@d9dfe772ea55:/usr/local/tomcat# chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/sbin/nologin]: /bin/bash<br />
su - tomcatuser<br />
ssh-keygen -t rsa -b8192<br />
Generating public/private rsa key pair.<br />
Enter file in which to save the key (/usr/local/tomcat/.ssh/id_rsa):<br />
Creating directory /usr/local/tomcat/.ssh<br />
Enter passphrase (empty for no passphrase):<br />
Enter same passphrase again:<br />
Your identification has been saved in /usr/local/tomcat/.ssh/id_rsa<br />
Your public key has been saved in /usr/local/tomcat/.ssh/id_rsa.pub<br />
The key fingerprint is:<br />
SHA256:NwG7DJtfwj8FsXc6CWnkdzBrivXrs3rn4jkRDdUq5cc tomcatuser@d9dfe772ea55<br />
The key's randomart image is:<br />
+---[RSA 8192]----+<br />
| . o o... |<br />
| = +.+. .|<br />
| . . X ==oo |<br />
| * = Xo=+ E|<br />
| o S = *o . |<br />
| . = o.o |<br />
| . o .. |<br />
| o=.. |<br />
| .+=B. |<br />
+----[SHA256]-----+<br />
<br />
Copy the public key that was created as it will need to be input into the Bitbucket Cloud Repo for the account that is being leveraged in Bitbucket. Note this key is applied at the user level and not the repository level.<br />
<br />
=== Bitbucket Cloud Repo ===<br />
<br />
Log into the Bitbucket Cloud Server as user as the user the key will be applied. The SSH Key must be added to an account which has write access to the repo.<br />
* Click on Settings Icon to left of the User Icon<br />
* Select SSH Keys in the left column<br />
* Click on Add Key<br />
* Provide a label as appropriate<br />
* Paste the public key (Be sure it's the public key!)<br />
** In this example it is id_rsa.pub<br />
* Select Add key and the key should be listed as available<br />
** Confirm the key has r/w access to the repo as noted in the next section<br />
<br />
=== Command Center Container ===<br />
<br />
Return to the Command Center Container to perform a connection test to the desired repository. You should still be tomcatuser at this point. If not, switch to tomcatuser as before. Perform the below activities and then be sure to switch the tomcatuser shell back to nologin.<br />
<br />
cd /tmp/<br />
git clone git@bitbucket.org:<username>/<repo>.git<br />
This key is not known by any other names<br />
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes<br />
Warning: Permanently added 'bitbucket.org' (ED25519) to the list of known hosts.<br />
exit (returns you to root user)<br />
chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/bin/bash]: /usr/sbin/nologin<br />
<br />
At this point the key has been validated in Bitbucket as working.<br />
<br />
<B>NOTE:</B> At this point you have a working SSH key for Bitbucket. It's important to realize that since this is in a container it will disappear upon reinstall/upgrade of Command Center. Making a backup of the .ssh directory in the container and having it available offline for the future can help to reduce the effort of recreating this process when this occurs<br />
<br />
== Script Additions to GitHub Repository ==<br />
Add the custom scripts listed below to the repository directory in GitHub that previously created. Be sure to update the scripts with your custom information as the scripts will not work as written, the details are required.<br />
* clone.sh<br />
** Requires the following to be updated<br />
*** REPO - Obtain this path from the repository itself, there is normally a link that can be clicked to copy the path<br />
*** BRANCH_NAME<br />
* pull.sh<br />
** Requires the following to be updated<br />
*** BRANCH_NAME<br />
* pushfiles.sh<br />
** No modifications are required in this script.<br />
<br />
=== clone.sh ===<br />
<br />
**Be sure to supply the USER_NAME, REPO, BRANCH where indicated**<br />
<br />
#!/bin/bash<br />
<br />
REPO="ssh://git@bitbucket.org/<REPO>.git"<br />
BRANCH="<BRANCH_NAME>"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "Custom Clone Incoming variables:"<br />
echo ""<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " WORKSPACES_DIR = ${WORKSPACES_DIR}"<br />
echo " WORKSPACE_NAME = ${WORKSPACE_NAME}"<br />
echo " REPO = ${REPO}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git clone is $(whoami)"<br />
<br />
# For Debugging<br />
GIT_SSH_COMMAND="ssh" git clone "$REPO" "$WORKSPACES_DIR/$WORKSPACE_NAME"<br />
ret=$?<br />
echo "Clone return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
===pull.sh===<br />
<br />
**Be sure to supply the branch where indicated**<br />
<br />
#!/bin/bash<br />
<br />
BRANCH="<BRANCH_NAME>"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
echo "=================================================================="<br />
echo ""<br />
echo "Custom Pull Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git pull is $(whoami)"<br />
<br />
# For Debugging<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
GIT_SSH_COMMAND="ssh" git --git-dir="$CLIENT_SOURCE_DIR/.git" --work-tree="$CLIENT_SOURCE_DIR" pull<br />
ret=$?<br />
echo "Pull return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
=== pushfiles.sh ===<br />
<br />
#!/bin/bash<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "CUSTOM_PUSH_FILES (${PUSH_TYPE})"<br />
echo ""<br />
echo "Custom Push Files Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " IMPORT_MESSAGE = ${IMPORT_MESSAGE}"<br />
echo " IMPORT_LIST_PATH = ${IMPORT_LIST_PATH}"<br />
<br />
echo "User running pushfiles is $(whoami)"<br />
<br />
# run script<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
echo "Files to import to the repo are: "<br />
cat "${IMPORT_LIST_PATH}"<br />
while IFS= read -r f; do<br />
git add "$f"<br />
ret=$?<br />
echo "Push add status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
done < "${IMPORT_LIST_PATH}"<br />
git commit -m "${IMPORT_MESSAGE}"<br />
GIT_SSH_COMMAND="ssh" git push <br />
ret2=$?<br />
echo "Push return status $ret2"<br />
if [ $ret2 -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
<br />
== Create a new Custom Data Source ==<br />
Once the scripts have been created and placed into the GitHub repository, make the scripts accessible to Command Center by adding the directory as a new Custom Data Source<br />
* When naming the Custom Data Source consider using a name that will make it easily identifiable as to what repository and branch the Custom Data Source is pointing towards.<br />
* There will be one Custom Data source created for a single repo/branch used by Command Center<br />
** If two branches from the same repository are required, there will be two Custom Data Sources Required.<br />
<br />
== Leveraging the Custom Data Source from Command Center ==<br />
<br />
At this point, when the Command Center Project is created, simply select the Custom Data Source as the Data Source Credential. Once the project is created, it should leverage the scripts to perform any operations required on the Bitbucket repo. Initially it should show the list of resource files that are found when running validation. That is a good check for the clone.sh and pull.sh scripts. The pushfiles.sh is used when committing files back into the repository so that could take the form of a returned translation, or even a pseudo-localization file.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Command_Center_SSH_Bitbucket&diff=99249Command Center SSH Bitbucket2025-05-15T14:10:01Z<p>Rwilliams: /* Background */</p>
<hr />
<div>= Connecting Command Center to Bitbucket using SSH =<br />
<br />
== Background ==<br />
Its possible to connect Command Center to Bitbucket without using HTTPS, but instead using SSH. This type of connection is not possible via the standard Bitbucket Connector in the UI as that only supports HTTPS connections. Follow this procedure to leverage an SSH connection to Bitbucket.<br />
<br />
== Process Overview ==<br />
* Creation of a GitHub repo for storing three custom scripts (Using GitHub as example for this)<br />
* Creation of a pub/private key in the Command Center Container<br />
* Adding the public key to Bitbucket Cloud Repository<br />
* Adding three custom scripts to the GitHub Repo<br />
* Creating a Custom Data Source in Command Center to access the three scripts<br />
* Leveraging the Custom Data Source from the desired Command Center Project<br />
<br />
=== Additional Notes ===<br />
Although this page details the process for Bitbucket, the same technique can be applied to other repositories such as GitLab as well. The overall process would be the same.<br />
<br />
== GitHub Repository Initial Setup ==<br />
Create a new repository in GitHub that will be used for storing the three custom scripts.<br />
* Create top level directory for storing the scripts<br />
* This directory will contain the following three scripts as described later in the document.<br />
** clone.sh<br />
** pull.sh<br />
** pushfiles.sh<br />
<br />
== Bitbucket Cloud Repository Configuration ==<br />
<br />
=== Command Center Container ===<br />
<br />
The Bitbucket repo requires a public key be added to it that is created in Command Center by the connecting user. Below is the process for creating the key to be shared with the Bitbucket Cloud Repo.<br />
* Perform this within the container itself for Command Center<br />
* Do not add a password to the key pair when prompted<br />
* The key will be in the tomcatuser home directory so it must be created by the tomcatuser preferably.<br />
* You will need set tomcatuser to /bin/bash shell from /usr/sbin/nologin as part of the below actions<br />
<br />
Follow the below command after logging into the VM and then logging into the Command Center container as the root user.<br />
<br />
root@d9dfe772ea55:/usr/local/tomcat# chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/sbin/nologin]: /bin/bash<br />
su - tomcatuser<br />
ssh-keygen -t rsa -b8192<br />
Generating public/private rsa key pair.<br />
Enter file in which to save the key (/usr/local/tomcat/.ssh/id_rsa):<br />
Creating directory /usr/local/tomcat/.ssh<br />
Enter passphrase (empty for no passphrase):<br />
Enter same passphrase again:<br />
Your identification has been saved in /usr/local/tomcat/.ssh/id_rsa<br />
Your public key has been saved in /usr/local/tomcat/.ssh/id_rsa.pub<br />
The key fingerprint is:<br />
SHA256:NwG7DJtfwj8FsXc6CWnkdzBrivXrs3rn4jkRDdUq5cc tomcatuser@d9dfe772ea55<br />
The key's randomart image is:<br />
+---[RSA 8192]----+<br />
| . o o... |<br />
| = +.+. .|<br />
| . . X ==oo |<br />
| * = Xo=+ E|<br />
| o S = *o . |<br />
| . = o.o |<br />
| . o .. |<br />
| o=.. |<br />
| .+=B. |<br />
+----[SHA256]-----+<br />
<br />
Copy the public key that was created as it will need to be input into the Bitbucket Cloud Repo for the account that is being leveraged in Bitbucket. Note this key is applied at the user level and not the repository level.<br />
<br />
=== Bitbucket Cloud Repo ===<br />
<br />
Log into the Bitbucket Cloud Server as user as the user the key will be applied. The SSH Key must be added to an account which has write access to the repo.<br />
* Click on Settings Icon to left of the User Icon<br />
* Select SSH Keys in the left column<br />
* Click on Add Key<br />
* Provide a label as appropriate<br />
* Paste the public key (Be sure it's the public key!)<br />
** In this example it is id_rsa.pub<br />
* Select Add key and the key should be listed as available<br />
** Confirm the key has r/w access to the repo as noted in the next section<br />
<br />
=== Command Center Container ===<br />
<br />
Return to the Command Center Container to perform a connection test to the desired repository. You should still be tomcatuser at this point. If not, switch to tomcatuser as before. Perform the below activities and then be sure to switch the tomcatuser shell back to nologin.<br />
<br />
cd /tmp/<br />
git clone git@bitbucket.org:<username>/<repo>.git<br />
This key is not known by any other names<br />
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes<br />
Warning: Permanently added 'bitbucket.org' (ED25519) to the list of known hosts.<br />
exit (returns you to root user)<br />
chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/bin/bash]: /usr/sbin/nologin<br />
<br />
At this point the key has been validated in Bitbucket as working.<br />
<br />
<B>NOTE:</B> At this point you have a working SSH key for Bitbucket. It's important to realize that since this is in a container it will disappear upon reinstall/upgrade of Command Center. Making a backup of the .ssh directory in the container and having it available offline for the future can help to reduce the effort of recreating this process when this occurs<br />
<br />
== Script Additions to GitHub Repository ==<br />
Add the custom scripts listed below to the repository directory in GitHub that previously created. Be sure to update the scripts with your custom information as the scripts will not work as written, the details are required.<br />
* clone.sh<br />
** Requires the following to be updated<br />
*** REPO - Obtain this path from the repository itself, there is normally a link that can be clicked to copy the path<br />
*** BRANCH_NAME<br />
* pull.sh<br />
** Requires the following to be updated<br />
*** BRANCH_NAME<br />
* pushfiles.sh<br />
** No modifications are required in this script.<br />
<br />
=== clone.sh ===<br />
<br />
**Be sure to supply the USER_NAME, REPO, BRANCH where indicated**<br />
<br />
#!/bin/bash<br />
<br />
REPO="ssh://git@bitbucket.org/<REPO>.git"<br />
BRANCH="<BRANCH_NAME>"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "Custom Clone Incoming variables:"<br />
echo ""<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " WORKSPACES_DIR = ${WORKSPACES_DIR}"<br />
echo " WORKSPACE_NAME = ${WORKSPACE_NAME}"<br />
echo " REPO = ${REPO}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git clone is $(whoami)"<br />
<br />
# For Debugging<br />
GIT_SSH_COMMAND="ssh" git clone "$REPO" "$WORKSPACES_DIR/$WORKSPACE_NAME"<br />
ret=$?<br />
echo "Clone return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
===pull.sh===<br />
<br />
**Be sure to supply the branch where indicated**<br />
<br />
#!/bin/bash<br />
<br />
BRANCH="<BRANCH_NAME>"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
echo "=================================================================="<br />
echo ""<br />
echo "Custom Pull Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git pull is $(whoami)"<br />
<br />
# For Debugging<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
GIT_SSH_COMMAND="ssh" git --git-dir="$CLIENT_SOURCE_DIR/.git" --work-tree="$CLIENT_SOURCE_DIR" pull<br />
ret=$?<br />
echo "Pull return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
=== pushfiles.sh ===<br />
<br />
#!/bin/bash<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "CUSTOM_PUSH_FILES (${PUSH_TYPE})"<br />
echo ""<br />
echo "Custom Push Files Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " IMPORT_MESSAGE = ${IMPORT_MESSAGE}"<br />
echo " IMPORT_LIST_PATH = ${IMPORT_LIST_PATH}"<br />
<br />
echo "User running pushfiles is $(whoami)"<br />
<br />
# run script<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
echo "Files to import to the repo are: "<br />
cat "${IMPORT_LIST_PATH}"<br />
while IFS= read -r f; do<br />
git add "$f"<br />
ret=$?<br />
echo "Push add status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
done < "${IMPORT_LIST_PATH}"<br />
git commit -m "${IMPORT_MESSAGE}"<br />
GIT_SSH_COMMAND="ssh" git push <br />
ret2=$?<br />
echo "Push return status $ret2"<br />
if [ $ret2 -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
<br />
== Create a new Custom Data Source ==<br />
Once the scripts have been created and placed into the GitHub repository, make the scripts accessible to Command Center by adding the directory as a new Custom Data Source<br />
* When naming the Custom Data Source consider using a name that will make it easily identifiable as to what repository and branch the Custom Data Source is pointing towards.<br />
* There will be one Custom Data source created for a single repo/branch used by Command Center<br />
** If two branches from the same repository are required, there will be two Custom Data Sources Required.<br />
<br />
== Leveraging the Custom Data Source from Command Center ==<br />
<br />
At this point, when the Command Center Project is created, simply select the Custom Data Source as the Data Source Credential. Once the project is created, it should leverage the scripts to perform any operations required on the Bitbucket repo. Initially it should show the list of resource files that are found when running validation. That is a good check for the clone.sh and pull.sh scripts. The pushfiles.sh is used when committing files back into the repository so that could take the form of a returned translation, or even a pseudo-localization file.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Command_Center_Installation&diff=99222Command Center Installation2025-04-17T12:56:33Z<p>Rwilliams: </p>
<hr />
<div>= Pre-Requisites=<br />
Before installing or updating Command Center, please verify this section is complete. <br />
<br />
== Introduction ==<br />
<br />
=== Basic Deployment Diagram ===<br />
<br />
The Lingoport system clones repository either for Globalyzer or Localyzer, or both. Access to the VM with Docker is necessary in order to install the Lingoport products. That may be internal to the customer or on a system hosted and managed by Lingoport. <br />
<br />
Furthermore, for Localyzer projects, resource files (files that need translation, not code) is sent to the LSP or the TMS. <br />
<br />
[[File:Docker Deployed Command Center.jpg|500px|center]]<br />
<br />
* Repositories may be inside or outside a customer's network<br />
* '''Lingoport Command Center System''' may be inside or outside a customer's network<br />
* Translation system, LSP may be inside or outside a customer's network. <br />
<br />
This leads to a number of configurations, all supported by Lingoport, with security enforced either by Lingoport or by the customer in terms of IT, Firewall, access, etc.<br />
<br />
=== IT ===<br />
When '''Lingoport hosts''' Command Center access to the repositories and to the LSP/TMS will need to be granted. Lingoport will then be in charge of security which IP addresses have access to what part of the application or the API entry points. <br />
<br />
When installing Command Center '''on premises''', the customer '''IT''' group is very important to the successful deployment of the Lingoport applications when installing the suite on site. In particular, the IT group that sets up the Linux system must understand the usage model for the system. <br />
Lingoport requires a meeting with the parties responsible for setting up and maintaining the host system <b>before</b> installation can properly begin. The hope is that once the system is setup for installation, minimal IT interaction is necessary.<br />
<br />
<br />
Preparations must be made with the '''IT''' team to ensure that all '''prerequisites''' are met before installation. For new installations, this is the recommended method to use to verify that all the various actors work together well.<br />
<br />
=== Requirements ===<br />
Before installing Command Center, the following needs to be configured:<br />
* Hardware <br />
* Linux <br />
* Docker<br />
* Firewall<br />
* Https<br />
<br />
The next sections on this page address each one of these points and more.<br />
<br />
==Hardware & Software Requirements==<br />
The following sections describe the hardware and software requirements for Command Center.<br />
<br />
Please note that the Globalyzer Server installation is in a different section. <br />
<br />
===Hardware Requirements ===<br />
<br />
<br />
{| border="1" class="wikitable" style="width=50%"<br />
! Element<br />
! Required<br />
|-<br />
! CPU<br />
| 2 (4 better)<br />
|-<br />
! Memory<br />
| 32 GB<br />
|-<br />
! Disk<br />
| 500 GB<br />
|}<br />
<br />
The [[Terms_and_Definitions#GlobalyzerServer|Globalyzer Server]] may be hosted by Lingoport, reside on another server, or be installed on the same system. Other Linux and Windows machines may have Globalyzer clients installed.<br />
<br />
===Software requirements===<br />
<br />
Since this is a Docker installation, most of the containers will be managed by Docker. However, volumes will be mounted on the Linux virtual machine and a database configuration file will reside on the VM: This requires Linux and a Docker installation.<br />
<br />
=== Support Browsers and Versions ===<br />
The following browsers are supported:<br />
* Chrome: 117+<br />
* Edge: 117+<br />
* Firefox: 71+<br />
<br />
==Access and Ports / Firewall==<br />
<br />
Command Center may need to be accessible by Lingoport and customer personnel to configure jobs, check the console if any problem arise, run jobs if necessary. Command Center needs to be accessible by many customer actors, including development teams, management, and QA, Lingoport, Translation Vendors.<br />
<br />
=== Ports ===<br />
<br />
===== Internal to company network =====<br />
<br />
{| border="1" class="wikitable" style="text-align:left; width=50%;"<br />
!Services!!Ports!!Inbound (session)!!Outbound (session)!!Notes<br />
|-<br />
|SSH (for system config/maintenance)|| 22 || Y || N || System configuration and maintenance<br />
|-<br />
|Command Center || 8083 (HTTP) and/or 443 (HTTPS) || Y || N || Default 8083 (configurable at install time) HTTPS requires reverse proxy Ex: Apache and Installation of SSL certificate.<br />
|-<br />
|[[Terms_and_Definitions#translationvendor|Translation Vendor]] interactions: FTP/FTPS/SFTP (MemoQ, etc.) || 21 (FTP) or 443 (FTPS) or 22 (SFTP - recommended) || (FTP/S only) || Y || FTP/FTPS also require data ports (> 1024). Recommend SFTP if possible.<br />
|-<br />
|[[Terms_and_Definitions#translationvendor|Translation Vendor]] interactions: Trados Enterprise, XTM and Memsource || 80 (HTTP) optional. 443 (HTTPS) required. || (Some cases) || Y || May need to be external if XTM/Memsource not installed on premise.<br />
|-<br />
|SMTP/SMTPS || 25 or 465 or 587 || N || Y || Depends on corporate mail setup.<br />
|-<br />
|Globalyzer Server (Optional) || 80 or 443 || N || Y || Only needed when Globalyzer Server is on premises<br />
|-<br />
|Repository Access || 22 (SSH) 443 (HTTPS/S3) 3690 (SVN) 7990 (Bitbucket) 7999 (Bitbucket) 8080 (TFS) || N || Y || VCS systems can vary, check with particular port(s) being used (Could be external/internal/both) <br />
|}<br />
<br />
==== External access ====<br />
<br />
{| border="1" class="wikitable" style="text-align:left; width=50%;"<br />
!Services!!Ports!!Inbound!!Outbound!!Notes<br />
|-<br />
|Lingoport SSH access || 22 || Y || N || Optional. Recommended for ease of upgrades and maintenance.<br />
|-<br />
|RHEL/CentOS/Ubuntu Packages || 80 (Debian) 443 (RHEL) || N || Y || Operating system packages access (Most likely external, but could be managed internally as well)<br />
|-<br />
|Globalyzer Server || 80 and 443 || N || Y || Access to Globalyzer Server in Lingoport Cloud for rule sets (Unless using on-premises Globalyzer Server)<br />
|-<br />
|hub.docker.com || 80 and 443 || N || Y || Command Center Image location<br />
|-<br />
|Repository Access || 22 (SSH) 443 (HTTPS/S3) 3690 (SVN) 7990 (Bitbucket) 7999 (Bitbucket) 8080 (TFS) || N || Y || VCS systems can vary, check with particular port(s) being used (Could be external/internal/both)<br />
|}<br />
<br />
==HTTPS==<br />
<br />
HTTPS is recommended but not necessary for the Command Center installation. HTTPS may already be set up or your IT may have a standard on how to set up HTTPS. If that's the case, go the next section. <br />
<br />
Otherwise, follow this link for a suggested HTTPS configuration:<br />
* [[ HTTPS configuration | HTTPS Configuration ]]<br />
<br />
==HTTP/2==<br />
<br />
HTTP/2 is recommended but not necessary for the Command Center installation as it will provide a noticeable performance boost when leveraged. HTTP/2 does require HTTPS be used so this will only be possible if the previous HTTPS configuration has already been performed. <br />
<br />
If HTTP/2 support will be added, follow this link for a suggested HTTP/2 configuration:<br />
* [[ HTTP2 Configuration | HTTP2 Configuration ]]<br />
<br />
== Email Sender ==<br />
Email notifications are sent to a project configured recipients . See [[ Projects_page#Create_a_new_project | Create a new project ]] after this installation.<br />
For those notifications to be sent, the following will be configured in the settings. <br />
<br />
The following information will then be needed:<br />
* Host URL ''(like smpt.gmail.com for instance)''<br />
* Authorization method ''(SMTP, SMTPS, etc.)''<br />
* Sender email address ''(localyzer@customerdomain.com for instance)''<br />
* Sender password<br />
<br />
== Docker Install==<br />
Docker is a platform that allows you to easily develop, test, and deploy applications as containers. This section will walk you through the process of installing Docker on a Linux system.<br />
<br />
The supported versions of Linux are:<br />
<br />
* [[Installing Docker on RedHat Enterprise Linux 8 |RedHat Enterprise Linux 8]]<br />
* [[Installing Docker on CentOS 7 |CentOS 7]] (EOL June 2024)<br />
* [[Installing Docker on RedHat Enterprise Linux 7|RedHat Enterprise Linux 7]] (EOL June 2024)<br />
* [[Oracle Linux 8]]<br />
* [[Installing Docker on Ubuntu 20.04|Ubuntu 20.04]]<br />
* [[Installing_Docker_on_Amazon_Linux_2|Amazon Linux 2]]<br />
<br />
Other versions of Linux may work correctly, but these are the versions and processes that have been verified.<br />
<br />
== Credentials ==<br />
<br />
When deploying Command Center, the configuration determines if the user management is done by Command Center itself, via an LDAP, or via SSO (using SAML).<br />
<br />
=== Command Center User Database ===<br />
<br />
One administration user is configured when Command Center is installed. Contact support (at) lingoport (dot) com in order to get an administration user and password. That user can then create Command Center users. It is strongly recommended to change the first administration password and keep it safe.<br />
<br />
=== LDAP ===<br />
<br />
* LDAP Connection <br />
* Management<br />
<br />
=== SSO ===<br />
<br />
* SSO Connection<br />
* Management<br />
<br />
See: [[Command Center SSO Installation]]<br />
<br />
= New Command Center Installation =<br />
<br />
==sudo user==<br />
A user, such as <code>centos</code> or <code>ec2-user</code>, with <code>sudo</code> privileges is required as the user under which to install Command Center. <br />
* Note: This should not be the legacy <code>jenkins</code> user.<br />
<br />
==Create the database conf file==<br />
Use the sudo user home for Docker, such as /home/centos for CentOS systems and /home/ec2-user for RedHat virtual systems. <br />
<br />
The mysql and conf.d folders may need to be created as well.<br />
<br />
vi /home/<user>/mysql/conf.d/mysql.cnf<br />
<br />
<pre><br />
[client]<br />
default-character-set = utf8mb4<br />
[mysql]<br />
default-character-set = utf8mb4<br />
</pre><br />
<br />
== Configuration == <br />
Get the installation and update scripts and the install.conf file from the main branch of this public repository:<br />
<br />
* https://github.com/Lingoport/CommandCenterConfig <br />
<br />
You should have files such as:<br />
<br />
install.conf<br />
BackupCommandCenterDatabase.sh<br />
InstallCommandCenter.sh<br />
UninstallCommandCenter.sh<br />
UpdateCommandCenter.sh<br />
<br />
If you need to install SSO version, the relevant files are:<br />
<br />
install.conf<br />
BackupCommandCenterDatabase.sh<br />
InstallSSOCommandCenter.sh<br />
UninstallCommandCenter.sh<br />
UpdateSSOCommandCenter.sh<br />
saml_configuration.conf<br />
<br />
Copy the above files under your home directory, ''for instance'' <code><user>/commandCenterInstall</code> where <user> may be <code>/home/centos</code> or <code>/home/ec2-user</code>.<br />
<br />
===Set up install.conf ===<br />
<br />
Unless directed otherwise, change the top part of the <code>install.conf</code> file. <br />
<br />
Set up <code>saml_configuration.conf</code> if you are going to use SAML<br />
<br />
The initial version number will be provided for the first installation. <br />
<br />
For updates, <code>command_center_image_version</code> will be the only parameter to change in the <code>install.conf</code> file. <br />
<br />
<pre><br />
# Provide the Command Center version<br />
# For *Regular* Updates, this should be the only parameter to change<br />
command_center_image_version=113<br />
<br />
Make sure to keep a copy of that file in case you overwrite it when updating from the https://github.com/Lingoport/CommandCenterConfig Git repository<br />
<br />
#<br />
# After Install, Updates should not need to change anything below<br />
# ----------------------------------------------------------------<br />
<br />
# The Server URL: '"https://yourserver/command-center"'<br />
serverURL='"https://SERVER_DNS_HERE/command-center"'<br />
<br />
# Provide the home directory, lingoport/commandcenter/Lingoport_Data<br />
# folder will be created<br />
home_directory=/home/centos<br />
<br />
# Provide the Command Center server port<br />
serverPort=8083<br />
<br />
</pre><br />
<br />
==Run InstallCommandCenter.sh==<br />
<br />
chmod +x *.sh<br />
sudo ./InstallCommandCenter.sh<br />
<br />
If you are using sso version installer, run <br />
<br />
chmod +x *.sh<br />
sudo ./InstallSSOCommandCenter.sh<br />
<br />
To check the running container status<br />
<br />
sudo docker ps<br />
<br />
=== Re-install Command Center ===<br />
<br />
If you need to re-run the '''InstallCommandCenter.sh'''h, make sure to run '''UninstallCommandCenter.sh''' first to clean your environment.<br />
* Uninstall Command Center<br />
<br />
sudo ./UninstallCommandCenter.sh<br />
<br />
* Verify that Command Center and the database is no longer in the list<br />
sudo docker ps <br />
<br />
* Remove the image to download and install again<br />
<br />
sudo docker image ls<br />
sudo docker image rm --force <command center image ID><br />
<br />
* Start the install again<br />
<br />
sudo ./InstallCommandCenter.sh<br />
<br />
<br />
Note: Docker image version is not the Command Center version, check latest docker image version at https://hub.docker.com/repository/docker/lingoport/command-center_dev/general<br />
<br />
You should see at least an MySQL and a Command Center container running.<br />
<br />
== Note: Database backup ==<br />
To backup the database, run the following script:<br />
<br />
chmod +x *.sh<br />
sudo ./BackupCommandCenterDatabase.sh<br />
<br />
The database backup sql file will be under '''$home_directory/commandcenter/backup''' folder, named '''commandcenter_backup_$current_date.sql'''<br />
<br />
Right after installation, the backup is not necessary. However, as you configure and on-board projects, you may want to set up a backup strategy.<br />
To backup the database periodically, schedule to run BackupCommandCenterDatabase.sh on a regular basis, for instance with a Cron service.<br />
<br />
== Verify Installation == <br />
Log in to the URL based on the command-center-config.sh settings, so something like:<br />
<br />
<nowiki>https://commandcenter.mycompany.io/command-center</nowiki><br />
<br />
<br />
You should now be able to install the licenses and create projects.<br />
<br />
The Command Center will initially have one Administrator user '''CCAdmin''' with the password '''please.reset.me'''.<br />
<br />
If the installation is unsuccessful for any reason, do not try to re-install. Instead, uninstall, make any needed changes, and re-install to avoid conflicts. <br />
<br />
sudo ./UninstallCommandCenter.sh<br />
<br />
= Command Center Update =<br />
<br />
== Get latest scripts ==<br />
Make sure to make a copy of the '''install.conf''' file used previously in case it's overwritten by the git pull / git clone below.<br />
<br />
Make sure to update the installation and update scripts and the install.conf file from the main branch of this public repository:<br />
* https://github.com/Lingoport/CommandCenterConfig<br />
<br />
Note: You may need to <code>chmod -x</code> the scripts under DockerScripts before git pull.<br />
<br />
== Backup the database ==<br />
You don't have to backup the current version of the database before proceeding to the update to the new version of the system, because the Update script will backup your current database automatically before updating. If you want to do the backup manually, you can use the BackupCommandCenterDatabase.sh script<br />
<br />
chmod +x *.sh<br />
sudo ./BackupCommandCenterDatabase.sh<br />
<br />
The database backup sql file will be under $home_directory/commandcenter/backup folder, named commandcenter_backup_$current_date.sql<br />
<br />
To backup the database periodically, schedule to run <code>BackupCommandCenterDatabase.sh</code>, for instance with cron services.<br />
<br />
=== Note: Restoring the database ===<br />
<br />
If later, at some point, the database needs to be restored, the following shows how to do so:<br />
<br />
chmod +x *.sh<br />
sudo ./RestoreCommandCenterDatabase.sh YYYY-MM-DD<br />
<br />
Check your database backup sql file under '''$home_directory/commandcenter/backup''' folder, they are named '''commandcenter_backup_$current_date.s'''ql, for example, if you backup the database on 2023 September 20th, you will see a commandcenter_backup_2023-09-20.sql file, and you can use below command to restore it<br />
<br />
sudo ./RestoreCommandCenterDatabase.sh 2023-09-20<br />
<br />
== Return to the previous version ==<br />
<br />
1. Stop the current active Command Center container<br />
<br />
You can use "docker ps" to see all active containers, and use "docker stop CONTAINER ID" to stop your current Command Center container<br />
<br />
2. Restart your previous Command Center server version<br />
<br />
You can use "docker ps -a" to see all exited containers, and use "docker start CONTAINER ID" to restart your previous version Command Center container<br />
<br />
3. Restore the database to match your previous Command Center server version<br />
<br />
sudo ./RestoreCommandCenterDatabase.sh YYYY-MM-DD<br />
<br />
==Edit install.conf ==<br />
<br />
Change the ''version number'' in the install.conf to get the Command Center image update version.<br />
<br />
command_center_image_version=<new version number><br />
<br />
See full [[Command_Center_Installation#Configuration | Configuration ]] above.<br />
<br />
=== Moving from a non SSO to an SSO configuration ===<br />
<br />
If you need to update your Command Center from non SSO version to SSO version, you need to have samlpath set up in install.conf file, and idp.xml, sp.xml, saml_configuration.conf and saml-keystore.jks file must be in this directory<br />
<br />
# Provide your saml directory, idp.xml, sp.xml, saml_configuration.conf and saml-keystore.jks file must be in this directory<br />
samlpath=<br />
<br />
See: [[Command Center SSO Installation]]<br />
<br />
==Run UpdateCommandCenter.sh==<br />
<br />
chmod +x UpdateCommandCenter.sh<br />
sudo ./UpdateCommandCenter.sh<br />
<br />
If you are using SSO version installer, run UpdateSSOCommandCenter.sh instead of UpdateCommandCenter.sh<br />
<br />
If you are updating CommandCenter from non SSO version to SSO version, only run SwitchToSSOCommandCenter.sh <br />
<br />
If you are updating CommandCenter from SSO version to non-SSO version, only run SwitchToNonSSOCommandCenter.sh <br />
<br />
<br />
To check the running container status<br />
<br />
sudo docker ps<br />
<br />
The database backup sql file is in $home_directory/commandcenter/ folder, named commandcenter_backup_$current_date.sql<br />
<br />
= Start and Stop System =<br />
* From Command Center, as an administrator, go to settings and click 'Restart'<br />
* From the VM, use docker commands to stop or start Command Center. For example:<br />
<br />
sudo docker ps<br />
sudo docker stop <hash><br />
sudo docker ps<br />
<br />
sudo docker container ls -a | grep command<br />
sudo docker start <hash><br />
sudo docker ps<br />
<br />
<br />
= Uninstall =<br />
<br />
sudo ./UninstallCommandCenter.sh<br />
Uninstalling the Command Center Servers ...<br />
<br />
sudo docker ps<br />
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES<br />
<br />
= FAQ and Troubleshooting =<br />
<br />
== Make sure the Server URL is reachable ==<br />
Navigate to the server URL set up in <code>install.conf</code>: is the login screen available?<br />
<br />
If it is not, first check that the docker container is up and running. Make sure both <code>lingoport/command-center</code> and <code>mysql</code> are running.<br />
<br />
sudo docker container ls -a <br />
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES<br />
3d9da7a80e0a '''lingoport/command-center''':80 "catalina.sh run" 3 days ago Up 6 hours 0.0.0.0:8081->8080/tcp, :::8081->8080/tcp pedantic_aryabhata<br />
683c55907c06 '''mysql''':8.0 "docker-entrypoint.s…" 3 days ago Up 6 hours 3306/tcp, 33060/tcp quizzical_newton<br />
<br />
Check with IT that the DNS for that system is correct.<br />
<br />
Check with IT that the firewall allows for reaching the URL from your system.<br />
<br />
Ask IT to check the https and the server URL / DNS.<br />
<br />
== To check files on disk ==<br />
To troubleshoot, it may be necessary to check files handled by Docker, such as looking for reports under Lingoport_Data. In that case, first use the Docker PS command to get the container ID of the Command Center application.<br />
<br />
sudo docker container ls -a <br />
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES<br />
'''3d9da7a80e0a''' '''lingoport/command-center''':80 "catalina.sh run" 3 days ago Up 6 hours 0.0.0.0:8081->8080/tcp, :::8081->8080/tcp pedantic_aryabhata<br />
<br />
With the container ID, execute the following command to run bash with access to those files:<br />
<br />
sudo docker exec -it '''3d9da7a80e0a''' bash<br />
<br />
<br />
== How to backup and restore a system ==<br />
<br />
If you have a system that you want to install a new version of Command Center, but keep the current configuration, here are the steps to do that. <br />
<br />
*'''Backup the Command Center databases'''<br />
<br />
sudo ./BackupCommandCenterDatabase.sh <br />
<br />
This will create two files <code><home>/commandcenter/backup/commandcenter_backup_YYYY-MM-DD.sql</code> and <code><home>/commandcenter/backup/LRM_backup_YYYY-MM-DD.sql</code> Where YYYY-MM-DD is the current date.<br />
<br />
*'''Stop the currently running Command Center container and its associated MySQL container'''<br />
<br />
sudo docker ps<br />
sudo docker stop <Command Center Container ID> <MySQL Container ID><br />
sudo docker ps<br />
<br />
*'''Modify the install.conf file for the correct version of Command Center to install'''<br />
<br />
*'''Install Command Center'''<br />
<br />
sudo ./InstallCommandCenter.sh<br />
<br />
If there is an error about the container in use, remove the container that is identified and attempt the install again. <br />
<br />
sudo docker rm <container><br />
sudo ./InstallCommandCenter.sh<br />
<br />
*'''Verify that Command Center comes up in the browser. Login with the CCAdmin user. There should be no projects or configuration set up'''<br />
<br />
*'''Restore from the database'''<br />
<br />
sudo ./RestoreCommandCenterDatabase.sh YYYY-MM-DD<br />
<br />
*'''Verify that Command Center is populated with the correct information'''<br />
<br />
= Next Steps =<br />
Command Center is now ready to be used. Proceed to the URL configured in the installation and follow the [[Command_Center_User_Guide | User's Guide's]] steps.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=HTTP2_Configuration&diff=99221HTTP2 Configuration2025-04-17T12:50:01Z<p>Rwilliams: </p>
<hr />
<div>HTTP/2 enablement can be achieved via a reverse proxy hosted on the Linux system. The below instructions assume that the prior configuration instructions for HTTPS have already been carried out. These instructions will add HTTP2 support to that existing configuration. It is assumed that this will be on Apache in a CentOS / RHEL environment:<br />
<br />
1. Edit the Apache SSL Configuration file, and example is shown below<br />
<pre><br />
vi /etc/httpd/conf.d/lingoport-apps-ssl.conf<br />
</pre><br />
<br />
2. Locate the section that the VirtualHost Directive is defined for SSL and add the six lines from <IfModule> to </IFModule> inclusive as shown below. This searches for the http2_module and it if exists will attempt to use HTTP2. If that fails for some reason it will fallback to HTTP1.1. If the http2_module doesn't exist, it will only attempt to use HTTP/1.1<br />
<br />
<pre><br />
<IfModule mod_ssl.c><br />
<VirtualHost *:443><br />
ServerName SERVER_URL_REPLACE_ME # example: myserver.lingoport.io<br />
<br />
<IfModule http2_module><br />
Protocols h2 http/1.1<br />
</IfModule><br />
<IfModule !http2_module><br />
Protocols http/1.1<br />
</IfModule><br />
<br />
AllowEncodedSlashes NoDecode<br />
ProxyPreserveHost On<br />
ProxyRequests Off<br />
<br />
...<br />
</VirtualHost><br />
</IfModule><br />
</pre><br />
<br />
3. Restart Apache to apply the settings<br />
<pre><br />
sudo systemctl restart httpd<br />
</pre><br />
<br />
4 Validation<br />
<br />
One method to confirm that http2 is supported after restarting Apache is via curl. Simply run a curl command on the command-center site and the returned result will be the version of HTTP supported. A 2 indicates that that HTTP/2 is supported and the configuration was successful. If the return was a 1.1, then only version HTTP/1.1 support is provided. <br />
<pre><br />
$ curl -sI https://<FQDN>/command-center -o/dev/null -w '%{http_version}\n'<br />
2<br />
</pre><br />
<br />
<br />
To continue on Command Center installation, please go to:<br />
* [[Command Center Installation | Command Center Installation ]]</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=HTTP2_Configuration&diff=99220HTTP2 Configuration2025-04-17T12:44:21Z<p>Rwilliams: Created page with "HTTP2 enablement can be achieved via a reverse proxy hosted on the Linux system. The below instructions assume that the prior configuration instructions for HTTPS have already..."</p>
<hr />
<div>HTTP2 enablement can be achieved via a reverse proxy hosted on the Linux system. The below instructions assume that the prior configuration instructions for HTTPS have already been carried out. These instructions will add HTTP2 support to that existing configuration. It is assumed that this will be on Apache in a CentOS / RHEL environment:<br />
<br />
1. Edit the Apache SSL Configuration file, and example is shown below<br />
<pre><br />
vi /etc/httpd/conf.d/lingoport-apps-ssl.conf<br />
</pre><br />
<br />
2. Locate the section that the VirtualHost Directive is defined.<br />
<pre><br />
<IfModule mod_ssl.c><br />
<VirtualHost *:443><br />
ServerName SERVER_URL_REPLACE_ME # example: myserver.lingoport.io<br />
<br />
<IfModule http2_module><br />
Protocols h2 http/1.1<br />
</IfModule><br />
<IfModule !http2_module><br />
Protocols http/1.1<br />
</IfModule><br />
<br />
AllowEncodedSlashes NoDecode<br />
ProxyPreserveHost On<br />
ProxyRequests Off<br />
<br />
...<br />
</VirtualHost><br />
</IfModule><br />
</pre><br />
<br />
3. Restart Apache to apply the settings<br />
<pre><br />
sudo systemctl restart httpd<br />
</pre><br />
<br />
4 Validation<br />
<br />
One method to confirm that http2 is supported after restarting Apache is via curl. Simply run a curl command on the command-center site and the returned result will be the version of HTTP supported. A 2 indicates that that HTTP/2 is supported and the configuration was successful. If the return was a 1.1, then only version HTTP/1.1 support is provided. <br />
<pre><br />
$ curl -sI https://<FQDN>/command-center -o/dev/null -w '%{http_version}\n'<br />
2<br />
</pre><br />
<br />
<br />
To continue on Command Center installation, please go to:<br />
* [[Command Center Installation | Command Center Installation ]]</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Command_Center_SSH_Bitbucket&diff=99195Command Center SSH Bitbucket2025-02-07T20:36:42Z<p>Rwilliams: /* Additional Notes */</p>
<hr />
<div>= Connecting Command Center to Bitbucket using SSH =<br />
<br />
== Background ==<br />
Its possible to connect Command Center to Bitbucket without using HTTPS, but instead using Bitbucket. This type of connection is not possible via the standard Bitbucket Connector in the UI as that only supports HTTPS connections. Follow this procedure to leverage an SSH connection to Bitbucket.<br />
<br />
== Process Overview ==<br />
* Creation of a GitHub repo for storing three custom scripts (Using GitHub as example for this)<br />
* Creation of a pub/private key in the Command Center Container<br />
* Adding the public key to Bitbucket Cloud Repository<br />
* Adding three custom scripts to the GitHub Repo<br />
* Creating a Custom Data Source in Command Center to access the three scripts<br />
* Leveraging the Custom Data Source from the desired Command Center Project<br />
<br />
=== Additional Notes ===<br />
Although this page details the process for Bitbucket, the same technique can be applied to other repositories such as GitLab as well. The overall process would be the same.<br />
<br />
== GitHub Repository Initial Setup ==<br />
Create a new repository in GitHub that will be used for storing the three custom scripts.<br />
* Create top level directory for storing the scripts<br />
* This directory will contain the following three scripts as described later in the document.<br />
** clone.sh<br />
** pull.sh<br />
** pushfiles.sh<br />
<br />
== Bitbucket Cloud Repository Configuration ==<br />
<br />
=== Command Center Container ===<br />
<br />
The Bitbucket repo requires a public key be added to it that is created in Command Center by the connecting user. Below is the process for creating the key to be shared with the Bitbucket Cloud Repo.<br />
* Perform this within the container itself for Command Center<br />
* Do not add a password to the key pair when prompted<br />
* The key will be in the tomcatuser home directory so it must be created by the tomcatuser preferably.<br />
* You will need set tomcatuser to /bin/bash shell from /usr/sbin/nologin as part of the below actions<br />
<br />
Follow the below command after logging into the VM and then logging into the Command Center container as the root user.<br />
<br />
root@d9dfe772ea55:/usr/local/tomcat# chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/sbin/nologin]: /bin/bash<br />
su - tomcatuser<br />
ssh-keygen -t rsa -b8192<br />
Generating public/private rsa key pair.<br />
Enter file in which to save the key (/usr/local/tomcat/.ssh/id_rsa):<br />
Creating directory /usr/local/tomcat/.ssh<br />
Enter passphrase (empty for no passphrase):<br />
Enter same passphrase again:<br />
Your identification has been saved in /usr/local/tomcat/.ssh/id_rsa<br />
Your public key has been saved in /usr/local/tomcat/.ssh/id_rsa.pub<br />
The key fingerprint is:<br />
SHA256:NwG7DJtfwj8FsXc6CWnkdzBrivXrs3rn4jkRDdUq5cc tomcatuser@d9dfe772ea55<br />
The key's randomart image is:<br />
+---[RSA 8192]----+<br />
| . o o... |<br />
| = +.+. .|<br />
| . . X ==oo |<br />
| * = Xo=+ E|<br />
| o S = *o . |<br />
| . = o.o |<br />
| . o .. |<br />
| o=.. |<br />
| .+=B. |<br />
+----[SHA256]-----+<br />
<br />
Copy the public key that was created as it will need to be input into the Bitbucket Cloud Repo for the account that is being leveraged in Bitbucket. Note this key is applied at the user level and not the repository level.<br />
<br />
=== Bitbucket Cloud Repo ===<br />
<br />
Log into the Bitbucket Cloud Server as user as the user the key will be applied. The SSH Key must be added to an account which has write access to the repo.<br />
* Click on Settings Icon to left of the User Icon<br />
* Select SSH Keys in the left column<br />
* Click on Add Key<br />
* Provide a label as appropriate<br />
* Paste the public key (Be sure it's the public key!)<br />
** In this example it is id_rsa.pub<br />
* Select Add key and the key should be listed as available<br />
** Confirm the key has r/w access to the repo as noted in the next section<br />
<br />
=== Command Center Container ===<br />
<br />
Return to the Command Center Container to perform a connection test to the desired repository. You should still be tomcatuser at this point. If not, switch to tomcatuser as before. Perform the below activities and then be sure to switch the tomcatuser shell back to nologin.<br />
<br />
cd /tmp/<br />
git clone git@bitbucket.org:<username>/<repo>.git<br />
This key is not known by any other names<br />
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes<br />
Warning: Permanently added 'bitbucket.org' (ED25519) to the list of known hosts.<br />
exit (returns you to root user)<br />
chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/bin/bash]: /usr/sbin/nologin<br />
<br />
At this point the key has been validated in Bitbucket as working.<br />
<br />
<B>NOTE:</B> At this point you have a working SSH key for Bitbucket. It's important to realize that since this is in a container it will disappear upon reinstall/upgrade of Command Center. Making a backup of the .ssh directory in the container and having it available offline for the future can help to reduce the effort of recreating this process when this occurs<br />
<br />
== Script Additions to GitHub Repository ==<br />
Add the custom scripts listed below to the repository directory in GitHub that previously created. Be sure to update the scripts with your custom information as the scripts will not work as written, the details are required.<br />
* clone.sh<br />
** Requires the following to be updated<br />
*** REPO - Obtain this path from the repository itself, there is normally a link that can be clicked to copy the path<br />
*** BRANCH_NAME<br />
* pull.sh<br />
** Requires the following to be updated<br />
*** BRANCH_NAME<br />
* pushfiles.sh<br />
** No modifications are required in this script.<br />
<br />
=== clone.sh ===<br />
<br />
**Be sure to supply the USER_NAME, REPO, BRANCH where indicated**<br />
<br />
#!/bin/bash<br />
<br />
REPO="ssh://git@bitbucket.org/<REPO>.git"<br />
BRANCH="<BRANCH_NAME>"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "Custom Clone Incoming variables:"<br />
echo ""<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " WORKSPACES_DIR = ${WORKSPACES_DIR}"<br />
echo " WORKSPACE_NAME = ${WORKSPACE_NAME}"<br />
echo " REPO = ${REPO}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git clone is $(whoami)"<br />
<br />
# For Debugging<br />
GIT_SSH_COMMAND="ssh" git clone "$REPO" "$WORKSPACES_DIR/$WORKSPACE_NAME"<br />
ret=$?<br />
echo "Clone return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
===pull.sh===<br />
<br />
**Be sure to supply the branch where indicated**<br />
<br />
#!/bin/bash<br />
<br />
BRANCH="<BRANCH_NAME>"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
echo "=================================================================="<br />
echo ""<br />
echo "Custom Pull Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git pull is $(whoami)"<br />
<br />
# For Debugging<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
GIT_SSH_COMMAND="ssh" git --git-dir="$CLIENT_SOURCE_DIR/.git" --work-tree="$CLIENT_SOURCE_DIR" pull<br />
ret=$?<br />
echo "Pull return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
=== pushfiles.sh ===<br />
<br />
#!/bin/bash<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "CUSTOM_PUSH_FILES (${PUSH_TYPE})"<br />
echo ""<br />
echo "Custom Push Files Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " IMPORT_MESSAGE = ${IMPORT_MESSAGE}"<br />
echo " IMPORT_LIST_PATH = ${IMPORT_LIST_PATH}"<br />
<br />
echo "User running pushfiles is $(whoami)"<br />
<br />
# run script<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
echo "Files to import to the repo are: "<br />
cat "${IMPORT_LIST_PATH}"<br />
while IFS= read -r f; do<br />
git add "$f"<br />
ret=$?<br />
echo "Push add status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
done < "${IMPORT_LIST_PATH}"<br />
git commit -m "${IMPORT_MESSAGE}"<br />
GIT_SSH_COMMAND="ssh" git push <br />
ret2=$?<br />
echo "Push return status $ret2"<br />
if [ $ret2 -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
<br />
== Create a new Custom Data Source ==<br />
Once the scripts have been created and placed into the GitHub repository, make the scripts accessible to Command Center by adding the directory as a new Custom Data Source<br />
* When naming the Custom Data Source consider using a name that will make it easily identifiable as to what repository and branch the Custom Data Source is pointing towards.<br />
* There will be one Custom Data source created for a single repo/branch used by Command Center<br />
** If two branches from the same repository are required, there will be two Custom Data Sources Required.<br />
<br />
== Leveraging the Custom Data Source from Command Center ==<br />
<br />
At this point, when the Command Center Project is created, simply select the Custom Data Source as the Data Source Credential. Once the project is created, it should leverage the scripts to perform any operations required on the Bitbucket repo. Initially it should show the list of resource files that are found when running validation. That is a good check for the clone.sh and pull.sh scripts. The pushfiles.sh is used when committing files back into the repository so that could take the form of a returned translation, or even a pseudo-localization file.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Command_Center_SSH_Bitbucket&diff=99194Command Center SSH Bitbucket2025-02-07T20:35:50Z<p>Rwilliams: /* Process Overview */</p>
<hr />
<div>= Connecting Command Center to Bitbucket using SSH =<br />
<br />
== Background ==<br />
Its possible to connect Command Center to Bitbucket without using HTTPS, but instead using Bitbucket. This type of connection is not possible via the standard Bitbucket Connector in the UI as that only supports HTTPS connections. Follow this procedure to leverage an SSH connection to Bitbucket.<br />
<br />
== Process Overview ==<br />
* Creation of a GitHub repo for storing three custom scripts (Using GitHub as example for this)<br />
* Creation of a pub/private key in the Command Center Container<br />
* Adding the public key to Bitbucket Cloud Repository<br />
* Adding three custom scripts to the GitHub Repo<br />
* Creating a Custom Data Source in Command Center to access the three scripts<br />
* Leveraging the Custom Data Source from the desired Command Center Project<br />
<br />
=== Additional Notes ===<br />
Although this page details the process for Bitbucket, the same technique can be applied to GitLab as well. The overall process would be the same.<br />
<br />
== GitHub Repository Initial Setup ==<br />
Create a new repository in GitHub that will be used for storing the three custom scripts.<br />
* Create top level directory for storing the scripts<br />
* This directory will contain the following three scripts as described later in the document.<br />
** clone.sh<br />
** pull.sh<br />
** pushfiles.sh<br />
<br />
== Bitbucket Cloud Repository Configuration ==<br />
<br />
=== Command Center Container ===<br />
<br />
The Bitbucket repo requires a public key be added to it that is created in Command Center by the connecting user. Below is the process for creating the key to be shared with the Bitbucket Cloud Repo.<br />
* Perform this within the container itself for Command Center<br />
* Do not add a password to the key pair when prompted<br />
* The key will be in the tomcatuser home directory so it must be created by the tomcatuser preferably.<br />
* You will need set tomcatuser to /bin/bash shell from /usr/sbin/nologin as part of the below actions<br />
<br />
Follow the below command after logging into the VM and then logging into the Command Center container as the root user.<br />
<br />
root@d9dfe772ea55:/usr/local/tomcat# chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/sbin/nologin]: /bin/bash<br />
su - tomcatuser<br />
ssh-keygen -t rsa -b8192<br />
Generating public/private rsa key pair.<br />
Enter file in which to save the key (/usr/local/tomcat/.ssh/id_rsa):<br />
Creating directory /usr/local/tomcat/.ssh<br />
Enter passphrase (empty for no passphrase):<br />
Enter same passphrase again:<br />
Your identification has been saved in /usr/local/tomcat/.ssh/id_rsa<br />
Your public key has been saved in /usr/local/tomcat/.ssh/id_rsa.pub<br />
The key fingerprint is:<br />
SHA256:NwG7DJtfwj8FsXc6CWnkdzBrivXrs3rn4jkRDdUq5cc tomcatuser@d9dfe772ea55<br />
The key's randomart image is:<br />
+---[RSA 8192]----+<br />
| . o o... |<br />
| = +.+. .|<br />
| . . X ==oo |<br />
| * = Xo=+ E|<br />
| o S = *o . |<br />
| . = o.o |<br />
| . o .. |<br />
| o=.. |<br />
| .+=B. |<br />
+----[SHA256]-----+<br />
<br />
Copy the public key that was created as it will need to be input into the Bitbucket Cloud Repo for the account that is being leveraged in Bitbucket. Note this key is applied at the user level and not the repository level.<br />
<br />
=== Bitbucket Cloud Repo ===<br />
<br />
Log into the Bitbucket Cloud Server as user as the user the key will be applied. The SSH Key must be added to an account which has write access to the repo.<br />
* Click on Settings Icon to left of the User Icon<br />
* Select SSH Keys in the left column<br />
* Click on Add Key<br />
* Provide a label as appropriate<br />
* Paste the public key (Be sure it's the public key!)<br />
** In this example it is id_rsa.pub<br />
* Select Add key and the key should be listed as available<br />
** Confirm the key has r/w access to the repo as noted in the next section<br />
<br />
=== Command Center Container ===<br />
<br />
Return to the Command Center Container to perform a connection test to the desired repository. You should still be tomcatuser at this point. If not, switch to tomcatuser as before. Perform the below activities and then be sure to switch the tomcatuser shell back to nologin.<br />
<br />
cd /tmp/<br />
git clone git@bitbucket.org:<username>/<repo>.git<br />
This key is not known by any other names<br />
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes<br />
Warning: Permanently added 'bitbucket.org' (ED25519) to the list of known hosts.<br />
exit (returns you to root user)<br />
chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/bin/bash]: /usr/sbin/nologin<br />
<br />
At this point the key has been validated in Bitbucket as working.<br />
<br />
<B>NOTE:</B> At this point you have a working SSH key for Bitbucket. It's important to realize that since this is in a container it will disappear upon reinstall/upgrade of Command Center. Making a backup of the .ssh directory in the container and having it available offline for the future can help to reduce the effort of recreating this process when this occurs<br />
<br />
== Script Additions to GitHub Repository ==<br />
Add the custom scripts listed below to the repository directory in GitHub that previously created. Be sure to update the scripts with your custom information as the scripts will not work as written, the details are required.<br />
* clone.sh<br />
** Requires the following to be updated<br />
*** REPO - Obtain this path from the repository itself, there is normally a link that can be clicked to copy the path<br />
*** BRANCH_NAME<br />
* pull.sh<br />
** Requires the following to be updated<br />
*** BRANCH_NAME<br />
* pushfiles.sh<br />
** No modifications are required in this script.<br />
<br />
=== clone.sh ===<br />
<br />
**Be sure to supply the USER_NAME, REPO, BRANCH where indicated**<br />
<br />
#!/bin/bash<br />
<br />
REPO="ssh://git@bitbucket.org/<REPO>.git"<br />
BRANCH="<BRANCH_NAME>"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "Custom Clone Incoming variables:"<br />
echo ""<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " WORKSPACES_DIR = ${WORKSPACES_DIR}"<br />
echo " WORKSPACE_NAME = ${WORKSPACE_NAME}"<br />
echo " REPO = ${REPO}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git clone is $(whoami)"<br />
<br />
# For Debugging<br />
GIT_SSH_COMMAND="ssh" git clone "$REPO" "$WORKSPACES_DIR/$WORKSPACE_NAME"<br />
ret=$?<br />
echo "Clone return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
===pull.sh===<br />
<br />
**Be sure to supply the branch where indicated**<br />
<br />
#!/bin/bash<br />
<br />
BRANCH="<BRANCH_NAME>"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
echo "=================================================================="<br />
echo ""<br />
echo "Custom Pull Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git pull is $(whoami)"<br />
<br />
# For Debugging<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
GIT_SSH_COMMAND="ssh" git --git-dir="$CLIENT_SOURCE_DIR/.git" --work-tree="$CLIENT_SOURCE_DIR" pull<br />
ret=$?<br />
echo "Pull return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
=== pushfiles.sh ===<br />
<br />
#!/bin/bash<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "CUSTOM_PUSH_FILES (${PUSH_TYPE})"<br />
echo ""<br />
echo "Custom Push Files Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " IMPORT_MESSAGE = ${IMPORT_MESSAGE}"<br />
echo " IMPORT_LIST_PATH = ${IMPORT_LIST_PATH}"<br />
<br />
echo "User running pushfiles is $(whoami)"<br />
<br />
# run script<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
echo "Files to import to the repo are: "<br />
cat "${IMPORT_LIST_PATH}"<br />
while IFS= read -r f; do<br />
git add "$f"<br />
ret=$?<br />
echo "Push add status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
done < "${IMPORT_LIST_PATH}"<br />
git commit -m "${IMPORT_MESSAGE}"<br />
GIT_SSH_COMMAND="ssh" git push <br />
ret2=$?<br />
echo "Push return status $ret2"<br />
if [ $ret2 -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
<br />
== Create a new Custom Data Source ==<br />
Once the scripts have been created and placed into the GitHub repository, make the scripts accessible to Command Center by adding the directory as a new Custom Data Source<br />
* When naming the Custom Data Source consider using a name that will make it easily identifiable as to what repository and branch the Custom Data Source is pointing towards.<br />
* There will be one Custom Data source created for a single repo/branch used by Command Center<br />
** If two branches from the same repository are required, there will be two Custom Data Sources Required.<br />
<br />
== Leveraging the Custom Data Source from Command Center ==<br />
<br />
At this point, when the Command Center Project is created, simply select the Custom Data Source as the Data Source Credential. Once the project is created, it should leverage the scripts to perform any operations required on the Bitbucket repo. Initially it should show the list of resource files that are found when running validation. That is a good check for the clone.sh and pull.sh scripts. The pushfiles.sh is used when committing files back into the repository so that could take the form of a returned translation, or even a pseudo-localization file.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Command_Center_SSH_Bitbucket&diff=99193Command Center SSH Bitbucket2025-02-07T20:33:40Z<p>Rwilliams: /* Connecting Command Center to Bitbucket using SSH */</p>
<hr />
<div>= Connecting Command Center to Bitbucket using SSH =<br />
<br />
== Background ==<br />
Its possible to connect Command Center to Bitbucket without using HTTPS, but instead using Bitbucket. This type of connection is not possible via the standard Bitbucket Connector in the UI as that only supports HTTPS connections. Follow this procedure to leverage an SSH connection to Bitbucket.<br />
<br />
== Process Overview ==<br />
* Creation of a GitHub repo for storing three custom scripts (Using GitHub as example for this)<br />
* Creation of a pub/private key in the Command Center Container<br />
* Adding the public key to Bitbucket Cloud Repository<br />
* Adding three custom scripts to the GitHub Repo<br />
* Creating a Custom Data Source in Command Center to access the three scripts<br />
* Leveraging the Custom Data Source from the desired Command Center Project<br />
<br />
== GitHub Repository Initial Setup ==<br />
Create a new repository in GitHub that will be used for storing the three custom scripts.<br />
* Create top level directory for storing the scripts<br />
* This directory will contain the following three scripts as described later in the document.<br />
** clone.sh<br />
** pull.sh<br />
** pushfiles.sh<br />
<br />
== Bitbucket Cloud Repository Configuration ==<br />
<br />
=== Command Center Container ===<br />
<br />
The Bitbucket repo requires a public key be added to it that is created in Command Center by the connecting user. Below is the process for creating the key to be shared with the Bitbucket Cloud Repo.<br />
* Perform this within the container itself for Command Center<br />
* Do not add a password to the key pair when prompted<br />
* The key will be in the tomcatuser home directory so it must be created by the tomcatuser preferably.<br />
* You will need set tomcatuser to /bin/bash shell from /usr/sbin/nologin as part of the below actions<br />
<br />
Follow the below command after logging into the VM and then logging into the Command Center container as the root user.<br />
<br />
root@d9dfe772ea55:/usr/local/tomcat# chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/sbin/nologin]: /bin/bash<br />
su - tomcatuser<br />
ssh-keygen -t rsa -b8192<br />
Generating public/private rsa key pair.<br />
Enter file in which to save the key (/usr/local/tomcat/.ssh/id_rsa):<br />
Creating directory /usr/local/tomcat/.ssh<br />
Enter passphrase (empty for no passphrase):<br />
Enter same passphrase again:<br />
Your identification has been saved in /usr/local/tomcat/.ssh/id_rsa<br />
Your public key has been saved in /usr/local/tomcat/.ssh/id_rsa.pub<br />
The key fingerprint is:<br />
SHA256:NwG7DJtfwj8FsXc6CWnkdzBrivXrs3rn4jkRDdUq5cc tomcatuser@d9dfe772ea55<br />
The key's randomart image is:<br />
+---[RSA 8192]----+<br />
| . o o... |<br />
| = +.+. .|<br />
| . . X ==oo |<br />
| * = Xo=+ E|<br />
| o S = *o . |<br />
| . = o.o |<br />
| . o .. |<br />
| o=.. |<br />
| .+=B. |<br />
+----[SHA256]-----+<br />
<br />
Copy the public key that was created as it will need to be input into the Bitbucket Cloud Repo for the account that is being leveraged in Bitbucket. Note this key is applied at the user level and not the repository level.<br />
<br />
=== Bitbucket Cloud Repo ===<br />
<br />
Log into the Bitbucket Cloud Server as user as the user the key will be applied. The SSH Key must be added to an account which has write access to the repo.<br />
* Click on Settings Icon to left of the User Icon<br />
* Select SSH Keys in the left column<br />
* Click on Add Key<br />
* Provide a label as appropriate<br />
* Paste the public key (Be sure it's the public key!)<br />
** In this example it is id_rsa.pub<br />
* Select Add key and the key should be listed as available<br />
** Confirm the key has r/w access to the repo as noted in the next section<br />
<br />
=== Command Center Container ===<br />
<br />
Return to the Command Center Container to perform a connection test to the desired repository. You should still be tomcatuser at this point. If not, switch to tomcatuser as before. Perform the below activities and then be sure to switch the tomcatuser shell back to nologin.<br />
<br />
cd /tmp/<br />
git clone git@bitbucket.org:<username>/<repo>.git<br />
This key is not known by any other names<br />
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes<br />
Warning: Permanently added 'bitbucket.org' (ED25519) to the list of known hosts.<br />
exit (returns you to root user)<br />
chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/bin/bash]: /usr/sbin/nologin<br />
<br />
At this point the key has been validated in Bitbucket as working.<br />
<br />
<B>NOTE:</B> At this point you have a working SSH key for Bitbucket. It's important to realize that since this is in a container it will disappear upon reinstall/upgrade of Command Center. Making a backup of the .ssh directory in the container and having it available offline for the future can help to reduce the effort of recreating this process when this occurs<br />
<br />
== Script Additions to GitHub Repository ==<br />
Add the custom scripts listed below to the repository directory in GitHub that previously created. Be sure to update the scripts with your custom information as the scripts will not work as written, the details are required.<br />
* clone.sh<br />
** Requires the following to be updated<br />
*** REPO - Obtain this path from the repository itself, there is normally a link that can be clicked to copy the path<br />
*** BRANCH_NAME<br />
* pull.sh<br />
** Requires the following to be updated<br />
*** BRANCH_NAME<br />
* pushfiles.sh<br />
** No modifications are required in this script.<br />
<br />
=== clone.sh ===<br />
<br />
**Be sure to supply the USER_NAME, REPO, BRANCH where indicated**<br />
<br />
#!/bin/bash<br />
<br />
REPO="ssh://git@bitbucket.org/<REPO>.git"<br />
BRANCH="<BRANCH_NAME>"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "Custom Clone Incoming variables:"<br />
echo ""<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " WORKSPACES_DIR = ${WORKSPACES_DIR}"<br />
echo " WORKSPACE_NAME = ${WORKSPACE_NAME}"<br />
echo " REPO = ${REPO}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git clone is $(whoami)"<br />
<br />
# For Debugging<br />
GIT_SSH_COMMAND="ssh" git clone "$REPO" "$WORKSPACES_DIR/$WORKSPACE_NAME"<br />
ret=$?<br />
echo "Clone return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
===pull.sh===<br />
<br />
**Be sure to supply the branch where indicated**<br />
<br />
#!/bin/bash<br />
<br />
BRANCH="<BRANCH_NAME>"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
echo "=================================================================="<br />
echo ""<br />
echo "Custom Pull Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git pull is $(whoami)"<br />
<br />
# For Debugging<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
GIT_SSH_COMMAND="ssh" git --git-dir="$CLIENT_SOURCE_DIR/.git" --work-tree="$CLIENT_SOURCE_DIR" pull<br />
ret=$?<br />
echo "Pull return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
=== pushfiles.sh ===<br />
<br />
#!/bin/bash<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "CUSTOM_PUSH_FILES (${PUSH_TYPE})"<br />
echo ""<br />
echo "Custom Push Files Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " IMPORT_MESSAGE = ${IMPORT_MESSAGE}"<br />
echo " IMPORT_LIST_PATH = ${IMPORT_LIST_PATH}"<br />
<br />
echo "User running pushfiles is $(whoami)"<br />
<br />
# run script<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
echo "Files to import to the repo are: "<br />
cat "${IMPORT_LIST_PATH}"<br />
while IFS= read -r f; do<br />
git add "$f"<br />
ret=$?<br />
echo "Push add status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
done < "${IMPORT_LIST_PATH}"<br />
git commit -m "${IMPORT_MESSAGE}"<br />
GIT_SSH_COMMAND="ssh" git push <br />
ret2=$?<br />
echo "Push return status $ret2"<br />
if [ $ret2 -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
<br />
== Create a new Custom Data Source ==<br />
Once the scripts have been created and placed into the GitHub repository, make the scripts accessible to Command Center by adding the directory as a new Custom Data Source<br />
* When naming the Custom Data Source consider using a name that will make it easily identifiable as to what repository and branch the Custom Data Source is pointing towards.<br />
* There will be one Custom Data source created for a single repo/branch used by Command Center<br />
** If two branches from the same repository are required, there will be two Custom Data Sources Required.<br />
<br />
== Leveraging the Custom Data Source from Command Center ==<br />
<br />
At this point, when the Command Center Project is created, simply select the Custom Data Source as the Data Source Credential. Once the project is created, it should leverage the scripts to perform any operations required on the Bitbucket repo. Initially it should show the list of resource files that are found when running validation. That is a good check for the clone.sh and pull.sh scripts. The pushfiles.sh is used when committing files back into the repository so that could take the form of a returned translation, or even a pseudo-localization file.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=System_Files&diff=99189System Files2025-02-04T18:38:53Z<p>Rwilliams: /* Custom Data Source Folder */</p>
<hr />
<div>= Introduction =<br />
<br />
System files are used to enhance and customize the behavior of the system. System files are retrieved from data sources, so that they can be versioned, so typically kept in a git repository. When a system file is updated in the data source (typically a git repository), it needs to be <code>Refreshed</code> in the System File Edit page in order for the new version to be executed. <br />
<br />
Examples of System Files can be found under:<br />
* https://github.com/Lingoport/CommandCenterConfig/tree/main<br />
<br />
System files to be executed (so, not XML Parser files or Globalyzer configuration files) will be invoked as Bash script.<br />
<br />
Once a System File is added to Command Center, it can be used via a project setting or as a debug script from Global settings.<br />
<br />
[[File:CCSystemFiles.jpg|700px|center]]<br />
<br />
<br />
[[File:ManageSystemFiles.jpg|700px|center]]<br />
<br />
== System File Types==<br />
<br />
=== Globalyzer Lite File ===<br />
<br />
The Globalyzer Lite File is the Project Definition file that identifies what ruleset will be used for the Globalyzer analysis. One file can be used by all the Globalyzer projects. The Globalyzer Lite File must be an XML file. <br />
<br />
=== Custom Script ===<br />
<br />
The Custom Script is used by Globalyzer to modify how the Globalyzer Scanning and reporting is done. The Custom Script should be a .sh file. <br />
<br />
=== Transform Folder ===<br />
<br />
The transform folder, used by Localyzer, contains scripts that modifies the resources from the repository or returning to the repository. For example, if a TMS does not support a specific extension, the transform script can create an acceptable file to send and change it back upon return. The transform folder must contain the following scripts:<br />
<br />
*transform_to_repo.sh<br />
*transform_from_repo.sh<br />
*transform_files_list.sh<br />
<br />
=== XML Parser File ===<br />
<br />
XML Localyzer resource files can be in many forms. An XML Parser file identifies the form of the XML resource file. <br />
<br />
=== Custom Data Source Folder ===<br />
<br />
Command Center provides several Data Source options. Those options may not fit a specific configuration. A custom data source can be created for an unusual configuration. The new Custom Data Source will be listed in the options when selecting the data source for a project. Like the transform folder, the custom data source folder requires the following files:<br />
<br />
*clone.sh<br />
*pull.sh<br />
*pushfiles.sh<br />
<br />
For more details on using a Custom Data Source Folder for providing and SSH repository to connect to a Bitbucket repository along with an example see [[ Command_Center_SSH_Bitbucket | Connecting to a Bitbucket Repo with SSH ]]<br />
<br />
=== Post Import Script === <br />
This script are invoked after the import of resources files. For ''example'', <br />
* https://github.com/Lingoport/CommandCenterConfig/blob/main/postimport/translated/callwebhook.sh<br />
<br />
is used to tell the <code>Translated.com</code> TMS of the success of failure of the import process. <br />
<br />
The following environment variables are available in a post import script:<br />
<br />
LRM_GROUP<br />
LRM_PROJECT<br />
KIT_VERSION<br />
LRM_LOCALE<br />
IMPORT_STATUS = "success" or "failure"<br />
<br />
Set the Post Import script on a project in the Advanced Settings configuration.<br />
<br />
=== Debug Script ===<br />
<br />
Command Center provides a way to run debug scripts to determine where things may be going wrong.<br />
<br />
= Creating System Files =<br />
<br />
Select the [[File:CreateIcon.jpg|30px]] to add a new system file.<br />
<br />
== Step 1: Select the data source==<br />
<br />
[[File:LiteDatasourcCredential.jpg|700px|center]]<br />
<br />
== Step 2: Choose the repository==<br />
<br />
[[File:LiteGitHubRepo.jpg|700px|center]]<br />
<br />
== Step 3: Choose the file type and path==<br />
<br />
[[File:SelectFileType.jpg|700px|center]]<br />
<br />
== Step 4: Name the system file ==<br />
<br />
Finally, name the file and '''Save'''. The user is returned to the System Files page. The new file will be shown in the appropriate section. Initially, it will not be associated with a project. To associate a system file with a project:<br />
<br />
# Indicate the file when creating the project<br />
# Edit the configuration to add. Projects --> <an existing project> --> Project Configuration.<br />
<br />
= Editing System Files =<br />
<br />
Only an Administrator user can add or edit System Files. A Manager can view the names of the files, but has no access. Other users cannot select the System Files card from Settings.<br />
<br />
To edit a system file, hover over its entry in '''Settings -> Manage System Files''' and select the '''Edit''' button that appears.<br />
<br />
[[File:EditSystemFile.jpg|700px|center]]<br />
<br />
* Select any of the values, modify them, and Save. If the Repository information does not exist, the system will error.<br />
* System Files can be deleted, but they cannot be associated with projects. Edit the projects and remove the references to the file. Then '''Delete'''.<br />
* '''NOTE:''' Once a system file has been edited, for example a transform, and it has been pushed into the repo, it is still necessary to press the "Refresh" button on the associated System File page in Command Center. This action will update the contents of the System File within Command Center so it can be available to all projects that are using it. Without pressing "Refresh" this update will not occur.<br />
<br />
[[Advanced_Settings|Next: Advanced Settings]]</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Command_Center_SSH_Bitbucket&diff=99188Command Center SSH Bitbucket2025-02-04T15:48:54Z<p>Rwilliams: </p>
<hr />
<div>= Connecting Command Center to Bitbucket using SSH =<br />
<br />
== Background ==<br />
Its possible to connect Command Center to Bitbucket without using HTTPS, but instead using Bitbucket. This type of connection is not possible via the standard Bitbucket Connector in the UI as that only supports HTTPS connections. Follow this procedure to leverage an SSH connection to Bitbucket.<br />
<br />
== Process Overview ==<br />
* Creation of a GitHub repo for storing three custom scripts (Using GitHub as example for this)<br />
* Creation of a pub/private key in the Command Center Container<br />
* Adding the public key to Bitbucket Cloud Repository<br />
* Adding three custom scripts to the GitHub Repo<br />
* Creating a Custom Data Source in Command Center to access the three scripts<br />
* Leveraging the Custom Data Source from the desired Command Center Project<br />
<br />
== GitHub Repository Initial Setup ==<br />
Create a new repository in GitHub that will be used for storing the three custom scripts.<br />
* Create top level directory for storing the scripts<br />
* This directory will contain the following three scripts as described later in the document.<br />
** clone.sh<br />
** pull.sh<br />
** pushfiles.sh<br />
<br />
== Bitbucket Cloud Repository Configuration ==<br />
<br />
=== Command Center Container ===<br />
<br />
The Bitbucket repo requires a public key be added to it that is created in Command Center by the connecting user. Below is the process for creating the key to be shared with the Bitbucket Cloud Repo.<br />
* Perform this within the container itself for Command Center<br />
* Do not add a password to the key pair when prompted<br />
* The key will be in the tomcatuser home directory so it must be created by the tomcatuser preferably.<br />
* You will need set tomcatuser to /bin/bash shell from /usr/sbin/nologin as part of the below actions<br />
<br />
Follow the below command after logging into the VM and then logging into the Command Center container as the root user.<br />
<br />
root@d9dfe772ea55:/usr/local/tomcat# chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/sbin/nologin]: /bin/bash<br />
su - tomcatuser<br />
ssh-keygen -t rsa -b8192<br />
Generating public/private rsa key pair.<br />
Enter file in which to save the key (/usr/local/tomcat/.ssh/id_rsa):<br />
Creating directory /usr/local/tomcat/.ssh<br />
Enter passphrase (empty for no passphrase):<br />
Enter same passphrase again:<br />
Your identification has been saved in /usr/local/tomcat/.ssh/id_rsa<br />
Your public key has been saved in /usr/local/tomcat/.ssh/id_rsa.pub<br />
The key fingerprint is:<br />
SHA256:NwG7DJtfwj8FsXc6CWnkdzBrivXrs3rn4jkRDdUq5cc tomcatuser@d9dfe772ea55<br />
The key's randomart image is:<br />
+---[RSA 8192]----+<br />
| . o o... |<br />
| = +.+. .|<br />
| . . X ==oo |<br />
| * = Xo=+ E|<br />
| o S = *o . |<br />
| . = o.o |<br />
| . o .. |<br />
| o=.. |<br />
| .+=B. |<br />
+----[SHA256]-----+<br />
<br />
Copy the public key that was created as it will need to be input into the Bitbucket Cloud Repo for the account that is being leveraged in Bitbucket. Note this key is applied at the user level and not the repository level.<br />
<br />
=== Bitbucket Cloud Repo ===<br />
<br />
Log into the Bitbucket Cloud Server as user as the user the key will be applied. The SSH Key must be added to an account which has write access to the repo.<br />
* Click on Settings Icon to left of the User Icon<br />
* Select SSH Keys in the left column<br />
* Click on Add Key<br />
* Provide a label as appropriate<br />
* Paste the public key (Be sure it's the public key!)<br />
** In this example it is id_rsa.pub<br />
* Select Add key and the key should be listed as available<br />
** Confirm the key has r/w access to the repo as noted in the next section<br />
<br />
=== Command Center Container ===<br />
<br />
Return to the Command Center Container to perform a connection test to the desired repository. You should still be tomcatuser at this point. If not, switch to tomcatuser as before. Perform the below activities and then be sure to switch the tomcatuser shell back to nologin.<br />
<br />
cd /tmp/<br />
git clone git@bitbucket.org:<username>/<repo>.git<br />
This key is not known by any other names<br />
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes<br />
Warning: Permanently added 'bitbucket.org' (ED25519) to the list of known hosts.<br />
exit (returns you to root user)<br />
chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/bin/bash]: /usr/sbin/nologin<br />
<br />
At this point the key has been validated in Bitbucket as working.<br />
<br />
<B>NOTE:</B> At this point you have a working SSH key for Bitbucket. It's important to realize that since this is in a container it will disappear upon reinstall/upgrade of Command Center. Making a backup of the .ssh directory in the container and having it available offline for the future can help to reduce the effort of recreating this process when this occurs<br />
<br />
== Script Additions to GitHub Repository ==<br />
Add the custom scripts listed below to the repository directory in GitHub that previously created. Be sure to update the scripts with your custom information as the scripts will not work as written, the details are required.<br />
* clone.sh<br />
** Requires the following to be updated<br />
*** USER_NAME<br />
*** REPO<br />
*** BRANCH_NAME<br />
* pull.sh<br />
** Requires the following to be updated<br />
*** BRANCH_NAME<br />
* pushfiles.sh<br />
** No modifications are required in this script.<br />
<br />
=== clone.sh ===<br />
<br />
**Be sure to supply the USER_NAME, REPO, BRANCH where indicated**<br />
<br />
#!/bin/bash<br />
<br />
REPO="ssh://git@bitbucket.org/<USER_NAME>/<REPO>.git"<br />
BRANCH="<BRANCH_NAME>"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "Custom Clone Incoming variables:"<br />
echo ""<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " WORKSPACES_DIR = ${WORKSPACES_DIR}"<br />
echo " WORKSPACE_NAME = ${WORKSPACE_NAME}"<br />
echo " REPO = ${REPO}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git clone is $(whoami)"<br />
<br />
# For Debugging<br />
GIT_SSH_COMMAND="ssh" git clone "$REPO" "$WORKSPACES_DIR/$WORKSPACE_NAME"<br />
ret=$?<br />
echo "Clone return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
===pull.sh===<br />
<br />
**Be sure to supply the branch where indicated**<br />
<br />
#!/bin/bash<br />
<br />
BRANCH="<BRANCH_NAME>"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
echo "=================================================================="<br />
echo ""<br />
echo "Custom Pull Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git pull is $(whoami)"<br />
<br />
# For Debugging<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
GIT_SSH_COMMAND="ssh" git --git-dir="$CLIENT_SOURCE_DIR/.git" --work-tree="$CLIENT_SOURCE_DIR" pull<br />
ret=$?<br />
echo "Pull return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
=== pushfiles.sh ===<br />
<br />
#!/bin/bash<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "CUSTOM_PUSH_FILES (${PUSH_TYPE})"<br />
echo ""<br />
echo "Custom Push Files Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " IMPORT_MESSAGE = ${IMPORT_MESSAGE}"<br />
echo " IMPORT_LIST_PATH = ${IMPORT_LIST_PATH}"<br />
<br />
echo "User running pushfiles is $(whoami)"<br />
<br />
# run script<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
echo "Files to import to the repo are: "<br />
cat "${IMPORT_LIST_PATH}"<br />
while IFS= read -r f; do<br />
git add "$f"<br />
ret=$?<br />
echo "Push add status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
done < "${IMPORT_LIST_PATH}"<br />
git commit -m "${IMPORT_MESSAGE}"<br />
GIT_SSH_COMMAND="ssh" git push <br />
ret2=$?<br />
echo "Push return status $ret2"<br />
if [ $ret2 -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
<br />
== Create a new Custom Data Source ==<br />
Once the scripts have been created and placed into the GitHub repository, make the scripts accessible to Command Center by adding the directory as a new Custom Data Source<br />
* When naming the Custom Data Source consider using a name that will make it easily identifiable as to what repository and branch the Custom Data Source is pointing towards.<br />
* There will be one Custom Data source created for a single repo/branch used by Command Center<br />
** If two branches from the same repository are required, there will be two Custom Data Sources Required.<br />
<br />
== Leveraging the Custom Data Source from Command Center ==<br />
<br />
At this point, when the Command Center Project is created, simply select the Custom Data Source as the Data Source Credential. Once the project is created, it should leverage the scripts to perform any operations required on the Bitbucket repo. Initially it should show the list of resource files that are found when running validation. That is a good check for the clone.sh and pull.sh scripts. The pushfiles.sh is used when committing files back into the repository so that could take the form of a returned translation, or even a pseudo-localization file.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Command_Center_SSH_Bitbucket&diff=99187Command Center SSH Bitbucket2025-02-04T15:45:01Z<p>Rwilliams: </p>
<hr />
<div>= Connecting Command Center to Bitbucket using SSH =<br />
<br />
== Background ==<br />
Its possible to connect Command Center to Bitbucket without using HTTPS, but instead using Bitbucket. This type of connection is not possible via the standard Bitbucket Connector in the UI as that only supports HTTPS connections. Follow this procedure to leverage an SSH connection to Bitbucket.<br />
<br />
== Process Overview ==<br />
* Creation of a GitHub repo for storing three custom scripts (Using GitHub as example for this)<br />
* Creation of a pub/private key in the Command Center Container<br />
* Adding the public key to Bitbucket Cloud Repository<br />
* Adding three custom scripts to the GitHub Repo<br />
* Creating a Custom Data Source in Command Center to access the three scripts<br />
* Leveraging the Custom Data Source from the desired Command Center Project<br />
<br />
== GitHub Repository Initial Setup ==<br />
Create a new repository in GitHub that will be used for storing the three custom scripts.<br />
* Create top level directory for storing the scripts<br />
* This directory will contain the following three scripts as described later in the document.<br />
** clone.sh<br />
** pull.sh<br />
** pushfiles.sh<br />
<br />
== Bitbucket Cloud Repository Configuration ==<br />
<br />
=== Command Center Container ===<br />
<br />
The Bitbucket repo requires a public key be added to it that is created in Command Center by the connecting user. Below is the process for creating the key to be shared with the Bitbucket Cloud Repo.<br />
* Perform this within the container itself for Command Center<br />
* Do not add a password to the key pair when prompted<br />
* The key will be in the tomcatuser home directory so it must be created by the tomcatuser preferably.<br />
* You will need set tomcatuser to /bin/bash shell from /usr/sbin/nologin as part of the below actions<br />
<br />
Follow the below command after logging into the VM and then logging into the Command Center container as the root user.<br />
<br />
root@d9dfe772ea55:/usr/local/tomcat# chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/sbin/nologin]: /bin/bash<br />
su - tomcatuser<br />
ssh-keygen -t rsa -b8192<br />
Generating public/private rsa key pair.<br />
Enter file in which to save the key (/usr/local/tomcat/.ssh/id_rsa):<br />
Creating directory /usr/local/tomcat/.ssh<br />
Enter passphrase (empty for no passphrase):<br />
Enter same passphrase again:<br />
Your identification has been saved in /usr/local/tomcat/.ssh/id_rsa<br />
Your public key has been saved in /usr/local/tomcat/.ssh/id_rsa.pub<br />
The key fingerprint is:<br />
SHA256:NwG7DJtfwj8FsXc6CWnkdzBrivXrs3rn4jkRDdUq5cc tomcatuser@d9dfe772ea55<br />
The key's randomart image is:<br />
+---[RSA 8192]----+<br />
| . o o... |<br />
| = +.+. .|<br />
| . . X ==oo |<br />
| * = Xo=+ E|<br />
| o S = *o . |<br />
| . = o.o |<br />
| . o .. |<br />
| o=.. |<br />
| .+=B. |<br />
+----[SHA256]-----+<br />
<br />
Copy the public key that was created as it will need to be input into the Bitbucket Cloud Repo for the account that is being leveraged in Bitbucket. Note this key is applied at the user level and not the repository level.<br />
<br />
=== Bitbucket Cloud Repo ===<br />
<br />
Log into the Bitbucket Cloud Server as user as the user the key will be applied. The SSH Key must be added to an account which has write access to the repo.<br />
* Click on Settings Icon to left of the User Icon<br />
* Select SSH Keys in the left column<br />
* Click on Add Key<br />
* Provide a label as appropriate<br />
* Paste the public key (Be sure it's the public key!)<br />
** In this example it is id_rsa.pub<br />
* Select Add key and the key should be listed as available<br />
** Confirm the key has r/w access to the repo as noted in the next section<br />
<br />
=== Command Center Container ===<br />
<br />
Return to the Command Center Container to perform a connection test to the desired repository. You should still be tomcatuser at this point. If not, switch to tomcatuser as before. Perform the below activities and then be sure to switch the tomcatuser shell back to nologin.<br />
<br />
cd /tmp/<br />
git clone git@bitbucket.org:<username>/<repo>.git<br />
This key is not known by any other names<br />
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes<br />
Warning: Permanently added 'bitbucket.org' (ED25519) to the list of known hosts.<br />
exit (returns you to root user)<br />
chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/bin/bash]: /usr/sbin/nologin<br />
<br />
At this point the key has been validated in Bitbucket as working.<br />
<br />
<B>NOTE:</B> At this point you have a working SSH key for Bitbucket. It's important to realize that since this is in a container it will disappear upon reinstall/upgrade of Command Center. Making a backup of the .ssh directory in the container and having it available offline for the future can help to reduce the effort of recreating this process when this occurs<br />
<br />
== Script Additions to GitHub Repository ==<br />
Add the custom scripts listed below to the repository directory in GitHub that previously created. Be sure to update the scripts with your custom information as the scripts will not work as written, the details are required.<br />
* clone.sh<br />
** Requires the following to be updated<br />
*** USER_NAME<br />
*** REPO<br />
*** BRANCH_NAME<br />
* pull.sh<br />
** Requires the following to be updated<br />
*** BRANCH_NAME<br />
* pushfiles.sh<br />
** No modifications are required in this script.<br />
<br />
=== clone.sh ===<br />
<br />
**Be sure to supply the USER_NAME, REPO, BRANCH where indicated**<br />
<br />
#!/bin/bash<br />
<br />
REPO="ssh://git@bitbucket.org/<USER_NAME>/<REPO>.git"<br />
BRANCH="<BRANCH_NAME>"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "Custom Clone Incoming variables:"<br />
echo ""<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " WORKSPACES_DIR = ${WORKSPACES_DIR}"<br />
echo " WORKSPACE_NAME = ${WORKSPACE_NAME}"<br />
echo " REPO = ${REPO}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git clone is $(whoami)"<br />
<br />
# For Debugging<br />
GIT_SSH_COMMAND="ssh" git clone "$REPO" "$WORKSPACES_DIR/$WORKSPACE_NAME"<br />
ret=$?<br />
echo "Clone return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
===pull.sh===<br />
<br />
**Be sure to supply the branch where indicated**<br />
<br />
#!/bin/bash<br />
<br />
BRANCH="<BRANCH_NAME>"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
echo "=================================================================="<br />
echo ""<br />
echo "Custom Pull Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git pull is $(whoami)"<br />
<br />
# For Debugging<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
GIT_SSH_COMMAND="ssh" git --git-dir="$CLIENT_SOURCE_DIR/.git" --work-tree="$CLIENT_SOURCE_DIR" pull<br />
ret=$?<br />
echo "Pull return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
=== pushfiles.sh ===<br />
<br />
#!/bin/bash<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "CUSTOM_PUSH_FILES (${PUSH_TYPE})"<br />
echo ""<br />
echo "Custom Push Files Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " IMPORT_MESSAGE = ${IMPORT_MESSAGE}"<br />
echo " IMPORT_LIST_PATH = ${IMPORT_LIST_PATH}"<br />
<br />
echo "User running pushfiles is $(whoami)"<br />
<br />
# run script<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
echo "Files to import to the repo are: "<br />
cat "${IMPORT_LIST_PATH}"<br />
while IFS= read -r f; do<br />
git add "$f"<br />
ret=$?<br />
echo "Push add status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
done < "${IMPORT_LIST_PATH}"<br />
git commit -m "${IMPORT_MESSAGE}"<br />
GIT_SSH_COMMAND="ssh" git push <br />
ret2=$?<br />
echo "Push return status $ret2"<br />
if [ $ret2 -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
<br />
== Create a new Custom Data Source ==<br />
<br />
Once the scripts have been created, make the scripts accessible to Command Center by adding the directory as a new Custom Data Source<br />
* When naming the Custom Data Source consider using a name that will make it easily identifiable as to what repository and branch the Custom Data Source is pointing towards.<br />
* There will be one Custom Data source created for a single repo/branch used by Command Center<br />
** If two branches from the same repository are required, there will be two Custom Data Sources Required.<br />
<br />
<br />
== Leveraging the Custom Data Source from Command Center ==<br />
<br />
At this point, when the Command Center Project is created, simply select the Custom Data Source as the Data Source Credential and you should be all set.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Command_Center_SSH_Bitbucket&diff=99186Command Center SSH Bitbucket2025-02-04T15:35:47Z<p>Rwilliams: </p>
<hr />
<div>= Connecting Command Center to Bitbucket using SSH =<br />
<br />
== Background ==<br />
Its possible to connect Command Center to Bitbucket without using HTTPS, but instead using Bitbucket. This type of connection is not possible via the standard Bitbucket Connector in the UI as that only supports HTTPS connections. Follow this procedure to leverage an SSH connection to Bitbucket.<br />
<br />
== Process Overview ==<br />
* Creation of a GitHub repo for storing three custom scripts (Using GitHub as example for this)<br />
* Creation of a pub/private key in the Command Center Container<br />
* Adding the public key to Bitbucket Cloud Repository<br />
* Adding three custom scripts to the GitHub Repo<br />
* Creating a Custom Data Source in Command Center to access the three scripts<br />
* Leveraging the Custom Data Source from the desired Command Center Project<br />
<br />
== GitHub Repository ==<br />
Create a new repository in GitHub that will be used for storing the three custom scripts.<br />
* Create top level directory for storing the scripts<br />
* This directory will contain the following three scripts as described later in the document.<br />
** clone.sh<br />
** pull.sh<br />
** pushfiles.sh<br />
<br />
== Bitbucket Cloud Repository Configuration ==<br />
<br />
=== Command Center Container ===<br />
<br />
The Bitbucket repo requires a public key be added to it that is created in Command Center by the connecting user. Below is the process for creating the key to be shared with the Bitbucket Cloud Repo.<br />
* Perform this within the container itself for Command Center<br />
* Do not add a password to the key pair when prompted<br />
* The key will be in the tomcatuser home directory so it must be created by the tomcatuser preferably.<br />
* You will need set tomcatuser to /bin/bash shell from /usr/sbin/nologin as part of the below actions<br />
<br />
Follow the below command after logging into the VM and then logging into the Command Center container as the root user.<br />
<br />
root@d9dfe772ea55:/usr/local/tomcat# chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/sbin/nologin]: /bin/bash<br />
su - tomcatuser<br />
ssh-keygen -t rsa -b8192<br />
Generating public/private rsa key pair.<br />
Enter file in which to save the key (/usr/local/tomcat/.ssh/id_rsa):<br />
Creating directory /usr/local/tomcat/.ssh<br />
Enter passphrase (empty for no passphrase):<br />
Enter same passphrase again:<br />
Your identification has been saved in /usr/local/tomcat/.ssh/id_rsa<br />
Your public key has been saved in /usr/local/tomcat/.ssh/id_rsa.pub<br />
The key fingerprint is:<br />
SHA256:NwG7DJtfwj8FsXc6CWnkdzBrivXrs3rn4jkRDdUq5cc tomcatuser@d9dfe772ea55<br />
The key's randomart image is:<br />
+---[RSA 8192]----+<br />
| . o o... |<br />
| = +.+. .|<br />
| . . X ==oo |<br />
| * = Xo=+ E|<br />
| o S = *o . |<br />
| . = o.o |<br />
| . o .. |<br />
| o=.. |<br />
| .+=B. |<br />
+----[SHA256]-----+<br />
<br />
Copy the public key that was created as it will need to be input into the Bitbucket Cloud Repo for the account that is being leveraged in Bitbucket. Note this key is applied at the user level and not the repository level.<br />
<br />
=== Bitbucket Cloud Repo ===<br />
<br />
Log into the Bitbucket Cloud Server as user as the user the key will be applied. The SSH Key must be added to an account which has write access to the repo.<br />
* Click on Settings Icon to left of the User Icon<br />
* Select SSH Keys in the left column<br />
* Click on Add Key<br />
* Provide a label as appropriate<br />
* Paste the public key (Be sure it's the public key!)<br />
** In this example it is id_rsa.pub<br />
* Select Add key and the key should be listed as available<br />
** Confirm the key has r/w access to the repo as noted in the next section<br />
<br />
=== Command Center Container ===<br />
<br />
Return to the Command Center Container to perform a connection test to the desired repository. You should still be tomcatuser at this point. If not, switch to tomcatuser as before. Perform the below activities and then be sure to switch the tomcatuser shell back to nologin.<br />
<br />
cd /tmp/<br />
git clone git@bitbucket.org:<username>/<repo>.git<br />
This key is not known by any other names<br />
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes<br />
Warning: Permanently added 'bitbucket.org' (ED25519) to the list of known hosts.<br />
exit (returns you to root user)<br />
chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/bin/bash]: /usr/sbin/nologin<br />
<br />
At this point the key has been validated in Bitbucket as working.<br />
<br />
**NOTE: At this point you have a working SSH key for Bitbucket. It's<br />
important to realize that since this is in a container it will<br />
disappear upon reinstall/upgrade of Command Center. Making a backup<br />
of the .ssh directory and having it available for the future can help<br />
to reduce the effort of recreating this process when this occurs**<br />
<br />
<br />
## Procedure<br />
<br />
<br />
### Create a Repo for the required Shell Scripts<br />
<br />
<br />
*clone.sh<br />
**USER_NAME<br />
**REPO<br />
**BRANCH_NAME<br />
*pull.sh<br />
** BRANCH_NAME<br />
*pushfiles.sh<br />
** No modification needed<br />
<br />
Add the contents below to each of the respective files, being sure to<br />
update the user_name/repo/branch where indicated.<br />
<br />
=== clone.sh ===<br />
<br />
**Be sure to supply the USER_NAME, REPO, BRANCH where indicated**<br />
<br />
#!/bin/bash<br />
<br />
REPO="ssh://git@bitbucket.org/<USER_NAME>/<REPO>.git"<br />
BRANCH="BRANCH_NAME"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "Custom Clone Incoming variables:"<br />
echo ""<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " WORKSPACES_DIR = ${WORKSPACES_DIR}"<br />
echo " WORKSPACE_NAME = ${WORKSPACE_NAME}"<br />
echo " REPO = ${REPO}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git clone is $(whoami)"<br />
<br />
# For Debugging<br />
GIT_SSH_COMMAND="ssh" git clone "$REPO" "$WORKSPACES_DIR/$WORKSPACE_NAME"<br />
ret=$?<br />
echo "Clone return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
===pull.sh===<br />
<br />
**Be sure to supply the branch where indicated**<br />
<br />
#!/bin/bash<br />
<br />
BRANCH="BRANCH_NAME"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
echo "=================================================================="<br />
echo ""<br />
echo "Custom Pull Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git pull is $(whoami)"<br />
<br />
# For Debugging<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
GIT_SSH_COMMAND="ssh" git --git-dir="$CLIENT_SOURCE_DIR/.git" --work-tree="$CLIENT_SOURCE_DIR" pull<br />
ret=$?<br />
echo "Pull return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
=== pushfiles.sh ===<br />
<br />
#!/bin/bash<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "CUSTOM_PUSH_FILES (${PUSH_TYPE})"<br />
echo ""<br />
echo "Custom Push Files Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " IMPORT_MESSAGE = ${IMPORT_MESSAGE}"<br />
echo " IMPORT_LIST_PATH = ${IMPORT_LIST_PATH}"<br />
<br />
echo "User running pushfiles is $(whoami)"<br />
<br />
# run script<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
echo "Files to import to the repo are: "<br />
cat "${IMPORT_LIST_PATH}"<br />
while IFS= read -r f; do<br />
git add "$f"<br />
ret=$?<br />
echo "Push add status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
done < "${IMPORT_LIST_PATH}"<br />
git commit -m "${IMPORT_MESSAGE}"<br />
GIT_SSH_COMMAND="ssh" git push <br />
ret2=$?<br />
echo "Push return status $ret2"<br />
if [ $ret2 -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
<br />
== Create a new Custom Data Source ==<br />
<br />
Once the scripts have been created, make the scripts accessible to Command Center by adding the directory as a new Custom Data Source<br />
* When naming the Custom Data Source consider using a name that will make it easily identifiable as to what repository and branch the Custom Data Source is pointing towards.<br />
* There will be one Custom Data source created for a single repo/branch used by Command Center<br />
** If two branches from the same repository are required, there will be two Custom Data Sources Required.<br />
<br />
<br />
== Leveraging the Custom Data Source from Command Center ==<br />
<br />
At this point, when the Command Center Project is created, simply select the Custom Data Source as the Data Source Credential and you should be all set.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Command_Center_SSH_Bitbucket&diff=99185Command Center SSH Bitbucket2025-02-04T15:32:10Z<p>Rwilliams: </p>
<hr />
<div>= Connecting Command Center to Bitbucket using SSH =<br />
<br />
== Background ==<br />
Its possible to connect Command Center to Bitbucket without using HTTPS, but instead using Bitbucket. This type of connection is not possible via the standard Bitbucket Connector in the UI as that only supports HTTPS connections. Follow this procedure to leverage an SSH connection to Bitbucket.<br />
<br />
== Process Overview ==<br />
* Creation of a GitHub repo for storing three custom scripts (Using GitHub as example for this)<br />
* Creation of a pub/private key in the Command Center Container<br />
* Adding the public key to Bitbucket Cloud Repository<br />
* Adding three custom scripts to the GitHub Repo<br />
* Creating a Custom Data Source in Command Center to access the three scripts<br />
* Leveraging the Custom Data Source from the desired Command Center Project<br />
<br />
== GitHub Repository ==<br />
Create a new repository in GitHub that will be used for storing the three custom scripts.<br />
* Create top level directory for storing the scripts<br />
* This directory will contain the following three scripts as described later in the document.<br />
** clone.sh<br />
** pull.sh<br />
** pushfiles.sh<br />
<br />
== Bitbucket Cloud Repository Configuration ==<br />
<br />
=== Command Center Container ===<br />
<br />
The Bitbucket repo requires a public key be added to it that is created in Command Center by the connecting user. Below is the process for creating the key to be shared with the Bitbucket Cloud Repo.<br />
* Perform this within the container itself for Command Center<br />
* Do not add a password to the key pair when prompted<br />
* The key will be in the tomcatuser home directory so it must be created by the tomcatuser preferably.<br />
* You will need set tomcatuser to /bin/bash shell from /usr/sbin/nologin as part of the below actions<br />
<br />
Follow the below command after logging into the VM and then logging into the Command Center container as the root user.<br />
<br />
root@d9dfe772ea55:/usr/local/tomcat# chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/sbin/nologin]: /bin/bash<br />
su - tomcatuser<br />
ssh-keygen -t rsa -b8192<br />
Generating public/private rsa key pair.<br />
Enter file in which to save the key (/usr/local/tomcat/.ssh/id_rsa):<br />
Creating directory /usr/local/tomcat/.ssh<br />
Enter passphrase (empty for no passphrase):<br />
Enter same passphrase again:<br />
Your identification has been saved in /usr/local/tomcat/.ssh/id_rsa<br />
Your public key has been saved in /usr/local/tomcat/.ssh/id_rsa.pub<br />
The key fingerprint is:<br />
SHA256:NwG7DJtfwj8FsXc6CWnkdzBrivXrs3rn4jkRDdUq5cc tomcatuser@d9dfe772ea55<br />
The key's randomart image is:<br />
+---[RSA 8192]----+<br />
| . o o... |<br />
| = +.+. .|<br />
| . . X ==oo |<br />
| * = Xo=+ E|<br />
| o S = *o . |<br />
| . = o.o |<br />
| . o .. |<br />
| o=.. |<br />
| .+=B. |<br />
+----[SHA256]-----+<br />
<br />
Copy the public key that was created as it will need to be input into the Bitbucket Cloud Repo for the account that is being leveraged in Bitbucket. Note this key is applied at the user level and not the repository level.<br />
<br />
=== Bitbucket Cloud Repo ===<br />
<br />
Log into the Bitbucket Cloud Server as user as the user the key will be applied. The SSH Key must be added to an account which has write access to the repo.<br />
* Click on Settings Icon to left of the User Icon<br />
* Select SSH Keys in the left column<br />
* Click on Add Key<br />
* Provide a label as appropriate<br />
* Paste the public key (Be sure it's the public key!)<br />
** In this example it is id_rsa.pub<br />
* Select Add key and the key should be listed as available<br />
** Confirm the key has r/w access to the repo as noted in the next section<br />
<br />
**You will need reset tomcatuser to /usr/sbin/nologin shell from<br />
/bin/bash as part of the below actions**<br />
<br />
cd /tmp/<br />
git clone git@bitbucket.org:<username>/<repo>.git<br />
This key is not known by any other names<br />
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes<br />
Warning: Permanently added 'bitbucket.org' (ED25519) to the list of known hosts.<br />
exit (returns you to root user)<br />
chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/bin/bash]: /usr/sbin/nologin<br />
<br />
At this point the key has been validated in Bitbucket as working.<br />
<br />
**NOTE: At this point you have a working SSH key for Bitbucket. It's<br />
important to realize that since this is in a container it will<br />
disappear upon reinstall/upgrade of Command Center. Making a backup<br />
of the .ssh directory and having it available for the future can help<br />
to reduce the effort of recreating this process when this occurs**<br />
<br />
<br />
## Procedure<br />
<br />
<br />
### Create a Repo for the required Shell Scripts<br />
<br />
<br />
*clone.sh<br />
**USER_NAME<br />
**REPO<br />
**BRANCH_NAME<br />
*pull.sh<br />
** BRANCH_NAME<br />
*pushfiles.sh<br />
** No modification needed<br />
<br />
Add the contents below to each of the respective files, being sure to<br />
update the user_name/repo/branch where indicated.<br />
<br />
=== clone.sh ===<br />
<br />
**Be sure to supply the USER_NAME, REPO, BRANCH where indicated**<br />
<br />
#!/bin/bash<br />
<br />
REPO="ssh://git@bitbucket.org/<USER_NAME>/<REPO>.git"<br />
BRANCH="BRANCH_NAME"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "Custom Clone Incoming variables:"<br />
echo ""<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " WORKSPACES_DIR = ${WORKSPACES_DIR}"<br />
echo " WORKSPACE_NAME = ${WORKSPACE_NAME}"<br />
echo " REPO = ${REPO}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git clone is $(whoami)"<br />
<br />
# For Debugging<br />
GIT_SSH_COMMAND="ssh" git clone "$REPO" "$WORKSPACES_DIR/$WORKSPACE_NAME"<br />
ret=$?<br />
echo "Clone return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
===pull.sh===<br />
<br />
**Be sure to supply the branch where indicated**<br />
<br />
#!/bin/bash<br />
<br />
BRANCH="BRANCH_NAME"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
echo "=================================================================="<br />
echo ""<br />
echo "Custom Pull Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git pull is $(whoami)"<br />
<br />
# For Debugging<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
GIT_SSH_COMMAND="ssh" git --git-dir="$CLIENT_SOURCE_DIR/.git" --work-tree="$CLIENT_SOURCE_DIR" pull<br />
ret=$?<br />
echo "Pull return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
=== pushfiles.sh ===<br />
<br />
#!/bin/bash<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "CUSTOM_PUSH_FILES (${PUSH_TYPE})"<br />
echo ""<br />
echo "Custom Push Files Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " IMPORT_MESSAGE = ${IMPORT_MESSAGE}"<br />
echo " IMPORT_LIST_PATH = ${IMPORT_LIST_PATH}"<br />
<br />
echo "User running pushfiles is $(whoami)"<br />
<br />
# run script<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
echo "Files to import to the repo are: "<br />
cat "${IMPORT_LIST_PATH}"<br />
while IFS= read -r f; do<br />
git add "$f"<br />
ret=$?<br />
echo "Push add status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
done < "${IMPORT_LIST_PATH}"<br />
git commit -m "${IMPORT_MESSAGE}"<br />
GIT_SSH_COMMAND="ssh" git push <br />
ret2=$?<br />
echo "Push return status $ret2"<br />
if [ $ret2 -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
<br />
== Create a new Custom Data Source ==<br />
<br />
Once the scripts have been created, make the scripts accessible to Command Center by adding the directory as a new Custom Data Source<br />
* When naming the Custom Data Source consider using a name that will make it easily identifiable as to what repository and branch the Custom Data Source is pointing towards.<br />
* There will be one Custom Data source created for a single repo/branch used by Command Center<br />
** If two branches from the same repository are required, there will be two Custom Data Sources Required.<br />
<br />
<br />
== Leveraging the Custom Data Source from Command Center ==<br />
<br />
At this point, when the Command Center Project is created, simply select the Custom Data Source as the Data Source Credential and you should be all set.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Command_Center_SSH_Bitbucket&diff=99184Command Center SSH Bitbucket2025-02-04T15:24:22Z<p>Rwilliams: </p>
<hr />
<div>= Connecting Command Center to Bitbucket using SSH =<br />
<br />
== Background ==<br />
Its possible to connect Command Center to Bitbucket without using HTTPS, but instead using Bitbucket. This type of connection is not possible via the standard Bitbucket Connector in the UI as that only supports HTTPS connections. Follow this procedure to leverage an SSH connection to Bitbucket.<br />
<br />
== Process Overview ==<br />
* Creation of a GitHub repo for storing three custom scripts (Using GitHub as example for this)<br />
* Creation of a pub/private key in the Command Center Container<br />
* Adding the public key to Bitbucket Cloud Repository<br />
* Adding three custom scripts to the GitHub Repo<br />
* Creating a Custom Data Source in Command Center to access the three scripts<br />
* Leveraging the Custom Data Source from the desired Command Center Project<br />
<br />
== GitHub Repository ==<br />
Create a new repository in GitHub that will be used for storing the three custom scripts.<br />
* Create top level directory for storing the scripts<br />
* This directory will contain the following three scripts as described later in the document.<br />
** clone.sh<br />
** pull.sh<br />
** pushfiles.sh<br />
<br />
== Bitbucket Cloud Repository Configuration ==<br />
<br />
=== Command Center Container ===<br />
<br />
The Bitbucket repo requires a public key be added to it that is created in Command Center by the connecting user. Below is the process for creating the key to be shared with the Bitbucket Cloud Repo.<br />
* Perform this within the container itself for Command Center<br />
* Do not add a password to the key pair when prompted<br />
* The key will be in the tomcatuser home directory so it must be created by the tomcatuser preferably.<br />
* You will need set tomcatuser to /bin/bash shell from /usr/sbin/nologin as part of the below actions<br />
<br />
Follow the below command after logging into the VM and then logging into the Command Center container as the root user.<br />
<br />
root@d9dfe772ea55:/usr/local/tomcat# chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/sbin/nologin]: /bin/bash<br />
su - tomcatuser<br />
ssh-keygen -t rsa -b8192<br />
Generating public/private rsa key pair.<br />
Enter file in which to save the key (/usr/local/tomcat/.ssh/id_rsa):<br />
Creating directory /usr/local/tomcat/.ssh<br />
Enter passphrase (empty for no passphrase):<br />
Enter same passphrase again:<br />
Your identification has been saved in /usr/local/tomcat/.ssh/id_rsa<br />
Your public key has been saved in /usr/local/tomcat/.ssh/id_rsa.pub<br />
The key fingerprint is:<br />
SHA256:NwG7DJtfwj8FsXc6CWnkdzBrivXrs3rn4jkRDdUq5cc tomcatuser@d9dfe772ea55<br />
The key's randomart image is:<br />
+---[RSA 8192]----+<br />
| . o o... |<br />
| = +.+. .|<br />
| . . X ==oo |<br />
| * = Xo=+ E|<br />
| o S = *o . |<br />
| . = o.o |<br />
| . o .. |<br />
| o=.. |<br />
| .+=B. |<br />
+----[SHA256]-----+<br />
<br />
- Add the key to the Bitbucket Account<br />
- This is performed on the Bitbucket Server<br />
- SSH Key must be added to an account which has write access to the<br />
repo.<br />
- Click on Settings Icon to left of the User Icon<br />
- Select SSH Keys in the left column<br />
- Click on Add Key<br />
- Provide a label as appropriate<br />
- Paste the public key (Be sure it's the public key!)<br />
- In this example it is id\_rsa.pub<br />
- Select Add key and the key should be listed as available<br />
- Confirm the key has r/w access to the repo<br />
<br />
The system doesn't allow for a shell to be used by tomcatuser, so it<br />
must temporarily be set to allow this for testing and setting up the<br />
ssh key.<br />
<br />
**You will need reset tomcatuser to /usr/sbin/nologin shell from<br />
/bin/bash as part of the below actions**<br />
<br />
cd /tmp/<br />
git clone git@bitbucket.org:<username>/<repo>.git<br />
This key is not known by any other names<br />
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes<br />
Warning: Permanently added 'bitbucket.org' (ED25519) to the list of known hosts.<br />
exit (returns you to root user)<br />
chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/bin/bash]: /usr/sbin/nologin<br />
<br />
At this point the key has been validated in Bitbucket as working.<br />
<br />
**NOTE: At this point you have a working SSH key for Bitbucket. It's<br />
important to realize that since this is in a container it will<br />
disappear upon reinstall/upgrade of Command Center. Making a backup<br />
of the .ssh directory and having it available for the future can help<br />
to reduce the effort of recreating this process when this occurs**<br />
<br />
<br />
## Procedure<br />
<br />
<br />
### Create a Repo for the required Shell Scripts<br />
<br />
<br />
*clone.sh<br />
**USER_NAME<br />
**REPO<br />
**BRANCH_NAME<br />
*pull.sh<br />
** BRANCH_NAME<br />
*pushfiles.sh<br />
** No modification needed<br />
<br />
Add the contents below to each of the respective files, being sure to<br />
update the user_name/repo/branch where indicated.<br />
<br />
=== clone.sh ===<br />
<br />
**Be sure to supply the USER_NAME, REPO, BRANCH where indicated**<br />
<br />
#!/bin/bash<br />
<br />
REPO="ssh://git@bitbucket.org/<USER_NAME>/<REPO>.git"<br />
BRANCH="BRANCH_NAME"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "Custom Clone Incoming variables:"<br />
echo ""<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " WORKSPACES_DIR = ${WORKSPACES_DIR}"<br />
echo " WORKSPACE_NAME = ${WORKSPACE_NAME}"<br />
echo " REPO = ${REPO}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git clone is $(whoami)"<br />
<br />
# For Debugging<br />
GIT_SSH_COMMAND="ssh" git clone "$REPO" "$WORKSPACES_DIR/$WORKSPACE_NAME"<br />
ret=$?<br />
echo "Clone return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
===pull.sh===<br />
<br />
**Be sure to supply the branch where indicated**<br />
<br />
#!/bin/bash<br />
<br />
BRANCH="BRANCH_NAME"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
echo "=================================================================="<br />
echo ""<br />
echo "Custom Pull Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git pull is $(whoami)"<br />
<br />
# For Debugging<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
GIT_SSH_COMMAND="ssh" git --git-dir="$CLIENT_SOURCE_DIR/.git" --work-tree="$CLIENT_SOURCE_DIR" pull<br />
ret=$?<br />
echo "Pull return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
=== pushfiles.sh ===<br />
<br />
#!/bin/bash<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "CUSTOM_PUSH_FILES (${PUSH_TYPE})"<br />
echo ""<br />
echo "Custom Push Files Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " IMPORT_MESSAGE = ${IMPORT_MESSAGE}"<br />
echo " IMPORT_LIST_PATH = ${IMPORT_LIST_PATH}"<br />
<br />
echo "User running pushfiles is $(whoami)"<br />
<br />
# run script<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
echo "Files to import to the repo are: "<br />
cat "${IMPORT_LIST_PATH}"<br />
while IFS= read -r f; do<br />
git add "$f"<br />
ret=$?<br />
echo "Push add status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
done < "${IMPORT_LIST_PATH}"<br />
git commit -m "${IMPORT_MESSAGE}"<br />
GIT_SSH_COMMAND="ssh" git push <br />
ret2=$?<br />
echo "Push return status $ret2"<br />
if [ $ret2 -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
<br />
== Create a new Custom Data Source ==<br />
<br />
Once the scripts have been created, make the scripts accessible to Command Center by adding the directory as a new Custom Data Source<br />
* When naming the Custom Data Source consider using a name that will make it easily identifiable as to what repository and branch the Custom Data Source is pointing towards.<br />
* There will be one Custom Data source created for a single repo/branch used by Command Center<br />
** If two branches from the same repository are required, there will be two Custom Data Sources Required.<br />
<br />
<br />
== Leveraging the Custom Data Source from Command Center ==<br />
<br />
At this point, when the Command Center Project is created, simply select the Custom Data Source as the Data Source Credential and you should be all set.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Command_Center_SSH_Bitbucket&diff=99183Command Center SSH Bitbucket2025-02-04T15:10:39Z<p>Rwilliams: </p>
<hr />
<div>= Connecting Command Center to Bitbucket using SSH =<br />
<br />
== Background ==<br />
Its possible to connect Command Center to Bitbucket without using HTTPS, but instead using Bitbucket. This type of connection is not possible via the standard Bitbucket Connector in the UI as that only supports HTTPS connections. Follow this procedure to leverage an SSH connection to Bitbucket.<br />
<br />
### Github Repo for Storing Scripts<br />
<br />
- Requires a repo to place Data Source Shell Scripts<br />
- Similar in functionality to transforms<br />
- Create top level directory for storing the scripts<br />
- This directory will contain the following three scripts as described<br />
later in the document.<br />
- clone.sh<br />
- pull.sh<br />
- pushfiles.sh<br />
<br />
<br />
### Bitbucket Cloud Repo<br />
<br />
- Need an ssh public key created in the container<br />
- Perform this within the container itself for Command Center<br />
- Do not add a password to the key<br />
- The key will be in the tomcatuser home directory so it must be<br />
created by the tomcatuser preferably.<br />
<br />
**You will need set tomcatuser to /bin/bash shell from<br />
/usr/sbin/nologin as part of the below actions**<br />
<br />
Here is the output from the command line:<br />
<br />
root@d9dfe772ea55:/usr/local/tomcat# chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/sbin/nologin]: /bin/bash<br />
su - tomcatuser<br />
ssh-keygen -t rsa -b8192<br />
Generating public/private rsa key pair.<br />
Enter file in which to save the key (/usr/local/tomcat/.ssh/id_rsa):<br />
Creating directory /usr/local/tomcat/.ssh<br />
Enter passphrase (empty for no passphrase):<br />
Enter same passphrase again:<br />
Your identification has been saved in /usr/local/tomcat/.ssh/id_rsa<br />
Your public key has been saved in /usr/local/tomcat/.ssh/id_rsa.pub<br />
The key fingerprint is:<br />
SHA256:NwG7DJtfwj8FsXc6CWnkdzBrivXrs3rn4jkRDdUq5cc tomcatuser@d9dfe772ea55<br />
The key's randomart image is:<br />
+---[RSA 8192]----+<br />
| . o o... |<br />
| = +.+. .|<br />
| . . X ==oo |<br />
| * = Xo=+ E|<br />
| o S = *o . |<br />
| . = o.o |<br />
| . o .. |<br />
| o=.. |<br />
| .+=B. |<br />
+----[SHA256]-----+<br />
<br />
- Add the key to the Bitbucket Account<br />
- This is performed on the Bitbucket Server<br />
- SSH Key must be added to an account which has write access to the<br />
repo.<br />
- Click on Settings Icon to left of the User Icon<br />
- Select SSH Keys in the left column<br />
- Click on Add Key<br />
- Provide a label as appropriate<br />
- Paste the public key (Be sure it's the public key!)<br />
- In this example it is id\_rsa.pub<br />
- Select Add key and the key should be listed as available<br />
- Confirm the key has r/w access to the repo<br />
<br />
The system doesn't allow for a shell to be used by tomcatuser, so it<br />
must temporarily be set to allow this for testing and setting up the<br />
ssh key.<br />
<br />
**You will need reset tomcatuser to /usr/sbin/nologin shell from<br />
/bin/bash as part of the below actions**<br />
<br />
cd /tmp/<br />
git clone git@bitbucket.org:<username>/<repo>.git<br />
This key is not known by any other names<br />
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes<br />
Warning: Permanently added 'bitbucket.org' (ED25519) to the list of known hosts.<br />
exit (returns you to root user)<br />
chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/bin/bash]: /usr/sbin/nologin<br />
<br />
At this point the key has been validated in Bitbucket as working.<br />
<br />
**NOTE: At this point you have a working SSH key for Bitbucket. It's<br />
important to realize that since this is in a container it will<br />
disappear upon reinstall/upgrade of Command Center. Making a backup<br />
of the .ssh directory and having it available for the future can help<br />
to reduce the effort of recreating this process when this occurs**<br />
<br />
<br />
## Procedure<br />
<br />
<br />
### Create a Repo for the required Shell Scripts<br />
<br />
<br />
*clone.sh<br />
**USER_NAME<br />
**REPO<br />
**BRANCH_NAME<br />
*pull.sh<br />
** BRANCH_NAME<br />
*pushfiles.sh<br />
** No modification needed<br />
<br />
Add the contents below to each of the respective files, being sure to<br />
update the user_name/repo/branch where indicated.<br />
<br />
=== clone.sh ===<br />
<br />
**Be sure to supply the USER_NAME, REPO, BRANCH where indicated**<br />
<br />
#!/bin/bash<br />
<br />
REPO="ssh://git@bitbucket.org/<USER_NAME>/<REPO>.git"<br />
BRANCH="BRANCH_NAME"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "Custom Clone Incoming variables:"<br />
echo ""<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " WORKSPACES_DIR = ${WORKSPACES_DIR}"<br />
echo " WORKSPACE_NAME = ${WORKSPACE_NAME}"<br />
echo " REPO = ${REPO}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git clone is $(whoami)"<br />
<br />
# For Debugging<br />
GIT_SSH_COMMAND="ssh" git clone "$REPO" "$WORKSPACES_DIR/$WORKSPACE_NAME"<br />
ret=$?<br />
echo "Clone return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
===pull.sh===<br />
<br />
**Be sure to supply the branch where indicated**<br />
<br />
#!/bin/bash<br />
<br />
BRANCH="BRANCH_NAME"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
echo "=================================================================="<br />
echo ""<br />
echo "Custom Pull Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git pull is $(whoami)"<br />
<br />
# For Debugging<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
GIT_SSH_COMMAND="ssh" git --git-dir="$CLIENT_SOURCE_DIR/.git" --work-tree="$CLIENT_SOURCE_DIR" pull<br />
ret=$?<br />
echo "Pull return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
=== pushfiles.sh ===<br />
<br />
#!/bin/bash<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "CUSTOM_PUSH_FILES (${PUSH_TYPE})"<br />
echo ""<br />
echo "Custom Push Files Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " IMPORT_MESSAGE = ${IMPORT_MESSAGE}"<br />
echo " IMPORT_LIST_PATH = ${IMPORT_LIST_PATH}"<br />
<br />
echo "User running pushfiles is $(whoami)"<br />
<br />
# run script<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
echo "Files to import to the repo are: "<br />
cat "${IMPORT_LIST_PATH}"<br />
while IFS= read -r f; do<br />
git add "$f"<br />
ret=$?<br />
echo "Push add status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
done < "${IMPORT_LIST_PATH}"<br />
git commit -m "${IMPORT_MESSAGE}"<br />
GIT_SSH_COMMAND="ssh" git push <br />
ret2=$?<br />
echo "Push return status $ret2"<br />
if [ $ret2 -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
<br />
== Create a new Custom Data Source ==<br />
<br />
Once the scripts have been created, make the scripts accessible to Command Center by adding the directory as a new Custom Data Source<br />
* When naming the Custom Data Source consider using a name that will make it easily identifiable as to what repository and branch the Custom Data Source is pointing towards.<br />
* There will be one Custom Data source created for a single repo/branch used by Command Center<br />
** If two branches from the same repository are required, there will be two Custom Data Sources Required.<br />
<br />
<br />
== Leveraging the Custom Data Source from Command Center ==<br />
<br />
At this point, when the Command Center Project is created, simply select the Custom Data Source as the Data Source Credential and you should be all set.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Command_Center_SSH_Bitbucket&diff=99182Command Center SSH Bitbucket2025-02-04T15:07:33Z<p>Rwilliams: </p>
<hr />
<div>## Prerequisites<br />
<br />
<br />
### Github Repo for Storing Scripts<br />
<br />
- Requires a repo to place Data Source Shell Scripts<br />
- Similar in functionality to transforms<br />
- Create top level directory for storing the scripts<br />
- This directory will contain the following three scripts as described<br />
later in the document.<br />
- clone.sh<br />
- pull.sh<br />
- pushfiles.sh<br />
<br />
<br />
### Bitbucket Cloud Repo<br />
<br />
- Need an ssh public key created in the container<br />
- Perform this within the container itself for Command Center<br />
- Do not add a password to the key<br />
- The key will be in the tomcatuser home directory so it must be<br />
created by the tomcatuser preferably.<br />
<br />
**You will need set tomcatuser to /bin/bash shell from<br />
/usr/sbin/nologin as part of the below actions**<br />
<br />
Here is the output from the command line:<br />
<br />
root@d9dfe772ea55:/usr/local/tomcat# chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/sbin/nologin]: /bin/bash<br />
su - tomcatuser<br />
ssh-keygen -t rsa -b8192<br />
Generating public/private rsa key pair.<br />
Enter file in which to save the key (/usr/local/tomcat/.ssh/id_rsa):<br />
Creating directory /usr/local/tomcat/.ssh<br />
Enter passphrase (empty for no passphrase):<br />
Enter same passphrase again:<br />
Your identification has been saved in /usr/local/tomcat/.ssh/id_rsa<br />
Your public key has been saved in /usr/local/tomcat/.ssh/id_rsa.pub<br />
The key fingerprint is:<br />
SHA256:NwG7DJtfwj8FsXc6CWnkdzBrivXrs3rn4jkRDdUq5cc tomcatuser@d9dfe772ea55<br />
The key's randomart image is:<br />
+---[RSA 8192]----+<br />
| . o o... |<br />
| = +.+. .|<br />
| . . X ==oo |<br />
| * = Xo=+ E|<br />
| o S = *o . |<br />
| . = o.o |<br />
| . o .. |<br />
| o=.. |<br />
| .+=B. |<br />
+----[SHA256]-----+<br />
<br />
- Add the key to the Bitbucket Account<br />
- This is performed on the Bitbucket Server<br />
- SSH Key must be added to an account which has write access to the<br />
repo.<br />
- Click on Settings Icon to left of the User Icon<br />
- Select SSH Keys in the left column<br />
- Click on Add Key<br />
- Provide a label as appropriate<br />
- Paste the public key (Be sure it's the public key!)<br />
- In this example it is id\_rsa.pub<br />
- Select Add key and the key should be listed as available<br />
- Confirm the key has r/w access to the repo<br />
<br />
The system doesn't allow for a shell to be used by tomcatuser, so it<br />
must temporarily be set to allow this for testing and setting up the<br />
ssh key.<br />
<br />
**You will need reset tomcatuser to /usr/sbin/nologin shell from<br />
/bin/bash as part of the below actions**<br />
<br />
cd /tmp/<br />
git clone git@bitbucket.org:<username>/<repo>.git<br />
This key is not known by any other names<br />
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes<br />
Warning: Permanently added 'bitbucket.org' (ED25519) to the list of known hosts.<br />
exit (returns you to root user)<br />
chsh tomcatuser<br />
Changing the login shell for tomcatuser<br />
Enter the new value, or press ENTER for the default<br />
Login Shell [/bin/bash]: /usr/sbin/nologin<br />
<br />
At this point the key has been validated in Bitbucket as working.<br />
<br />
**NOTE: At this point you have a working SSH key for Bitbucket. It's<br />
important to realize that since this is in a container it will<br />
disappear upon reinstall/upgrade of Command Center. Making a backup<br />
of the .ssh directory and having it available for the future can help<br />
to reduce the effort of recreating this process when this occurs**<br />
<br />
<br />
## Procedure<br />
<br />
<br />
### Create a Repo for the required Shell Scripts<br />
<br />
<br />
*clone.sh<br />
**USER_NAME<br />
**REPO<br />
**BRANCH_NAME<br />
*pull.sh<br />
** BRANCH_NAME<br />
*pushfiles.sh<br />
** No modification needed<br />
<br />
Add the contents below to each of the respective files, being sure to<br />
update the user_name/repo/branch where indicated.<br />
<br />
=== clone.sh ===<br />
<br />
**Be sure to supply the USER_NAME, REPO, BRANCH where indicated**<br />
<br />
#!/bin/bash<br />
<br />
REPO="ssh://git@bitbucket.org/<USER_NAME>/<REPO>.git"<br />
BRANCH="BRANCH_NAME"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "Custom Clone Incoming variables:"<br />
echo ""<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " WORKSPACES_DIR = ${WORKSPACES_DIR}"<br />
echo " WORKSPACE_NAME = ${WORKSPACE_NAME}"<br />
echo " REPO = ${REPO}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git clone is $(whoami)"<br />
<br />
# For Debugging<br />
GIT_SSH_COMMAND="ssh" git clone "$REPO" "$WORKSPACES_DIR/$WORKSPACE_NAME"<br />
ret=$?<br />
echo "Clone return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
===pull.sh===<br />
<br />
**Be sure to supply the branch where indicated**<br />
<br />
#!/bin/bash<br />
<br />
BRANCH="BRANCH_NAME"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
echo "=================================================================="<br />
echo ""<br />
echo "Custom Pull Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git pull is $(whoami)"<br />
<br />
# For Debugging<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
GIT_SSH_COMMAND="ssh" git --git-dir="$CLIENT_SOURCE_DIR/.git" --work-tree="$CLIENT_SOURCE_DIR" pull<br />
ret=$?<br />
echo "Pull return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
=== pushfiles.sh ===<br />
<br />
#!/bin/bash<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "CUSTOM_PUSH_FILES (${PUSH_TYPE})"<br />
echo ""<br />
echo "Custom Push Files Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " IMPORT_MESSAGE = ${IMPORT_MESSAGE}"<br />
echo " IMPORT_LIST_PATH = ${IMPORT_LIST_PATH}"<br />
<br />
echo "User running pushfiles is $(whoami)"<br />
<br />
# run script<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
echo "Files to import to the repo are: "<br />
cat "${IMPORT_LIST_PATH}"<br />
while IFS= read -r f; do<br />
git add "$f"<br />
ret=$?<br />
echo "Push add status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
done < "${IMPORT_LIST_PATH}"<br />
git commit -m "${IMPORT_MESSAGE}"<br />
GIT_SSH_COMMAND="ssh" git push <br />
ret2=$?<br />
echo "Push return status $ret2"<br />
if [ $ret2 -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
<br />
== Create a new Custom Data Source ==<br />
<br />
Once the scripts have been created, make the scripts accessible to Command Center by adding the directory as a new Custom Data Source<br />
* When naming the Custom Data Source consider using a name that will make it easily identifiable as to what repository and branch the Custom Data Source is pointing towards.<br />
* There will be one Custom Data source created for a single repo/branch used by Command Center<br />
** If two branches from the same repository are required, there will be two Custom Data Sources Required.<br />
<br />
<br />
== Leveraging the Custom Data Source from Command Center ==<br />
<br />
At this point, when the Command Center Project is created, simply select the Custom Data Source as the Data Source Credential and you should be all set.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Command_Center_SSH_Bitbucket&diff=99181Command Center SSH Bitbucket2025-02-04T15:06:14Z<p>Rwilliams: </p>
<hr />
<div>*clone.sh<br />
**USER_NAME<br />
**REPO<br />
**BRANCH_NAME<br />
*pull.sh<br />
** BRANCH_NAME<br />
*pushfiles.sh<br />
** No modification needed<br />
<br />
Add the contents below to each of the respective files, being sure to<br />
update the user_name/repo/branch where indicated.<br />
<br />
=== clone.sh ===<br />
<br />
**Be sure to supply the USER_NAME, REPO, BRANCH where indicated**<br />
<br />
#!/bin/bash<br />
<br />
REPO="ssh://git@bitbucket.org/<USER_NAME>/<REPO>.git"<br />
BRANCH="BRANCH_NAME"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "Custom Clone Incoming variables:"<br />
echo ""<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " WORKSPACES_DIR = ${WORKSPACES_DIR}"<br />
echo " WORKSPACE_NAME = ${WORKSPACE_NAME}"<br />
echo " REPO = ${REPO}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git clone is $(whoami)"<br />
<br />
# For Debugging<br />
GIT_SSH_COMMAND="ssh" git clone "$REPO" "$WORKSPACES_DIR/$WORKSPACE_NAME"<br />
ret=$?<br />
echo "Clone return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
===pull.sh===<br />
<br />
**Be sure to supply the branch where indicated**<br />
<br />
#!/bin/bash<br />
<br />
BRANCH="BRANCH_NAME"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
echo "=================================================================="<br />
echo ""<br />
echo "Custom Pull Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git pull is $(whoami)"<br />
<br />
# For Debugging<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
GIT_SSH_COMMAND="ssh" git --git-dir="$CLIENT_SOURCE_DIR/.git" --work-tree="$CLIENT_SOURCE_DIR" pull<br />
ret=$?<br />
echo "Pull return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
=== pushfiles.sh ===<br />
<br />
#!/bin/bash<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "CUSTOM_PUSH_FILES (${PUSH_TYPE})"<br />
echo ""<br />
echo "Custom Push Files Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " IMPORT_MESSAGE = ${IMPORT_MESSAGE}"<br />
echo " IMPORT_LIST_PATH = ${IMPORT_LIST_PATH}"<br />
<br />
echo "User running pushfiles is $(whoami)"<br />
<br />
# run script<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
echo "Files to import to the repo are: "<br />
cat "${IMPORT_LIST_PATH}"<br />
while IFS= read -r f; do<br />
git add "$f"<br />
ret=$?<br />
echo "Push add status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
done < "${IMPORT_LIST_PATH}"<br />
git commit -m "${IMPORT_MESSAGE}"<br />
GIT_SSH_COMMAND="ssh" git push <br />
ret2=$?<br />
echo "Push return status $ret2"<br />
if [ $ret2 -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
<br />
== Create a new Custom Data Source ==<br />
<br />
Once the scripts have been created, make the scripts accessible to Command Center by adding the directory as a new Custom Data Source<br />
* When naming the Custom Data Source consider using a name that will make it easily identifiable as to what repository and branch the Custom Data Source is pointing towards.<br />
* There will be one Custom Data source created for a single repo/branch used by Command Center<br />
** If two branches from the same repository are required, there will be two Custom Data Sources Required.<br />
<br />
<br />
== Leveraging the Custom Data Source from Command Center ==<br />
<br />
At this point, when the Command Center Project is created, simply select the Custom Data Source as the Data Source Credential and you should be all set.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Command_Center_SSH_Bitbucket&diff=99180Command Center SSH Bitbucket2025-02-04T15:04:03Z<p>Rwilliams: </p>
<hr />
<div>*clone.sh<br />
**USER_NAME<br />
**REPO<br />
**BRANCH_NAME<br />
*pull.sh<br />
** BRANCH_NAME<br />
*pushfiles.sh<br />
** No modification needed<br />
<br />
Add the contents below to each of the respective files, being sure to<br />
update the user_name/repo/branch where indicated.<br />
<br />
=== clone.sh ===<br />
<br />
**Be sure to supply the USER_NAME, REPO, BRANCH where indicated**<br />
<br />
#!/bin/bash<br />
<br />
REPO="ssh://git@bitbucket.org/<USER_NAME>/<REPO>.git"<br />
BRANCH="BRANCH_NAME"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "Custom Clone Incoming variables:"<br />
echo ""<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " WORKSPACES_DIR = ${WORKSPACES_DIR}"<br />
echo " WORKSPACE_NAME = ${WORKSPACE_NAME}"<br />
echo " REPO = ${REPO}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git clone is $(whoami)"<br />
<br />
# For Debugging<br />
GIT_SSH_COMMAND="ssh" git clone "$REPO" "$WORKSPACES_DIR/$WORKSPACE_NAME"<br />
ret=$?<br />
echo "Clone return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
===pull.sh===<br />
<br />
**Be sure to supply the branch where indicated**<br />
<br />
#!/bin/bash<br />
<br />
BRANCH="BRANCH_NAME"<br />
<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
echo "=================================================================="<br />
echo ""<br />
echo "Custom Pull Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " BRANCH = ${BRANCH}"<br />
<br />
echo "User running git pull is $(whoami)"<br />
<br />
# For Debugging<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
GIT_SSH_COMMAND="ssh" git --git-dir="$CLIENT_SOURCE_DIR/.git" --work-tree="$CLIENT_SOURCE_DIR" pull<br />
ret=$?<br />
echo "Pull return status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
# This use case only occurs when a clone was done prior and the branch was different from the desired one<br />
cur_branch="$(git rev-parse --abbrev-ref HEAD)"<br />
<br />
if [ "${cur_branch}" != "${BRANCH}" ] ; then<br />
echo "Branch was ${cur_branch} so switching to ${BRANCH}"<br />
git switch "${BRANCH}"<br />
else<br />
echo "Branch already at ${cur_branch}, no need to switch "<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
=== pushfiles.sh ===<br />
<br />
#!/bin/bash<br />
echo "Using credential: ${CREDENTIAL_NAME}"<br />
<br />
echo "=================================================================="<br />
echo "CUSTOM_PUSH_FILES (${PUSH_TYPE})"<br />
echo ""<br />
echo "Custom Push Files Incoming variables:"<br />
echo " CUSTOM_DIR = ${CUSTOM_DIR}"<br />
echo " CLIENT_SOURCE_DIR = ${CLIENT_SOURCE_DIR}"<br />
echo " IMPORT_MESSAGE = ${IMPORT_MESSAGE}"<br />
echo " IMPORT_LIST_PATH = ${IMPORT_LIST_PATH}"<br />
<br />
echo "User running pushfiles is $(whoami)"<br />
<br />
# run script<br />
cd "${CLIENT_SOURCE_DIR}" || exit 1<br />
echo "Files to import to the repo are: "<br />
cat "${IMPORT_LIST_PATH}"<br />
while IFS= read -r f; do<br />
git add "$f"<br />
ret=$?<br />
echo "Push add status $ret"<br />
if [ $ret -ne 0 ] ; then<br />
exit 1<br />
fi<br />
done < "${IMPORT_LIST_PATH}"<br />
git commit -m "${IMPORT_MESSAGE}"<br />
GIT_SSH_COMMAND="ssh" git push <br />
ret2=$?<br />
echo "Push return status $ret2"<br />
if [ $ret2 -ne 0 ] ; then<br />
exit 1<br />
fi<br />
<br />
cd ~/ || exit 1<br />
<br />
exit 0<br />
<br />
<br />
=== Create a new Custom Data Source ===<br />
<br />
- Once the scripts have been created, make the scripts accessible to<br />
Command Center by adding the directory as a new Custom Data Source<br />
- When naming the Custom Data Source consider using a name that will<br />
make it easily identifiable as to what repository and branch the<br />
Custom Data Source is pointing towards.<br />
- There will be one Custom Data source created for a single<br />
repo/branch used by Command Center<br />
- If two branches from the same repository are required, there will<br />
be two Custom Data Sources Required.<br />
<br />
<br />
=== Leveraging the Custom Data Source from Command Center ===<br />
<br />
- At this point, when the Command Center Project is created, simply<br />
select the Custom Data Source as the Data Source Credential and you<br />
should be all set.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Scanning_and_Filtering_FAQ&diff=99179Scanning and Filtering FAQ2025-01-30T21:58:23Z<p>Rwilliams: </p>
<hr />
<div>===Can I use Globalyzer to look for issues in my code that have nothing to do with internationalization?===<br />
<br />
Yes. In fact this is quite common. One of the added values that our customers use Globalyzer for is as a repository for regular expression searches, which they can name, describe and share among their company’s developers. See [http://www.globalyzer.com/gzserver/help/usersguide/ruleSets.html#whatAreRuleSets Rule Sets] and scroll down to '''General Pattern Scan Rules''' for more details.<br />
<br />
===Is there support for detecting UI alignment problems?===<br />
<br />
This would be handled adding new General Pattern Rules to your Rule Set that detect fixed widths.<br />
<br />
===What is the difference between the “Ignore” and “Invalid” Status?===<br />
<br />
These status choices can have any meaning, and are just a way to further break up the scan results. That said, we think that the '''Invalid''' status should be used in the cases where the scan detection is not correct. For example, say Globalyzer’s Embedded String scan found a detection that wasn’t a UI embedded string (for example, a programmatic string). In this case, you would set the result to the '''Invalid''' status. The '''Ignore''' status, on the other hand, would be used for embedded strings that do appear in the UI but that you don’t translate, for example, file extensions or program names. The '''TODO''' is another status that you could apply to scan results that you want to deal with at a later time. In the case of the Locale-Sensitive Method scan, you could apply the '''Ignore''' status to results where the method usage is not an issue and use the '''TODO''' status if you want to look at the method later.<br />
<br />
===How does Globalyzer determine whether or not an embedded string is an internationalization issue?===<br />
<br />
During the Embedded String scanning process, Globalyzer will detect all strings in the source code. Then, the Globalyzer filters are used to eliminate the programmatic strings, or strings that would not require translation. So, the scanning work is primarily in filtering out strings, rather than in detecting them.<br />
<br />
=== How are i18n issue priorities set? ===<br />
<br />
Each active issue has a priority. The priority ranges between 1 and 5, 1 being the highest - i.e. the most likely to be an internationalization issue. In addition, Strings can be marked as 'Concatenated', or priority 0. For Locale-Sensitive Methods, Static File References, and General Patterns, the priority is configured in the detection rules of the rule set. For Embedded Strings, priorities can be configured in retention rules, such as String Content Patterns, String Method Patterns, and String Variable Patterns. <br />
<br />
If a string is detected by these rules, the configured priority is assigned to the issue. If not, Globalyzer assigns a priority based on the content of the string. For example, a string containing words found in the dictionary will get a higher priority (more likely to be displayed to the end user and therefore more likely to require externalization) than one with words not found in the dictionary. Other considerations for assigning priorities to Embedded Strings include capitalization and punctuation found in the string. Priorities help focus efforts on the most important active issues.<br />
<br />
==== String Priorities ====<br />
<br />
For strings, here is the algorithm we use to determine priority:<br />
<br />
<b>Priority: 0 / Concatenation</b><br />
<br />
Any string which is not filtered and is concatenated is marked as 0/Concatenated. <br />
<br />
<b>Priority 1:</b><br />
<br />
* if dictionary filtering is ON: <br />
<br />
Note: Dictionary filtering is turned on by default (see Window->Preferences->Globalyzer in the Globalyzer Workbench). <br><br />
Note: Globalyzer comes with its own dictionary. To add words to the dictionary, create a Company dictionary that is used in addition to the Globalyzer dictionary. See [[Scanning_and_Filtering_FAQ#How_can_I_add_words_to_the_dictionary_used_when_scanning.3F | How can I add words to the dictionary used when scanning?]] below for more information.<br />
<br />
all words found in dictionary (one or more words)<br />
and first word character is uppercase (and second character of first word is not uppercase) <br />
and string doesn't contain non word characters (that is, string only contains letters, numbers, and/or white space)<br />
<br />
* if dictionary filter is OFF: <br />
<br />
first word character is upper case (and second character of first word is lowercase) <br />
and string doesn't contain non word characters<br />
<br />
<br />
<br />
<b>Priority 2 (not Priority 1 and):</b><br />
<br />
* if dictionary filtering is ON: <br />
<br />
all words found in dictionary <br />
and first word character is lowercase (i.e. first letter is lowercase) <br />
and number of words is 2 or more <br />
and string doesn't contain non word characters<br />
<br />
OR<br />
<br />
all words found in dictionary <br />
and first word character is uppercase (and second character of first word is lowercase) <br />
and string contains non word characters<br />
<br />
<br />
* if dictionary filter is OFF: <br />
<br />
first word character is lowercase (i.e. first letter is lowercase) <br />
and number of words is >= 2 <br />
and string doesn't contain non word characters<br />
<br />
OR<br />
<br />
first word character is uppercase (and second character of first word is lowercase) <br />
and string contains non word characters<br />
<br />
<b>Priority 3 (not Priority 1, 2 and):</b><br />
<br />
* if dictionary filtering is ON: <br />
<br />
all words found in dictionary (including one word phrase) <br />
and first word character is lower case (i.e. first letter is lowercase) <br />
and string contains non word characters<br />
<br />
* if dictionary filtering is OFF: <br />
<br />
first word character is lower case (i.e. first letter is lowercase) <br />
and string contains non word characters<br />
<br />
<b>Priority 4 (not Priority 1, 2, 3 and):</b><br />
<br />
* if dictionary filter is ON: <br />
<br />
at least one word found in dictionary<br />
and number of words is 2 or more<br />
<br />
<b>Priority 5: not Priority 1, 2, 3, 4</b><br />
<br />
==== Locale-Sensitive Methods Priorities====<br />
<br />
For Locale-Sensitive Methods, General Patterns, and Static File References, our general approach is to assign it a priority 1 if the application could break if the i18n issue isn't addressed. For example, an encoding issue where you would see character corruption. We also assign priority 1 to methods that are likely to have an i18n issue, such as date/time/number formatting methods. We assign as priority 2 or 3 issues which could be addressed later, such a sorting or font issues. These priorities are defaults which can be modified in the rule set.<br />
<br />
===How should I filter false positive issues?=== <br />
<br />
See [[False Positives | False Positives]]<br />
<br />
Two of Globalyzer's main benefits are first in detecting possible internationalization (i18n) issues, and then in helping you hone down that list to only issues that will actually need code modifications to fix. There are three approaches that Globalyzer provides to address false positive issues in your Scan Results:<br />
<br />
1. Add filter rules to your Rule Set so that the next time you scan, Globalyzer will filter out those false positive detections. Since Rule Sets can be shared among team members and applied to any source code, this is a way to make a large scale effect with little effort and is our first recommendation for filtering Scan Results.<br />
<br />
2. Change the Scan Results Status of false positive issues to be '''Invalid''' or '''Ignore'''. The Status settings are stored with the scanning results in Globalyzer's Client database on your local machine, so as long as you don't delete your scan results or modify the source code file significantly, the Status settings will be maintained during subsequent scans. We recommend this approach when there are specific results that you need to filter that don't lend themselves to Rule Set filters, and when developers prefer that you do not modify source code.<br />
<br />
3. The last approach is to use one of the '''Ignore Comment''' options, which modifies the source code, and so is the most permanent resolution. Regardless whether a Rule Set filter is modified or Scan Results are deleted, or the source code file is significantly modified, Globalyzer will detect the ignore comment in the source code and skip over one or more lines of code that contain false positive i18n issues.<br />
<br />
In addition, Globalyzer's Dictionary, enabled by default in the '''Window->Preferences->Globalyzer''' page, helps to filter and prioritize the Embedded Strings that are detected. For example, strings will be filtered if there are no matching Dictionary words. Conversely, depending on the number of matching versus non-matching words as well as other applied heuristics, Globalyzer will set the priority of each Scan Result, which aids in determining which strings will most likely be translatable strings.<br />
<br />
===Can you tell me more about inserting comments in my source code so that Globalyzer does not detect programmatic strings?===<br />
<br />
The following comments can be used to tell Globalyzer some issues are not to be detected:<br />
<br />
1. Use Eclipse style comments: select the rows that you want to ignore in the Scan Results table; Then right-click and choose '''Ignore this Issue'''. Globalyzer will insert comments of the form $NON-NLS-[n]$ at the end of the line, where "n" refers to the nth issue on the line. For example, if there were 2 embedded strings on the line that you wanted to ignore, Globalyzer would insert: $NON-NLS-1$ $NON-NLS-2$ for the two times that you chose '''Ignore this Issue'''.<br />
<br />
4. Ignore '''all''' the issues on a line, choose '''Ignore this Line'''. Globalyzer will insert comments with $NON-NLS-L$ comments at the end of the line. Subsequent scans will ignore the lines with $NON-NLS-L$ comments. <br />
<br />
1. Insert a comment in the source code that indicates the next line does not require scanning. The comment itself is customizable in Globalyzer's project properties setting. By default it is GLOBALYZER_IGNORE_NEXT_LINE.<br />
<br />
2. Skip scanning a block of code by using a comment to start and a comment to end the "skipped block". These comment commands are also customizable. By default, the keywords are: GLOBALYZER_START_IGNORE and GLOBALYZER_END_IGNORE.<br />
<br />
<br />
'''Note''': Globalyzer Workbench also has a way to ignore issues without modifying the source – using the Status setting in the Scan Results view. A Status on the Workbench is local to that Workbench instance. It is no seen by Lite for instance. To move the Status to the Dashboard, use the Dashboard False Positive Workbench function (See [[False Positives | False Positives]] ). As long as the files don’t change too much, the Status will keep track of the issues. If you want to share your Status settings with other team members, you may choose to<br />
* export your Globalyzer Project (with Scan Results checked): they will need to import the project. You will also need to make sure that the Globalyzer Server Rule Sets used by the project are set to '''shared''' so that they're available to the entire team.<br />
* Use Dashboard False Positives to centralize all False Positives on the Dashboard. See the False Positives Synchronization section in the [[False Positives|False Positives]] page.<br />
<br />
=== Could you provide some sense of scanning performance? ===<br />
Performance will depend on the machine running the scans. Lingoport performance tests are geared towards a Continuous Globalization process where a Jenkins type system executes scanning jobs. <br />
The following gives a performance benchmark for a specific machines on the two major operations when running in a Continuous Globalyzer:<br />
* Login in<br />
* Running the scans, with or without rule sets reload<br />
<br />
<pre><br />
Benchmark System Info:<br />
Operating System Name: Windows 8.1<br />
Operating System Type: amd64<br />
Operating System Version: 6.3<br />
Processor Identifier: Intel64 Family 6 Model 58 Stepping 9, GenuineIntel<br />
Number of Processors: 4<br />
Available processors (cores): 4<br />
Free memory (bytes): 79497416<br />
Maximum memory (bytes): 1407713280<br />
Total memory (bytes): 94896128<br />
Number of Rule Sets: 10<br />
<br />
Login Benchmark: 559 milliseconds<br />
Login Benchmark: 324 milliseconds<br />
Login Benchmark: 336 milliseconds<br />
Login Benchmark: 313 milliseconds<br />
Login Benchmark: 307 milliseconds<br />
Login Benchmark: 306 milliseconds<br />
Login Benchmark: 313 milliseconds<br />
Login Benchmark: 300 milliseconds<br />
Login Benchmark: 303 milliseconds<br />
Login Benchmark: 290 milliseconds<br />
<br />
<br />
Execute Java Scan Benchmark (927 lines of code, 9 files, 190 active results):<br />
Reloaded rule sets<br />
Executing java scan: 2073 milliseconds<br />
Executing java scan: 746 milliseconds<br />
Executing java scan: 557 milliseconds<br />
Executing java scan: 553 milliseconds<br />
Executing java scan: 533 milliseconds<br />
Executing java scan: 541 milliseconds<br />
Executing java scan: 520 milliseconds<br />
Executing java scan: 513 milliseconds<br />
Executing java scan: 524 milliseconds<br />
Executing java scan: 516 milliseconds<br />
Reloaded rule sets<br />
Executing java scan: 652 milliseconds<br />
Executing java scan: 574 milliseconds<br />
Executing java scan: 526 milliseconds<br />
Executing java scan: 493 milliseconds<br />
Executing java scan: 488 milliseconds<br />
Executing java scan: 499 milliseconds<br />
Executing java scan: 486 milliseconds<br />
Executing java scan: 481 milliseconds<br />
Executing java scan: 475 milliseconds<br />
Executing java scan: 470 milliseconds<br />
Reloaded rule sets<br />
Executing java scan: 611 milliseconds<br />
Executing java scan: 478 milliseconds<br />
Executing java scan: 465 milliseconds<br />
Executing java scan: 472 milliseconds<br />
Executing java scan: 464 milliseconds<br />
Executing java scan: 483 milliseconds<br />
Executing java scan: 469 milliseconds<br />
Executing java scan: 455 milliseconds<br />
Executing java scan: 459 milliseconds<br />
Executing java scan: 459 milliseconds<br />
</pre><br />
<br />
=== How can I scan code written in programming languages Globalyzer does not support out of the box?===<br />
Globalyzer provides a set of internationalization rules in support of the main programming languages. In case your code is written in a language that is not part of the out of the box rules, you can do the following:<br />
* Call Lingoport to include a new set of rules for you: This may or may not be a consulting effort by Lingoport<br />
* Find a supported programming language whose constructs are close to your own and create your own rule set. To do so, please visit the [[Scanning_Unsupported_Languages | Scanning Unsupported Languages ]] page.<br />
<br />
<br />
=== How can I add words to the dictionary used when scanning?===<br />
If the preference <b>Filter Strings without Dictionary Words</b> is checked (see Window->Preferences->Globalyzer), Globalyzer will automatically filter strings that<br />
contain no dictionary words. That is, the string itself is parsed into words, and if none of the words are found in the dictionary, the string is filtered. If at least one of the words is found in the dictionary, the string is potentially active. <br />
<br />
The dictionary is maintained by Lingoport. If there are words you would like added to the dictionary, you can create a Company Dictionary on the Globalyzer Server and add words to that. There is one Company Dictionary per company, so all users in the company will see the same dictionary. <br />
<br />
To add words to the Company Dictionary, download the dictionary file from the Globalyzer Server, modify the file locally (one word per line), and then upload the dictionary file to the Server. <br />
<br />
To use your Company Dictionary for scanning, download the dictionary file from the Server and place in your Lingoport directory (C:\Lingoport on Windows, $HOME/lingoport on Linux, and /Applications/Lingoport on Mac). When scanning, Globalyzer will consider words in both the Lingoport Dictionary and your Company Dictionary.<br />
<br />
=== Are there any heuristics that can be applied to the priorities and how to set them? ===<br />
In cases where a there are a large number of results being returned one approach is to try using C and P1 only initially and see if that makes it easier to find and correct the higher priority items. Adjust the sensitivity based upon what is being seen in the detection output. Once those have been addressed its possible to make additional passes including P2-P5 enabled to look for the lower priority items. In general when enabling the P2-P5, there may be an increase of false positives due to the sensitivity being increased, however eliminating them in entirety can mean that true positives could be missed. That is why the stepped approach has proven effective in many cases. Correct the "low hanging fruit" initially and then go back and dig for the harder to identify items.<br />
<br />
Globalyzer identifies items that that look suspect but ultimately it will be up to the developer in some cases to determine if its really an issue based upon their knowledge and the context in the code. As you get closer to P5 the developer input will increase as the detection is getting more sensitive.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Custom_Git_Data_Source_Credential&diff=99075Custom Git Data Source Credential2025-01-07T18:23:00Z<p>Rwilliams: /* Bitbucket / Custom Git */</p>
<hr />
<div>= Bitbucket / Custom Git =<br />
[Administrator]<br />
<br />
For special git repositories, such as Bitbucket, use Custom Git. It provides flexibility for special Git systems.<br />
<br />
'''Bitbucket PAT Creation Notes'''<br />
<br />
Bitbucket allows PATs to be created at the Project or the Repository level. In this description the PAT was created at the repository level<br />
<br />
* Within the Bitbucket repository, go to Repository Settings -> Access Tokens select Create Repository Access Token <br />
[[File:BitbucketPATCreationForm.jpg|400px]]<br />
<br />
* Give the token a name that can be easily identified<br />
* Select the scopes of Read/Write/Delete<br />
* Press Create<br />
<br />
There should be a new screen that appears showing the newly created PAT and the various ways to leverage it. Be sure to save the contents of this screen as everything but the email user.email section will no longer be visible once closed.<br />
<br />
The sections that are of most importance have been marked in red. These will be referenced later when filling out the configuration in Command Center. They are, from top to bottom:<br />
* Repository access token<br />
* How to use this token with your Git Repository<br />
* The git config user.email<br />
<br />
[[File:BitbucketPATCreationDetails.jpg|400px]]<br />
<br />
Now that the PAT has been created, it can be incorporated into Command Center as follows.<br />
<br />
'''Create a new Data Source Credential'''<br />
* Open the Settings section (Gear Icon) from the Dashboard page<br />
* Select "Maintenance Mode" (Must be an Administrator to do this) to unlock the Data Source Credentials area<br />
* Select the Data Source Credentials<br />
* Selecti the [[File:CreateIcon.jpg|30px]] ('''Create new credential''') button on the Manage Data Source Credentials page. <br />
<br />
'''Select the Custom Git card'''<br />
<br />
[[File:BitbucketCard.jpg|100px]] <br />
<br />
'''The Custom Git Connection Form will open'''<br />
<br />
[[File:BitbucketGitCredentials.jpg|800px]]<br />
<br />
'''Enter the details for the Custom Git Form'''<br />
* Enter a Username.<br />
** The username will be x-token-auth as provided by Bitbucket as part of the git clone URL when the PAT was initially created. This can be found in the "How to use this token with your Git Repository" when the PAT was created marked in red in the screenshot prior.<br />
** Its from here: ''git clone https://'''x-token-auth''':<PAT>@bitbucket.org/<ACCOUNT>/<REPO>.git''<br />
* Enter the Personal access token<br />
** The PAT is the Token itself as provided by Bitbucket in the top text box marked in red in the screenshot prior marked as "Repository Access Token". This is the PAT itself.<br />
* Enter the Commit author - You can put whatever you wish here<br />
* Enter the Commit email<br />
** If the Bitbucket provided user.email is input here, when commits occur from Command Center, within Bitbucket commits from Command Center will show as the token name provided when the PAT was created in Bitbucket. This is the "git config user.email" token marked in red in the screenshot prior.<br />
* Enter the Git server URL, for example, ''https://bitbucket.org/account/'' <br />
* '''Next'''<br />
<br />
[[File:BitbucketCredentialName.jpg|800px]]<br />
<br />
'''Give the new credential a name'''<br />
* The name should be something that is easily identified when applied from a project as the being the correct PAT<br />
* Assign it to applicable managers<br />
* '''Create'''<br />
<br />
The system should return to the '''Manage Data Source Credentials''' page with "Credential created" note and the new credential should be listed.<br />
<br />
At this point, this credential can be added to a project in the same manner as any other source credential.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Custom_Git_Data_Source_Credential&diff=99074Custom Git Data Source Credential2025-01-07T18:01:23Z<p>Rwilliams: /* Bitbucket / Custom Git */</p>
<hr />
<div>= Bitbucket / Custom Git =<br />
[Administrator]<br />
<br />
For special git repositories, such as Bitbucket, use Custom Git. It provides flexibility for special Git systems.<br />
<br />
'''Bitbucket PAT Creation Notes'''<br />
<br />
Bitbucket allows PATs to be created at the Project or the Repository level. In this description the PAT was created at the repository level<br />
<br />
* Within the Bitbucket repository, go to Repository Settings -> Access Tokens select Create Repository Access Token <br />
[[File:BitbucketPATCreationForm.jpg|400px]]<br />
<br />
* Give the token a name that can be easily identified<br />
* Select the scopes of Read/Write/Delete<br />
* Press Create<br />
<br />
There should be a new screen that appears showing the newly created PAT and the various ways to leverage it. Be sure to save the contents of this screen as everything but the email user.email section will no longer be visible once closed.<br />
<br />
The sections that are of most importance have been marked in red. These will be referenced later when filling out the configuration in Command Center. They are, from top to bottom:<br />
* Repository access token<br />
* How to use this token with your Git Repository<br />
* The git config user.email<br />
<br />
[[File:BitbucketPATCreationDetails.jpg|400px]]<br />
<br />
Now that the PAT has been created, it can be incorporated into Command Center as follows.<br />
<br />
'''Create a new Data Source Credential'''<br />
* Open the Settings section (Gear Icon) from the Dashboard page<br />
* Select "Maintenance Mode" (Must be an Administrator to do this) to unlock the Data Source Credentials area<br />
* Select the Data Source Credentials<br />
* Selecti the [[File:CreateIcon.jpg|30px]] ('''Create new credential''') button on the Manage Data Source Credentials page. <br />
<br />
'''Select the Custom Git card'''<br />
<br />
[[File:BitbucketCard.jpg|100px]] <br />
<br />
'''The Custom Git Connection Form will open'''<br />
<br />
[[File:BitbucketGitCredentials.jpg|800px]]<br />
<br />
'''Enter the details for the Custom Git Form'''<br />
* Enter a Username.<br />
** The username will be x-token-auth as provided by Bitbucket as part of the git clone URL when the PAT was initially created. This can be found in the "How to use this token with your Git Repository" when the PAT was created marked in red in the screenshot prior.<br />
* Enter the Personal access token<br />
** The PAT is the Token itself as provided by Bitbucket in the top text box marked in red in the screenshot prior marked as "Repository Access Token". This is the PAT itself.<br />
* Enter the Commit author - You can put whatever you wish here<br />
* Enter the Commit email<br />
** If the Bitbucket provided user.email is input here, when commits occur from Command Center, within Bitbucket commits from Command Center will show as the token name provided when the PAT was created in Bitbucket. This is the "git config user.email" token marked in red in the screenshot prior.<br />
* Enter the Git server URL, for example, ''https://bitbucket.org/account/'' <br />
* '''Next'''<br />
<br />
[[File:BitbucketCredentialName.jpg|800px]]<br />
<br />
'''Give the new credential a name'''<br />
* The name should be something that is easily identified when applied from a project as the being the correct PAT<br />
* Assign it to applicable managers<br />
* '''Create'''<br />
<br />
The system should return to the '''Manage Data Source Credentials''' page with "Credential created" note and the new credential should be listed.<br />
<br />
At this point, this credential can be added to a project in the same manner as any other source credential.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Custom_Git_Data_Source_Credential&diff=99065Custom Git Data Source Credential2025-01-07T17:16:38Z<p>Rwilliams: /* Bitbucket / Custom Git */</p>
<hr />
<div>= Bitbucket / Custom Git =<br />
[Administrator]<br />
<br />
For special git repositories, such as Bitbucket, use Custom Git. It provides flexibility for special Git systems.<br />
<br />
'''Bitbucket PAT Creation Notes'''<br />
<br />
Bitbucket allows PATs to be created at the Project or the Repository level. In this description the PAT was created at the repository level<br />
<br />
* Within the Bitbucket repository, go to Repository Settings -> Access Tokens select Create Repository Access Token <br />
[[File:BitbucketPATCreationForm.jpg|400px]]<br />
<br />
* Give the token a name that can be easily identified<br />
* Select the scopes of Read/Write/Delete<br />
* Press Create<br />
<br />
There should be a new screen that appears showing the newly created PAT and the various ways to leverage it. Be sure to save the contents of this screen as everything but the email user.email section will no longer be visible once closed.<br />
<br />
The sections that are of importance have been marked in red. These will be referenced later when filling out the configuration in Command Center. They are, from top to bottom:<br />
* Repository access token<br />
* How to use this token with your Git Repository<br />
* The git config user.email<br />
<br />
[[File:BitbucketPATCreationDetails.jpg|400px]]<br />
<br />
Now that the PAT has been created, it can be incorporated into Command Center as follows.<br />
<br />
'''Create a new Data Source Credential'''<br />
* Open the Settings section (Gear Icon) from the Dashboard page<br />
* Select "Maintenance Mode" (Must be an Administrator to do this) to unlock the Data Source Credentials area<br />
* Select the Data Source Credentials<br />
* Selecti the [[File:CreateIcon.jpg|30px]] ('''Create new credential''') button on the Manage Data Source Credentials page. <br />
<br />
'''Select the Custom Git card'''<br />
<br />
[[File:BitbucketCard.jpg|100px]] <br />
<br />
'''The Custom Git Connection Form will open'''<br />
<br />
[[File:BitbucketGitCredentials.jpg|800px]]<br />
<br />
'''Enter the details for the Custom Git Form'''<br />
* Enter a Username.<br />
** The username will be x-token-auth as provided by Bitbucket as part of the git clone URL when the PAT was initially created. This can be found in the "How to use this token with your Git Repository" when the PAT was created marked in red in the screenshot prior.<br />
* Enter the Personal access token<br />
** The PAT is the Token itself as provided by Bitbucket in the top text box marked in red in the screenshot prior marked as "Repository Access Token". This is the PAT itself.<br />
* Enter the Commit author - You can put whatever you wish here<br />
* Enter the Commit email<br />
** If the Bitbucket provided user.email is input here, when commits occur from Command Center, within Bitbucket commits from Command Center will show as the token name provided when the PAT was created in Bitbucket. This is the "git config user.email" token marked in red in the screenshot prior.<br />
* Enter the Git server URL, for example, ''https://bitbucket.org/account/'' <br />
* '''Next'''<br />
<br />
[[File:BitbucketCredentialName.jpg|800px]]<br />
<br />
'''Give the new credential a name'''<br />
* The name should be something that is easily identified when applied from a project as the being the correct PAT<br />
* Assign it to applicable managers<br />
* '''Create'''<br />
<br />
The system should return to the '''Manage Data Source Credentials''' page with "Credential created" note and the new credential should be listed.<br />
<br />
At this point, this credential can be added to a project in the same manner as any other source credential.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Custom_Git_Data_Source_Credential&diff=99064Custom Git Data Source Credential2025-01-07T17:14:55Z<p>Rwilliams: /* Bitbucket / Custom Git */</p>
<hr />
<div>= Bitbucket / Custom Git =<br />
[Administrator]<br />
<br />
For special git repositories, such as Bitbucket, use Custom Git. It provides flexibility for special Git systems.<br />
<br />
'''Bitbucket PAT Creation Notes'''<br />
<br />
Bitbucket allows PATs to be created at the Project or the Repository level. In this description the PAT was created at the repository level<br />
<br />
* Within the Bitbucket repository, go to Repository Settings -> Access Tokens select Create Repository Access Token <br />
[[File:BitbucketPATCreationForm.jpg|400px]]<br />
<br />
* Give the token a name that can be easily identified<br />
* Select the scopes of Read/Write/Delete<br />
* Press Create<br />
<br />
There should be a new screen that appears showing the newly created PAT and the various ways to leverage it. Be sure to save the contents of this screen as everything but the email user.email section will no longer be visible once closed.<br />
<br />
The sections that are of importance have been marked in red. These will be referenced later when filling out the configuration in Command Center. They are, from top to bottom:<br />
* Repository access token<br />
* How to use this token with your Git Repository<br />
* The git config user.email<br />
<br />
[[File:BitbucketPATCreationDetails.jpg|400px]]<br />
<br />
Now that the PAT has been created, it can be incorporated into Command Center as follows.<br />
<br />
'''Create a new Data Source Credential'''<br />
* Open the Settings section (Gear Icon) from the Dashboard page<br />
* Select "Maintenance Mode" (Must be an Administrator to do this) to unlock the Data Source Credentials area<br />
* Select the Data Source Credentials<br />
* Selecti the [[File:CreateIcon.jpg|30px]] ('''Create new credential''') button on the Manage Data Source Credentials page. <br />
<br />
'''Select the Custom Git card'''<br />
<br />
[[File:BitbucketCard.jpg|100px]] <br />
<br />
'''The Custom Git Connection Form will open'''<br />
<br />
[[File:BitbucketGitCredentials.jpg|800px]]<br />
<br />
'''Enter the details for the Custom Git Form'''<br />
* Enter a Username.<br />
** The username will be x-token-auth as provided by Bitbucket as part of the git clone URL when the PAT was initially created. This can be found in the "How to use this token with your Git Repository" when the PAT was created marked in red in the screenshot prior.<br />
* Enter the Personal access token<br />
** The PAT is the Token itself as provided by Bitbucket in the top text box marked in red in the screenshot prior marked as "Repository Access Token". This is the PAT itself.<br />
* Enter the Commit author - You can put whatever you wish here<br />
* Enter the Commit email<br />
** If the Bitbucket provided user.email is input here, when commits occur from Command Center, they will show in Bitbucket with a commit author as token name provided when the PAT was created in Bitbucket. This is the "git config user.email" token marked in red in the screenshot prior.<br />
* Enter the Git server URL, for example, ''https://bitbucket.org/account/'' <br />
* '''Next'''<br />
<br />
[[File:BitbucketCredentialName.jpg|800px]]<br />
<br />
'''Give the new credential a name'''<br />
* The name should be something that is easily identified when applied from a project as the being the correct PAT<br />
* Assign it to applicable managers<br />
* '''Create'''<br />
<br />
The system should return to the '''Manage Data Source Credentials''' page with "Credential created" note and the new credential should be listed.<br />
<br />
At this point, this credential can be added to a project in the same manner as any other source credential.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=File:BitbucketCredentialName.jpg&diff=99061File:BitbucketCredentialName.jpg2025-01-07T17:13:15Z<p>Rwilliams: </p>
<hr />
<div></div>Rwilliamshttps://wiki.lingoport.com/index.php?title=File:BitbucketGitCredentials.jpg&diff=99055File:BitbucketGitCredentials.jpg2025-01-07T16:58:27Z<p>Rwilliams: </p>
<hr />
<div></div>Rwilliamshttps://wiki.lingoport.com/index.php?title=File:BitbucketPATCreationDetails.jpg&diff=99048File:BitbucketPATCreationDetails.jpg2025-01-07T16:44:17Z<p>Rwilliams: </p>
<hr />
<div></div>Rwilliamshttps://wiki.lingoport.com/index.php?title=File:BitbucketPATCreationForm.jpg&diff=99047File:BitbucketPATCreationForm.jpg2025-01-07T16:41:23Z<p>Rwilliams: </p>
<hr />
<div></div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Custom_Git_Data_Source_Credential&diff=99043Custom Git Data Source Credential2025-01-07T15:09:05Z<p>Rwilliams: /* Bitbucket / Custom Git */</p>
<hr />
<div>= Bitbucket / Custom Git =<br />
[Administrator]<br />
<br />
For special git repositories, such as Bitbucket, use Custom Git. It provides flexibility for special Git systems.<br />
<br />
'''Bitbucket PAT Creation Notes'''<br />
<br />
Bitbucket allows PATs to be created at the Project or the Repository level. In this description the PAT was created at the repository level<br />
<br />
* Within the Bitbucket repository, go to Repository Settings -> Access Tokens select Create Repository Access Token <br />
[[File:BitbucketPATCreationForm.jpg|600px]]<br />
* Give the token a name that can be easily identified<br />
* Select the scopes of Read/Write/Delete<br />
* Press Create<br />
<br />
There should be a new screen that appears showing the newly created PAT and the various ways to leverage it. Be sure to save the contents of this screen as everything but the email user.email section will no longer be visible once closed.<br />
<br />
[[File:BitbucketPATCreationDetails.jpg|600px]]<br />
<br />
The Administrator can create the data source credentials by selecting the [[File:CreateIcon.jpg|30px]] ('''Create new credential''') button on the Manage Data Source Credentials page. <br />
<br />
'''Select the Custom Git card'''<br />
<br />
[[File:BitbucketCard.jpg|100px]] <br />
<br />
'''The Custom Git Connection Form will open'''<br />
<br />
[[File:BitbucketUsername.jpg|600px]]<br />
<br />
'''Enter the details for the Custom Git Form'''<br />
* Enter a Username.<br />
** The username will be x-token-auth as provided by Bitbucket as part of the git clone URL provided by Bitbucket when the PAT was initially created.<br />
* Enter the Personal access token<br />
** The PAT is the Token itself as provided by Bitbucket in the first text box that was created by the Bitbucket service. Be sure not to add the username portion or the @<URL> portion to this.<br />
* Enter the Commit author<br />
* Enter the Commit email<br />
** If the Bitbucket provided user.email is input here, when commits occur from Command Center, they will show in Bitbucket with a commit author as token name provided when the PAT was created in Bitbucket<br />
* Enter the URL, for example, ''https://bitbucket.org/account/'' <br />
* '''Next'''<br />
[[File:BitbucketGitCredentials.jpg|600px]]<br />
<br />
'''Give the new credential a name'''<br />
* The name should be something that is easily identified when applied from a project as the being the correct PAT<br />
* Assign it to applicable managers<br />
* '''Create'''<br />
<br />
[[File:BitbucketCredentialName.jpg|600px]]<br />
<br />
The system should return to the '''Manage Data Source Credentials''' page with "Credential created" note and the new credential should be listed.</div>Rwilliamshttps://wiki.lingoport.com/index.php?title=Custom_Git_Data_Source_Credential&diff=99042Custom Git Data Source Credential2025-01-07T15:06:00Z<p>Rwilliams: /* Bitbucket / Custom Git */</p>
<hr />
<div>= Bitbucket / Custom Git =<br />
[Administrator]<br />
<br />
For special git repositories, such as Bitbucket, use Custom Git. It provides flexibility for special Git systems.<br />
<br />
'''Bitbucket PAT Creation Notes'''<br />
<br />
Bitbucket allows PATs to be created at the Project or the Repository level. In this description the PAT was created at the repository level<br />
<br />
* Within the Bitbucket repository, go to Repository Settings -> Access Tokens select Create Repository Access Token <br />
[[File:BitbucketPATCreationForm.jpg|600px]]<br />
* Give the token a name that can be easily identified<br />
* Select the scopes of Read/Write/Delete<br />
* Press Create<br />
<br />
There should be a new screen that appears showing the newly created PAT and the various ways to leverage it. Be sure to save the contents of this screen as everything but the email user.email section will no longer be visible once closed.<br />
<br />
[[File:BitbucketPATCreationDetails.jpg|600px]]<br />
<br />
The Administrator can create the data source credentials by selecting the [[File:CreateIcon.jpg|30px]] ('''Create new credential''') button on the Manage Data Source Credentials page. <br />
<br />
'''Select the Custom Git card'''<br />
<br />
[[File:BitbucketCard.jpg|100px]] <br />
<br />
[[File:BitbucketUsername.jpg|600px]]<br />
<br />
'''Enter the details for the Custom Git Form'''<br />
* Enter a Username.<br />
** The username will be x-token-auth as provided by Bitbucket as part of the git clone URL provided by Bitbucket when the PAT was initially created.<br />
* Enter the Personal access token<br />
** The PAT is the Token itself as provided by Bitbucket in the first text box that was created by the Bitbucket service. Be sure not to add the username portion or the @<URL> portion to this.<br />
* Enter the Commit author<br />
* Enter the Commit email<br />
** If the Bitbucket provided user.email is input here, when commits occur from Command Center, they will show in Bitbucket with a commit author as token name provided when the PAT was created in Bitbucket<br />
* Enter the URL, for example, ''https://bitbucket.org/account/'' <br />
* '''Next'''<br />
[[File:BitbucketGitCredentials.jpg|600px]]<br />
<br />
'''Give the new credential a name'''<br />
* The name should be something that is easily identified when applied from a project as the being the correct PAT<br />
* Assign it to applicable managers<br />
* '''Create'''<br />
<br />
[[File:BitbucketCredentialName.jpg|600px]]<br />
<br />
The system should return to the '''Manage Data Source Credentials''' page with "Credential created" note and the new credential should be listed.</div>Rwilliams