Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

GitHub Desktop | Simple collaboration from your desktop

Add a workspace to Git

This is Done by Only the first user does this to add the PowerBuilder workspace to Git Reporepo. 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.

...

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, in order 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.

...

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

...

The name of the current workspace is automatically displayed.

Type in your user name 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 “main” as the origin branch. We will use NACIS as an example in this document

...

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

2. Go to Branches “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”

...

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

...

Get a workspace from Git
Anchor
get-a-workspace-from-git
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.

...

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

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

or

Select Connect “Connect to Workspace Workspace” from the File menu.

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

...

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

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

...

4. Click on the Clone Button (The clone pop-up will appear)

...

“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 dialogue 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 username and then Password password and Paste paste in in the PB Source Control dialogue 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 “Test Connection” to verify the settings are correct

10. Click OK “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 Git Pull

...

a “Git Pull”

...

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

...

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

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

3. In the Source “Source Control Advanced Settings Settings” dialog box, select Diff Viewer “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.“OK”

...

Make Changes to objects in PowerBuilder

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

a. Naming Convention (“features OR bugs” + “/” + “user name” + “/” + pbi_no + “-“ + “short desc”) use small case and no spacesThe 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 Git Pull

...

a “Git Pull”

...

3. Switch Branch the branch to the new newly created working branch

...

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

...

5. Perform a Refresh “Refresh” in PowerBuilder

...

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

BEFORE CHANGE

...

AFTER CHANGE

...

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 object (Or Target or target if you want to commit all object changes) in the System Tree “System Tree” and select Git Commit “Git Commit” from the pop-up menu.

...

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

...

 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 doesn't commit changes to the .pbl files)

...

2. Click Push Origin “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 depo repo click on Pull requests “Pull requests” 

...

2. Click on Create “Create a pull requestrequest”

...

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

...

4. Click Setup “Setup auto-completecomplete”

...

5. Make sure Delete to delete the working branch is checked to be deleted (Click set auto-complete)

...

to ensure there are no stragglers left behind in the repository. Click “Set auto-complete”.

...

6. Await Reviewer a reviewer to approve pull request (. You will see a Complete completed pull request with the Reviewer name) and reviewer’s name on the right, and your working branch is deleted

...

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 back to the object on the local computer.

...