PowerBuilder and Git Configuration and Procedures

Install Git

https://github.com/git-for-windows/git/releases/download/v2.35.3.windows.1/Git-2.35.3-64-bit.exe

Install GitHub Desktop

GitHub Desktop | Simple collaboration from your desktop

Add a workspace to Git

Only the first user does this to add the PowerBuilder workspace to Git repo. If the repo is already in Azure DevOps, skip to the “Get a workspace from Git” step.
When PowerBuilder IDE opens without loading any workspace, you can get a PowerBuilder workspace from the source control system and open the workspace in the PowerBuilder IDE directly.

1. Right-click the workspace in the System Tree and select Add to Source Control from the pop-up menu.

2. In the Add to Source Control dialog box, select Git as the source control provider for the current workspace and click OK.

3. In the Author Information dialog box, input the author name and author email.

4. After clicking OK, the Add to Source Control dialog box displays listing all the files for the workspace that are not currently under source control. You cannot add files that are already under source control.

 A ws_objects sub-folder is automatically created under the workspace, for managing the source code file of the PowerBuilder objects such as .srw (for window), .srm (for menu), .sru (for user object), .srd (for DataWindow), etc. ws_objects must be added to source code, to manage the source code at object level.

5. In the Add to Source Control dialog box, select the files and folders (especially ws_objects) and click OK.

PowerBuilder adds the selected files and folders to the repository on your local computer. After the file or folder is added to the local repository, the object in the PowerBuilder System Tree will be marked with a green dot in front of it, indicating that its source code file on the local computer is in sync with the file on the local repository. Now you can proceed to push the objects from the local repository to the remote repository on the Git source control server.

 6. Right-click the workspace in the System Tree and select Git Push from the pop-up menu.

7. In the Git Login dialog box, input the information required by the source control system. If the login information has been input before, it will be filled in automatically.

Input the URL of the Git server and the repository for the workspace. Make sure the repository with the same name exists on the server and the repository is empty before you push the files.

The name of the current workspace is automatically displayed.

Type in your username and password for the Git source control system.

Click Test Connection to make sure connection is successful and then click OK.

Change origin branch to ‘dev’ instead of ‘master’ in Git

This is Done after adding a PowerBuilder workspace to Git Repo.

PowerBuilder creates master, but according to DevOps principles it is advised to use “main” as the origin branch. We will use NACIS as an example in this document

1. Go to the DevOps Repo

NACIS-SINCA-POWERBUILDER - Repos (azure.com)

2. Go to “Branches” on the left menu.

3. Delete “main” (if one already exists).

4. Create “main” from “master”.

5. Delete “master”.

 6. Repeat step 4 to create “dev” from “main”

7. Set “dev” as default branch

 8. In PowerBuilder Perform a Git Pull request

9. Switch Branch in PowerBuilder to “dev” by right mouse click on workspace and selecting “Switch Branch”

Get a workspace from Git

When PowerBuilder IDE opens without loading any workspace, you can get a PowerBuilder workspace from the source control system and open the workspace in the PowerBuilder IDE directly.

We will use FTAE – PowerBuilder as the example

To get a PowerBuilder workspace from the Git source control system:

1. Right-click “No Workspace” in the System Tree and select Connect to Workspace from the pop-up menu

or

Select “Connect to Workspace” from the File menu.

The “Connect to Workspace” dialog box displays. If the login information has been input before, it will be filled in automatically.

2. Select “Git' from the “Source Control System” list.

3. Go to the Git repository location FTAE-FVEA-POWERBUILDER - Repos (azure.com)

4. Click on the “Clone” button. The “clone” fly-out will appear.

Copy the URL (You can click on the copy button)

5. Paste or input the URL of the Git source control location in the PB Source Control dialog window.

6. Input the Workspace File name for this application xxx.pbw (In this case ftae.pbw)

7. Click on “Generate Git Credentials” in the Git Clone pop-up

Copy username and then password and paste in in the PB Source Control dialog window.

8. Add Local Settings

a. Checkout Directory (The directory for your local repository) It is advised to create a main directory for Local Git and a separate sub-directory for each application (i.e. C:\Local Git\FTAE\Source)

b. Author Name (Your name)

c. Author Email (Your TC e-mail address)

9. Click “Test Connection” to verify the settings are correct

10. Click “OK” when the connection is successful.
PowerBuilder will start downloading the workspace from the Git source control system, and after the workspace is successfully downloaded, it will be loaded in the PowerBuilder IDE automatically.

11. Perform a “Git Pull”

12. Switch Branch in PowerBuilder to “dev” by right mouse click on workspace and selecting “Switch Branch”

Select a utility for object comparison

1. Right-click the workspace in the “System Tree” and select “Properties” from the pop-up menu.

2. In the “Properties of Workspace” dialog box, select the “Source Control” tab, and then click the “Advanced” button.

3. In the “Source Control Advanced Settings” dialog box, select “Diff Viewer” in the left panel, then select the tool name from the list, specify the executable program of the tool, and change the arguments if necessary.

4. Click “OK”

Make Changes to objects in PowerBuilder

1. Create a working branch in DevOps from “dev”

a. The branch naming convention is “[features OR bugs]/[user name]/[pbi number]-short-desc”. Use lower case, no spaces, and hyphens to connect words in a sentence.

b. Optional - link it to the Work Item for reference

2. Perform a “Git Pull”

3. Switch the branch to the newly created working branch

 4. In case it doesn’t work properly, switch branches using GitHub, instead

5. Perform a “Refresh” in PowerBuilder

There is no checkout process using Git as you are using your local Repo. Just open an object and save it. After changes are made, a green checkmark will appear, instead of the green dot, indicating that it has been modified and is not yet committed.

BEFORE CHANGE

AFTER CHANGE

Commit Changed objects to Local Git Repository

This will create the objects in .PBL files in the local repository. After this step PowerBuilder would have created a new directory in the local repository with the extracted objects

Example C:\Local Git\FTAE\Source

To commit an object to the Git source control system:

1. Right-click the object (or target if you want to commit all object changes) in the “System Tree” and select “Git Commit” from the pop-up menu.

2. In the commit dialog box that displays, input a comment, and click “OK” to confirm committing the object.

3. Now you can proceed to push the objects from the local repository to the DevOps repository.

Push modified objects to DevOps Git Repository

 We will be using GitHub for the Push operation instead of PowerBuilder to make sure the .pbl files are also included in the push operation.

1. In GitHub Commit the changes to the .pbl file that contains the modified objects (This is done as PowerBuilder doesn't commit changes to the .pbl files)

2. Click “Push Origin” and that will push committed objects/files to the DevOps repository

Create a Pull Request from the working branch to “Dev”

1. From the DevOps repo click on “Pull requests” 

2. Click on “Create a pull request”

3. Complete the pull request information (Make sure to link a work item if has not been linked before). Click “Create”

4. Click “Setup auto-complete”

5. Make sure to delete the working branch to ensure there are no stragglers left behind in the repository. Click “Set auto-complete”.

6. Await a reviewer to approve pull request. You will see a completed pull request with the reviewer’s name on the right, and your working branch will be deleted in DevOps. It may continue to live in your local repository.

When “Compile failure” error occurs

When "Compile failure" error occurs during the download process, clicking OK will still download and import the object with the error (and you will need to fix the error later), or clicking Cancel will terminate the download process of all objects and revert to the object on the local computer.