Reviewing and verifying fixes
Take an eligible GitHub dependency finding from a reviewed proposal through a real pull request, human merge, and verification.
When to use a fix proposalPermalink to When to use a fix proposal
Use this workflow when Relane offers a fix action for a confirmed dependency finding in a connected GitHub repository. It provides a proposal you can inspect before authorizing a repository change. Availability is specific to the finding and workspace; not every dependency issue or repository has an automated fix.
- Start with a confirmed finding and read the original assessment. Needs validation and Unconfirmed candidates are not eligible confirmed findings.
- The finding must not be triaged as Not a real issue or Ignored, and the console must offer a fix action for it.
- Check that the GitHub connection and the permissions needed to open a pull request are available. Have a human reviewer who can review and merge in the repository.
- If no fix action is offered, use the finding's guidance to plan a manual change. Do not assume that connecting another source-control system enables this GitHub fix workflow.
Open the proposalPermalink to Open the proposal
Open the eligible finding
Use Findings or the original scan result. Confirm the repository and issue before choosing an action.
Prepare or resume
Choose Prepare fix to request a draft. Use Review fix or Resume review when a proposal already exists, rather than starting another review for the same work.
Wait for review content
A proposal can still be preparing. Read the message and return when the diff is ready. Requesting a proposal is not approval to change the repository.
Review, regenerate, or rejectPermalink to Review, regenerate, or reject
- Read the entire proposed diff, the changed-file list, and additions and deletions. Confirm that the dependency change addresses the finding without unrelated edits.
- Review compatibility and the tests needed for your application. A passing safety assessment does not replace application-specific review.
- Choose Regenerate if you need a new proposal. Review the replacement from the beginning; checks and approval readiness for an earlier proposal do not carry over.
- Choose Reject if the proposal should not proceed. Rejecting the proposal is not a false-positive decision about the finding and does not remediate the issue.
Where offered, View fix history opens prior activity. A rejected, failed, or completed attempt in history is a record of what happened, not a currently approvable proposal.
Approve only the current checked changePermalink to Approve only the current checked change
Approve and open a pull request becomes available only when approval is supported, the proposal is current, and the change was assessed as safe. The displayed bytes of the diff must match the assessed bytes: the change you review must be the change that passed the check. Explicitly approve only after your review; this authorizes a real branch and pull request in the GitHub repository, not merely a saved decision.
| If approval is blocked | Next action |
|---|---|
| A newer proposal exists | Load and review the current proposal. Do not rely on a review of the earlier revision. |
| The base branch has changed | Regenerate the proposal against the current base, then review it again before approving. |
| Safety did not pass or was not assessed | Do not apply the change. Read the available assessment and regenerate or reject as appropriate. |
| The displayed change cannot be verified against the checked change | Reload or regenerate as directed, then review again. Do not bypass the mismatch. |
| Approval is unavailable | Review, regenerate, or reject where offered, but do not assume that a viewable proposal can be applied. Contact support if needed. |
Conditions can change while a proposal is open. If the approval-time freshness check fails, no branch or pull request is created by that approval. Reload, regenerate as directed, and review the current state instead of repeatedly approving the old view.
Review the real pull request and checksPermalink to Review the real pull request and checks
Wait for the pull request
After approval, watch What happened for the actual pull-request entry and link. An approval acknowledgement means opening is in progress; it is not evidence that the pull request already exists.
Inspect GitHub checks
Open the real pull request, review its diff, and inspect the checks and required reviews. The Relane timeline shows check entries when they are reported; an absent check is not a successful one.
Resolve failures before merge
Investigate failing checks, compatibility issues, and missing required review using your normal repository process. Proposal safety and pull-request checks answer different questions.
Have a person merge
A human decides whether and when to merge in GitHub. Relane does not merge for you. Closing the pull request without merging does not apply the proposed change.
Verify after mergePermalink to Verify after merge
Return to the fix activity after merge and inspect the reported post-merge verification at the exact merge commit. Where a rescan link is available, open its result and check the assessed version, original issue, and coverage. Verification may instead be target-focused verification of the original finding; do not describe that as a new full-repository assessment.
- Verification running means the outcome is still pending.
- If verification has not started or did not establish a complete result, use Retry verification when offered and inspect the new outcome.
- Before treating the issue as resolved, confirm that the relevant verification no longer reports the original finding. A successful workflow status alone is not that evidence.
- If the finding remains or another issue appears, review it and plan further work. A merged pull request is not proof that the original problem is gone.
- If coverage is insufficient, keep the verification gap explicit. Marking the finding Fixed or seeing fewer findings does not close that gap.