Pull Requests - Public Beta
A Pull Request (PR) is a fundamental tool in software development, enabling contributors to submit code changes for peer review before integration, enhancing code quality, and promoting collaboration.
In Y42, the Pull Request feature supports both GitHub Pull Requests and GitLab Merge Requests, with its functionality shaped by the specific features and constraints of these Git providers.
Uniquely, Y42’s PRs extend beyond code updates to also include data changes caused by the respective code-data diffing. This setup allows for rigorous scrutiny of both code and data changes. This dual focus ensures that all modifications uphold the stringent standards essential for maintaining data integrity and reliability.
Pull Requests Workflow in Y42
Branching
The workflow begins with branching. Use a branch to isolate development work, ensuring it does not impact the stability of other branches in the repository. Changes from one branch can be merged into another using a Pull Request. Please refer to Working with branches for detailed information on branch.
Committing Changes
As changes are made within a branch, commit these changes incrementally. Each commit represents a single logical change to the codebase, complete with a descriptive message that provides context for the change, facilitating easier PR review.
Materializing Data for Data Diffing
Once committed, all data changes should be materialized. This allows Pull Request reviewers to validate the proposed changes against previous versions of datasets or expected business outcomes.
Creating Pull Requests
Once a feature or fix is ready, bundle these commits into a pull request and any additional context necessary for reviewers to understand the modifications.
Review and Collaboration
Team members and stakeholders review the content of a PR, comment on potential improvements, and suggest or directly make further modifications by committing changes to the branch. Use Y42 in-app notifications to get notifications about the most recent PRs updates.
Integration
For a Pull Request to be merged into the target branch, it must meet several criteria: it requires approval from designated reviewers according to the Git provider's rules, must comply with branch and merge rules set within the repository for the specific Git provider, and must pass the Continuous Integration (CI) checks that Y42 executes on spaces.
Pull Requests - Roles and Permissions
The access rules for the Pull Request feature in Y42 adhere to the standard Y42 roles and permissions setup, detailed further in our documentation on roles and permissions (opens in a new tab).
Write actions
To perform ‘write’ repository actions related to pull requests, which are create, close, approve and merge the following permissions should be in place for a Y42 user:
- Git identity linked to the space. The Git identity linked to the Y42 space must have access levels that permit 'write' actions on the repository. For detailed guidelines on setting repository access configurations, please refer to the documentation provided by the respective Git provider: Gitlab (opens in a new tab) and GitHub (opens in a new tab)
- Organization/space permissions:
- 'Administrator' role within the organization, or
- 'Limited Access Role' at the organization level and have 'Owner' permissions at the space level
Read actions
To perform ‘read’ repository actions related to pull requests such as view PR and add comments, Y42 user should have:
- Git identity linked to the space. The Git identity linked to the Y42 space must have access levels that permit 'read' actions on the repository. For detailed guidelines on setting repository access configurations, please refer to the documentation provided by the respective Git provider: Gitlab (opens in a new tab) and GitHub (opens in a new tab)
- 'Limited Access Role' or ‘Limited Viewer Access’ at the organization level and have 'Viewer' permissions at the space level
Create a PR
Select a branch
Create a new branch or navigate to the relevant branch to add changes. Make sure the branch is up-to-date and has no conflicts with the base branch. If not, pull changes and resolve all conflicts (opens in a new tab) as prompted by Y42.
Commit your changes
Commit changes you made to the Git repo.
Build asset
Build assets that are affected by the code changes. Perform a build command (opens in a new tab) and make sure the run completes successfully.
Create a PR
Open the pull request creation modal using the git menu or by navigating to the Pull Requests List and creating a PR from there. Fill in the details and click ‘Create pull request’.
Request a pull request review
Assigning reviewers
- While creating a PR: During the PR creation, you will see an option to assign reviewers to your PR.
- After creating a PR: If you did not assign reviewers during the initial PR creation, you can add them as long as PR is open.
Assign Reviewers directly in GitHub/GitLab:
Go to the GitHub/GitLab repository linked to your Y42 space. Use the repository's interface to assign reviewers.
Join as reviewer
If you are not initially on the reviewer list, you cannot add yourself, but you can join as a reviewer and immediately approve the Pull Request if necessary.
Navigate to a Pull Request
Access Pull Requests
In your space, click on the 'Pull Requests' option from the main menu.
Search, Sort and Filtering Options
To find a specific PR, use the available search and filter tools:
- Search Bar: Enter keywords in the search bar related to the PR you are looking for, such as the PR title, author’s or reviewer’s name, or branch name. You can also navigate to a specific Pull Request by clicking on an in-app notification related to PR.
- Filtering Options: Apply filters to narrow down your search:
- Status Filter: Select to view PRs based on their status (open, closed, merged).
- Date Filter: Filter PRs by their creation dates.
- Sorting Options: Organize your PR list by clicking on column titles.
Access PRs from Notifications:
Click on in-app notifications related to PRs. These notifications can direct you to specific Pull Requests that require your attention or action.
Pull request review
Review General Details of in the Pull Request
- Examine the Title and Description: Ensure they accurately reflect the changes made.
- Check Labels: Review any labels applied for additional context.
- Review Branch Details: Ensure the source and target branches are correct. Address any branch conflicts that may need resolution.
- Navigate to GitHub/GitLab: Use direct links provided in Y42 to open the PR in GitHub or GitLab for detailed review.
Review and Resolve Comments
- General Comments: Add general comments to the PR through Y42 as well as directly in GitHub or GitLab. However, due to limitations in GitHub, these comments cannot be resolved within the Y42 UI.
- Code Comments: Add code comments directly in GitHub or GitLab. Y42 syncs these comments but they must be resolved in the respective platform.
- Configuration Settings: In GitHub or GitLab, configure whether the PR can be merged even if not all code comments are resolved.
Review Code Changes
- Review Commit List: Examine the list of commits included in the PR.
- Inspect Single Commit: Use commit IDs provided in Y42 to review changes directly on GitHub or GitLab.
- File Changes: View the list of all changed files in the git repository.
- Compare Diffs: Select files to compare differences, either inline or side-by-side.
Review Asset Changes
- Review DBT Assets: Examine DBT assets involved in dbt_manifest compilation and affected by the commits.
Compare Materialization Information
- DWH Configs and Schemas: Compare configurations and view schemas of the data warehouse views affected by the changes.
Compare Data Changes
- View Data Diff: Compare two assets or snapshots of the same asset to identify row and column-level changes, such as updates, deletions, or additions.
Continuous Integration (CI) Checks
- CI Status: Y42 conducts CI checks (opens in a new tab) on all linked repositories. Additionally, users have the option to set up their own CI/CD pipelines directly in GitHub or GitLab, which can impact the PR workflow in Y42.
Approving Pull Requests
The PR author cannot approve their own pull request. Only users who are assigned as reviewers have the authority to approve. Additionally, any other user who was not originally assigned as a PR reviewer but had the necessary roles and permission to perform as a reviewer can join as a reviewer and approve the pull request immediately. -Approval with Pending Issues: There are no limitations to approving PRs.
Closing Pull Requests
- Close Permissions: The PR author can close their own pull request. Users with writing gitlab/github access, repo owner/admin can do it.
- Closing with Pending Issues: There are no limitations to closing PRs.
Merging Pull Requests
The PR author can close their own pull request. Users with writing gitlab/github access, repo owner/admin can do it.
By default, any pull request can be merged at any time, unless the head branch is in conflict with the base branch. However, there may be restrictions on when you can merge a pull request into a specific branch. For example, you may only be able to merge a pull request into the default branch if required status checks are passing. Repository administrators can add constraints like this to branches using branch protection rules. Please refer to docs of GitLab and GitHub for respective limitations.