Page History
...
This enablement pack will trigger the WST deployment process via the command line. For further information on this, please refer to the WhereScape RED help guide.
Machine Configuration
All deployment machines must have the same configuration and installation steps in the prerequisites section.
Configure Target Environment Runners
To deploy the application to target environments, the below link provides instructions to configure a self-hosted runner as a service.
For more information consult the documentation here: GitHub - Hosting your Own Runners
Consideration when Setting up Agents/Runners
It is recommended that you consider this before continuing or selecting the option.
Option1: Create a runner per deployment machine
This will enable the machine to be configured specifically for that runner and the required deployment tasks. For example, you may require specific software for that runner.
However, this will create a more complex environment to support and may also be more cost-inefficient.
Option 2: You can create many runners within one deployment machine
This will enable the runners to utilize the setup of the deployment machine environment configuration for many runners.
When creating the agents or runners, include the solution name within the name of the runner, for example: [Machine Name]_[Project]_[Environment]
Your selected option depends on how complex you wish to make the environment. Having one deployment machine with many runners may be simpler to support and more cost-effective in the long run. However, this may create an environmental configuration restriction that may prevent you from scaling the solution in the future.
Also, you should understand the CPU requirements for deployment, as the deployment machine will use the CPU while executing the deployment to the target platform. This is only a consideration if you have many runners on a single deployment machine and, therefore, parallel tasks taking place that are trying to consume the CPU from that deployment machine.
Workflow Logs
When you run the WhereScape GIT Enablement Pack all workflow logs will automatically be created within the following folder:
%USERPROFILE%\WhereScape\GIT\Logs
Whenever you run a workflow task, the user can access these logs to see information relating to them.
| Note | ||
|---|---|---|
| ||
If this folder is used, please ensure that the user profiles have read/write permissions. Failure to do this will prevent the workflow tasks from working correctly. |
WhereScape 3d, RED & GIT Naming Convention
When you create a repository in WhereScape 3D or RED, its name is automatically linked to the name of your GIT repository.
| Warning | ||
|---|---|---|
| ||
If you rename your WhereScape 3D or RED repository later, it will break the connection to your GIT repository and the CI/CD configuration files. This can cause issues with version control and automated deployments. |
Don’t create new repositories in WhereScape 3D that point to existing ones already set up for CI/CD.
Firewall Rules and Proxy Configuration
- Your Git Repository. This can include dev.azure.com, github.com
- GitHub API: api.github.com
- For Git Enterprise users: https://[url]/api/v3/user/repos
| Note | ||
|---|---|---|
| ||
Please note, that some organisations using proxy servers, may need to run the following git command:
|