- Where To Start?
- Workspace Settings
- Local Repository Cache
- Workspace Editor
- Unable to connect to port 22 (SSH Protocol)
CET Developer: Git Workspace Editor is a tool for creating and editing workspaces within CET Operator. A workspace is a set of references to different branches/versions on the packages included in the workspace. The Workspace Editor can be opened by pressing the Add Git Workspace or the Edit button in CET Operator.
Where To Start?
- Start by clicking Add Git Workspace at the bottom of CET Operator to bring up the Git Workspace Editor.
- The first time you open the Workspace Editor, it will not list any repositories because you have not yet specified an access token. An access token is used to uniquely identify you when the GitLab server is called, whenever an access token is used on a new machine, GitLab will send an email notifying you of its use. Clicking the red link will bring up your web browser where you can log in to your GitLab account and generate a token.
If you do not yet have a GitLab account, or don’t know your login credentials, please contact Developer Support.
- You should now find yourself on the Personal Access Tokens page on GitLab. Fill out a name for your token (any name is ok, for example "cetdev"), check all the checkboxes under Scopes and lastly click the button to create your personal access token.
- Click the button next to the generated access token to copy it to the Windows clipboard. Then paste it into the Private Token field in the Git Workspace Editor. Click Refresh from Server to log in and view a list of the repos that you have access to.
Your list should show the base-repo (where CET core, Abstract and Utility Extensions are located) and any custom repos that you are a developer for, check the repos you want to include and click Save. Then, answer Yes on the question to get the files for the workspace.
The Workspace settings section allows you to update the settings of your workspace. You need to specify the workspace name and the workspace local path when creating the workspace. The ability to assign names gives you the possibility to have several workspaces on the same core version. For example, having a branch that needs the latest base code, and a branch that only uses the current publicly released base code.
You can also specify where the workspace is located by changing the field Workspace Folder.
To set the workspace as a Build workspace, check the checkbox Use for Build. If a workspace is defined as a Build workspace, it will automatically be synced with the latest changes when building from the workspace.
Local Repository Cache
If you have another workspace and you already have a similar workspace on your computer you can choose to use a cached repository. It will check the size of the cached file and decides whether or not it needs to fetch the repository from the server or if it can use the cache. In the case that the file size on the server differs by more than 2%, the operator will fetch from the server. Otherwise, it uses the cached file.
In the Workspace Editor, the existing packages are divided into Custom Extensions and Other Repos. The categories are used to filter what you can see in the main view of the Workspace Editor. There is also a tab for showing all available packages. All the new custom extensions will be added under the tab Custom Extensions.
To add a package to the workspace, enable the checkbox to the left of the package name. When adding a new package to the workspace it is important to update the branch/version and the label/changelist to the correct settings for the workspace. The branch/version setting is defaulted to the version closest to the core version of the workspace. The label/changelist setting has two default settings – Latest recommended and Latest submitted. When choosing one of the two you will automatically be synced to the best label for that setting. If a manual label is created for the package it is also possible to sync against that label.
The branch/version setting for the core package can only be set when creating the workspace. If the branch/version setting is updated to a new version the update will be propagated to all other packages as well.
Unable to connect to port 22 (SSH Protocol)
If there is any trouble relating to being unable to pull from port 22 the dialog will report errors.
This might be because of the user's router settings are blocking port 22(SSH), which is the default port we use. In this case, we have to change to use a different port, namely using port 443(HTTPS/SSL). To do this, go to Setup in CET Developer, and then press the Git Settings button. Set UseHttpsForGitRepos to true: