- 24 Mar 2022
- 6 Minutes to read
External Pull Request
- Updated on 24 Mar 2022
- 6 Minutes to read
About External Pull Request
Create a pull request to propose and collaborate on changes to a repository. These changes are proposed in a branch, which ensures that the master branch only contains finished and approved work.
You can specify which branch you'd like to merge your changes into when you create your pull request. Pull requests can only be opened between two branches that are different.
External Pull Request vs Merge Request
Merge Request and Pull Request are equivalent. Both are means of pulling changes from another branch or fork into your branch and merging the changes with your existing code.
Merge Request is essentially a request to merge one branch into another. With Merge Request, AutoRABIT allows you (the reviewer) to go through the suggested changes. From here, you can choose to apply them or add comments to make further changes to the code. It is particularly useful as it helps merge code from different branches and make sure the code that gets deployed to production is bug-free.
Ex: For instance, one of your developers has just finished working on a feature in a dedicated branch. Now, this feature should be merged with the development branch. But first, other team members should review it.
So, your developer creates a merge request, chooses the feature branch as Source and the development branch as Destination. The developer can add the title and the description of the merge request and choose who will be the Reviewers of it.
The reviewer can:
- see what files have been edited, what commits have been made
- add comments to the whole merge request or a particular code line and discuss it
- decline a pull request
- merge a pull request
External Pull Request
AutoRABIT allows you to create a new pull request to pull changes from another branch. For each pull request created inside AutoRABIT, you will have a link that will redirect you to GitHub/Bitbucket application externally where you can view the code changes, merge the changes and close the pull request. But, if there are problems with the proposed changes, they can post feedback in the pull request. Follow-up commits will show up right next to the relevant comments.
There is also a provision to approve the pull request within the AutoRABIT application as well.
Before You proceed for External Pull Request
- Enable Pull Request support for users in AutoRABIT. The account owner or admin must perform this function.
- Users have appropriate roles or permissions to integrate their Version Control Repository for pull requests. Such privileges are granted by their account owner or admin. They can assign the required permission to the employees by visiting the Admin > Roles tab and selecting the 'Create Pull Request' checkbox under the 'Special Permissions In Version Control' section.
- The Approver should have the Pull Request Approver permission.
- Users are allowed to access the 'External Pull Requests' page. The account owner or admin can assign the required permission to the users by visiting the Admin > Roles tab and selecting the 'External Pull Requests' checkbox under the Version Control section.
Enable Pull Request Support
- Go to the My Account page.
- Under Plugins, select the hosting service to manage your repositories. AutoRABIT currently supports both GitHub/Bitbucket (cloud and server) and Azure Cloud in raising a pull request.
- Click Save.
- Next, go to the Version Control Repository page.
- On this page, select your Version Control Repository from which you like to enable the pull request support.
- On the right side of the screen, select the checkbox: Enable Pull Request Support
- Next, select the pull request plugins enabled for your account. For more details, please contact your administrator.Copy the auto-generated URL (applicable only for Github cloud and enterprise service) and create a webhook push event for pull requests in your repository. This integration can be used to trigger CI jobs while creating a pull request.
- Click Save Details to save the Pull Request configuration.
Creating an External Pull Request
Pull requests are a mechanism for a developer to notify team members that they have completed a feature. Once their feature branch is ready, the developer files a pull request via their account. This lets everybody involved know that they need to review the code and merge it into the master branch.
How it works
- A developer creates the feature in a dedicated branch in their local repository.
- The developer pushes the branch to a public Version Control repository via AutoRABIT.
- The developer files a pull request via AutoRABIT.
- The rest of the team reviews the code, discusses it, and alters it.
- The approved Merger merges the feature into the official repository and closes the pull request.
Creating a Pull Request
- From the top navigation pane, go to Create New > New EZ-Commit.
- On the EZ-Commit screen, select the Salesforce Org from which the metadata components will get fetched. Select the Salesforce Org registered Author.
- Select the Version Control Repository for which the pull request support is enabled. Select its mapped branch.
- Select the way to fetch the metadata components from the selected Salesforce Org under the Fetch Changes section. Choose the one that best fits your needs.
- Under Perform section, select the option: Create a Pull Request
- Leave the remaining field as default and click on the Next button to proceed ahead.
- On the next page, select the metadata components and their members to be committed to the Version Control branch. Click Next.
- On the next screen, you need to do the following:
- To include your globally selected profiles/ permissionsets to the commit, select the checkbox: Apply Global Profile Permissions
- Apply Search and Substitute Rules: If you have created the SEARCH and SUBSTITUTE rules to define custom find and substitute rules, AutoRABIT applies whenever you commit and deploy files from one Sandbox to another Sandbox one Sandbox to Version Control or vice-versa, such rule can be found here.
- Enter the Commit Comment. This is a mandatory step.
- Under Create a Pull Request section, choose where you like to commit i.e., in your base branch, or create a new branch and commit under it.
- To create a new branch and later commit the changes, enter the new branch name.
- Give the Pull Request a Label Name.
- Once all the fields are filled in, click on Finish. This concludes the creation of a pull request and is ready for review. After you create a pull request, you can ask a specific person to review your proposed changes.
- Once the commit process is initiated, you will be redirected to the Commits screen where you can view the progress of your commit operation initiated.
Creating Pull Request during CI Job
Now since you have enabled pull requests for your Version Control Repository, you can trigger CI Job via AutoRABIT using the pull request webhook.
- Go to Create New > New CI Job.
- On the next screen, select one of the below criteria for running the CI Job:
- Package from Version Control
- Deploy from Version Control
- Deploy SFDX source from Version Control
- Go to the Build section.
- Select the Version Control Repository for which the pull request is enabled. Then, select the Branch.
- Now, select the Pull Request checkbox. You can see that some of the options have been withdrawn automatically, for example, Incremental Build, Trigger Build on Commit, or Map ALM Project. This is because such options are not supported when raising requests via pull webhook.
- Pull Request facilitation is provided for both GitHub and Bitbucket (cloud and enterprise) services.
- When Pull Request is validated via CI job, the 'Validate Only' option (under Deploy section) will be in the selected mode. The user won't be able to deselect it.
- Choose the remaining fields that best fit your needs and click Save.
- Go to the 'External Pull Requests' page, where you can find the CI Job details that were triggered via webhook pull request. Upon successful Build/Deploy, comments get updated to the pull request. The revisions associated with the pull request will be packaged. These changes will be validated and the results will get updated back to the pull request as a comment.