You can now, you can harness the power of Clayton's static code review to enhance the efficiency of your pipelines.
Once you've created your Gearset pipeline, you can use Clayton as a status check for incoming PRs that move across your static environments.
To see how this works in practice, check out the video below, which demonstrates what the integration looks like in your pipeline.
Adding a Repository and Connection in Clayton
Allowing Clayton access to your repositories mean it can scan changes, apply configurable rules, and perform real-time code reviews, ensuring that code remains compliant with best practices.
Adding a New Connection in Clayton:
Access Workspace Settings:
Click your name at the top left of any page.
Select "Connections" from the dropdown menu.
Manage Connections:
On the Connections screen, you can view, edit, or add new connections.
Only administrator users have permission to manage connections.
Connections that are currently in use by one or more projects cannot be deleted.
You can find a more detailed guide on adding Clayton Connections in our documentation page
Enabling Clayton Protection modes for that Repository
Clayton automates code quality monitoring by scanning changes in your repository, analyzing app metadata, and applying configurable rules to maintain a clean codebase. It uses webhooks to track relevant Git events and perform real-time code reviews.
Steps to Enable Automated Code Reviews:
Project Selection:
Start by selecting the project from the Clayton homepage.
Navigate to Settings > Protection to view and adjust protection settings.
Choose a Protection Mode:
Observe Discreetly: Gathers insights without interfering, suitable for long-term audits.
Make Suggestions: Monitors development and provides optional suggestions, ideal for first-time users or teams not yet adhering strictly to standards.
Protect what's new (RECOMMENDED) : Actively oversees developments and requests changes for non-compliance, suitable for ongoing projects aiming to improve standards.
Full Compliance: Enforces compliance, addressing both new and legacy issues, best for new applications or strict teams.
By configuring the appropriate protection mode, Clayton can automate code reviews efficiently, maintaining code quality across projects. For a more detailed guide check out or guide on Monitor your code with automatic reviews
Creating a Quality Gate in your VCS
To truly maintain high code quality and consistency, you need to set up a quality gate in your version control system (VCS), often called a branch protection rule. Should specific approval rules or status checks not be configured, the progression of issues will remain unblocked.
Setting up a quality gate is essential for enforcing a consistent quality policy within your organization. It ensures that only code that has successfully passed required code reviews can be merged into protected branches. This helps uphold a high standard across your project by preventing unreviewed or low-quality code from being integrated. While the exact setup process varies depending on your VCS, we've created step-by-step guides for each major platform to simplify it. By configuring a quality gate, you establish a structured process for managing code quality and ensuring compliance with your organization's standards.
Github
GitLab
Bitbucket
Azure DevOps
Promoting a PR in your Gearset Pipeline
All new PRs new created in Gearset will now be scanned for potential issue in Clayton automatically. It's important to notice that if you have choose to only Scan PRs only when destination is a tracked branch you should make sure that all your target repositories are tracked.
Understanding Status Checks in Gearset with Clayton
A status check in Gearset, when integrated with Clayton, provides a comprehensive evaluation of the entire source commit associated with a Pull Request (PR). Unlike a simple code review that only examines the new changes introduced in the PR, a status check analyzes every file involved in the specific revision. This means it scans all files, regardless of whether the changes were made in the current PR or in previous ones.
This approach ensures the overall health of the codebase rather than just focusing on the changes being introduced. Even if a PR only updates a few lines of code, the status check will flag any pre-existing issues within the affected commit, treating the entire commit as a single unit. As a result, the report is considered "all-or-nothing" because if any issues are detected whether newly introduced or inherited from past commits the PR will fail the status check.
This approach can sometimes affect the workflow since a PR might fail not because the new changes introduced issues, but because there are existing issues from prior commits that are now being evaluated. Consequently, developers often need to address existing issues in the same PR, even if they were not the original authors of those issues. This ensures the quality of the entire project rather than allowing unchecked changes to accumulate over time.
Reference Dates and Legacy Code
This is where a reference date and the Legacy Code Filter become invaluable. A reference date acts as a historical marker, allowing you to tell Clayton to ignore any code quality issues that existed in the codebase before that specific date. By setting this date, the Legacy Code Filter will ignore older, pre-existing issues from the current status check report. This enables your team to focus solely on addressing new issues introduced by the PR or any technical debt that has accumulated since the reference date, preventing older, known problems from automatically failing your builds and streamlining your path to a cleaner codebase.
The status check, therefore, acts as a comprehensive quality gate that maintains consistency and integrity across the entire codebase.
Reviewers
Here you can view the Clayton[bots] feedback. This feedback takes a different approach by analyzing only the files changed in the current PR, specifically flagging issues introduced by those changes rather than highlighting pre-existing problems. This approach keeps the feedback relevant and focused on what was actually modified, rather than bringing up legacy issues.
To view a comprehensive list of all issues related to the pull request, you can click on Full report for more detailed information.