chore: sync released main state back to develop - #15
Conversation
Ci/qa validation suite
📝 WalkthroughWalkthroughChangesProjects v2 owner-type support
Q.A. promotion and validation
Estimated code review effort: 5 (Critical) | ~120 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 1📝 Generate docstrings 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
scripts/validation/repo_quality.py (1)
193-202: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winDo not require a preserved target
Makefileto reference managed scripts.Line 194 validates every caller in
SCRIPT_REFERENCESeven whenstrict_repository_scanisFalse.tests/qa/test_cli_e2e.pypreserves an existing targetMakefileunchanged. A valid preservedMakefilewithoutscripts/validation/repo_quality.pywill therefore fail embedded-target validation.In embedded-target mode, validate script existence and installer copying, but skip
Makefilecaller-content checks unless the installer owns or updates that file. Add a regression test that runs repository quality after installing into a target with a preservedMakefile.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@scripts/validation/repo_quality.py` around lines 193 - 202, Update the owner-reference validation loop in the repository quality check to skip caller-content checks for preserved target Makefiles when strict_repository_scan is false, while retaining script-existence and installer-copy validation. Preserve current caller checks for installer-owned or updated files, and add a regression test covering repository-quality validation after installation into a target with an unchanged Makefile.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/qa-source-branch.yml:
- Around line 3-6: Update the workflow trigger in qa-source-branch.yml from
pull_request to pull_request_target so the gate uses the target branch’s
workflow definition. Keep this metadata-only workflow free of checkout and
pull-request code execution, preserve the existing branch and event filters, and
ensure the workflow is present on the repository’s default branch.
In `@scripts/validation/repo_quality.py`:
- Around line 104-105: Replace the path-only check in is_tool_repository with an
explicit mode passed by the managed invocation or a source identity that
embedded targets cannot control. Ensure embedded targets containing
tests/test_project_setup.py remain in target mode rather than tool-source mode.
Add a regression test covering that embedded-target layout.
---
Outside diff comments:
In `@scripts/validation/repo_quality.py`:
- Around line 193-202: Update the owner-reference validation loop in the
repository quality check to skip caller-content checks for preserved target
Makefiles when strict_repository_scan is false, while retaining script-existence
and installer-copy validation. Preserve current caller checks for
installer-owned or updated files, and add a regression test covering
repository-quality validation after installation into a target with an unchanged
Makefile.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 9fa80dc7-de5b-496c-ba52-0e915ccd269a
📒 Files selected for processing (31)
.env.example.github/workflows/main-source-branch.yml.github/workflows/qa-issue-generation.yml.github/workflows/qa-live.yml.github/workflows/qa-source-branch.yml.github/workflows/qa-validation.ymlAI_SETUP_GUIDE.mdMakefileREADME.mdREADME.pt-BR.mddocs/DOCUMENTATION-GUIDE.mddocs/repo/branching-policy.mddocs/repo/branching-policy.pt-BR.mddocs/repo/project-owner-type.mddocs/repo/project-owner-type.pt-BR.mddocs/repo/qa-policy.mddocs/repo/qa-policy.pt-BR.mddocs/repo/testing-policy.mdproject_setup/cli.pyproject_setup/installer.pyproject_setup/pr_validation.pyproject_setup/project.pyproject_setup/runner.pyscripts/validation/repo_quality.pytests/qa/live_issue_generation.pytests/qa/live_sandbox.pytests/qa/test_cli_e2e.pytests/test_branch_promotion.pytests/test_makefile_env_defaults.pytests/test_project_owner_type.pytests/test_qa_workflows.py
| on: | ||
| pull_request: | ||
| branches: ["Q.A"] | ||
| types: [opened, synchronize, reopened, edited, ready_for_review] |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow files =="
git ls-files '.github/workflows/*'
echo "== target workflow =="
if [ -f .github/workflows/qa-source-branch.yml ]; then
cat -n .github/workflows/qa-source-branch.yml
else
echo "missing .github/workflows/qa-source-branch.yml"
fi
echo "== other workflows mentioning qa/source/Q.A/policies =="
rg -n "Q\.A|qa-source|promotion|source-branch|pull_request_target|pull_request" .github/workflows || trueRepository: v-Kaefer/Github-Project-Automation
Length of output: 7352
🌐 Web query:
GitHub Actions required statuses pull_request pull_request_target merge commit documentation
💡 Result:
Required status checks in GitHub Actions are a critical feature for maintaining code quality on protected branches, ensuring that specific workflows complete successfully before a pull request can be merged [1][2]. Key concepts and their roles are outlined below: Pull Request vs. Pull Request Target The pull_request and pull_request_target events serve different purposes regarding security and execution context [3][4]. pull_request: This event triggers workflows using the code from the pull request merge commit [5][4]. It is the standard choice for CI testing and security scanning because it runs with restricted permissions when triggered from forks, ensuring untrusted code cannot access secrets or write to the repository [3][6][4]. pull_request_target: This event runs the workflow using the code from the base repository's target branch [5][4]. Because it runs within the context of the base repository, it has access to secrets and can perform write operations [3][4]. It is designed for automation—such as labeling, commenting, or posting status checks—that needs higher privileges while responding to pull requests, including those from forks [3][6][4]. If using this event, you must exercise extreme caution to avoid executing untrusted code from the pull request [3][4]. Merge Commit and Status Checks Required status checks must typically pass on the latest commit SHA of the pull request [7][8]. When branch protection is configured, GitHub evaluates whether checks need to pass against the head commit or a test merge commit [7][8]. If a test merge commit is generated, GitHub may show that checks are running against that specific commit [7][8]. If your repository uses a merge queue, you must also include the merge_group event as a trigger in your workflows [7][8][9]. Without it, required status checks will not report correctly for queued items, causing merge failures [7][9]. General Requirements For any workflow to function as a required status check: - The check must conclude as success, skipped, or neutral [7][1]. - It must be explicitly enabled in the branch protection rules for the target branch [2]. - If you require specific workflows via organization rulesets, ensure they are configured to run on the appropriate events [10][9].
Citations:
- 1: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches?require-status-checks-before-merging=
- 2: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule
- 3: https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target
- 4: https://stackoverflow.com/questions/74957218/what-is-the-difference-between-pull-request-and-pull-request-target-event-in-git
- 5: https://stackoverflow.com/questions/64802322/running-github-actions-on-the-code-in-a-pull-request-from-a-fork
- 6: https://docs.github.com/en/enterprise-cloud@latest/actions/reference/security/securely-using-pull_request_target
- 7: https://docs.github.com/en/pull-requests/how-tos/merge-and-close-pull-requests/troubleshooting-required-status-checks
- 8: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/troubleshooting-required-status-checks
- 9: https://docs.github.com/en/enterprise-cloud@latest/pull-requests/how-tos/merge-and-close-pull-requests/troubleshooting-required-status-checks
- 10: https://docs.github.com/en/enterprise-server@3.10/actions/using-workflows/required-workflows
🌐 Web query:
GitHub Actions pull_request push workflow runs merge commit same repo PR push workflow runs base commit
💡 Result:
In GitHub Actions, the push and pull_request events behave differently regarding which commit they operate on and what they test [1][2]. Push Event When a workflow is triggered by a push event, the GITHUB_SHA is the commit SHA that was pushed to the repository [1][3]. The workflow runs against this specific commit, representing the state of the branch exactly as it exists after the push [3][2]. Pull Request Event When a workflow is triggered by a pull_request event, GitHub creates a temporary merge commit that combines the head branch of the pull request with the base branch [3][4]. - Default Behavior: The GITHUB_SHA for a pull_request event is this temporary merge commit [5][4]. - Checkout: Because actions/checkout uses GITHUB_REF by default, and GITHUB_REF is set to the merge branch (e.g., refs/pull/:prNumber/merge), the action automatically checks out this merge commit [6][4]. - Purpose: This ensures your CI tests run against the proposed result of the merge, rather than just the isolated head branch [6][3][2]. Key Differences in Same-Repo Workflows When you have a workflow configured to trigger on both push and pull_request within the same repository, pushing code to a branch associated with an open pull request will trigger both events simultaneously [7][2]. - The push event tests the head commit independently [1][2]. - The pull_request event tests the hypothetical merge commit [3][2]. To avoid duplicate workflow runs, it is common practice to: 1. Limit push triggers to the default branch (e.g., main) and let pull_request handle all feature branch testing [7][2]. 2. Use conditional logic (e.g., if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name != github.repository) to skip runs for internal PRs that are already covered by push [2]. 3. Use concurrency groups to cancel older runs when a new push or PR update occurs [1][2]. If you specifically need to test the head commit rather than the merge commit during a pull_request event, you can reference github.event.pull_request.head.sha instead of GITHUB_SHA [5][4].
Citations:
- 1: https://github.com/scratchfoundation/understand-gha-triggers
- 2: https://costops.dev/guides/duplicate-trigger-runs
- 3: https://www.liamadamson.co.uk/2025/03/26/pr-triggered-actions-nuances.html
- 4: https://docs.github.com/actions/using-workflows/events-that-trigger-workflows
- 5: GITHUB_SHA on PRs refers to the merge commit, not the actual commit which triggered the PR github/docs#15302
- 6: https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
- 7: https://stackoverflow.com/questions/70767090/github-actions-on-push-and-on-pull-request-difference
Gate policy validation on the target-branch workflow definition.
pull_request executes .github/workflows/qa-source-branch.yml from the PR merge commit. A same-repository PR can modify this workflow to always succeed while the required check name stays the same. Use pull_request_target for this metadata-only check, keep it free of checkout and PR-code execution, and ensure the workflow exists on the default branch.
Proposed fix
on:
- pull_request:
+ pull_request_target:
branches: ["Q.A"]
types: [opened, synchronize, reopened, edited, ready_for_review]📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| on: | |
| pull_request: | |
| branches: ["Q.A"] | |
| types: [opened, synchronize, reopened, edited, ready_for_review] | |
| on: | |
| pull_request_target: | |
| branches: ["Q.A"] | |
| types: [opened, synchronize, reopened, edited, ready_for_review] |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/qa-source-branch.yml around lines 3 - 6, Update the
workflow trigger in qa-source-branch.yml from pull_request to
pull_request_target so the gate uses the target branch’s workflow definition.
Keep this metadata-only workflow free of checkout and pull-request code
execution, preserve the existing branch and event filters, and ensure the
workflow is present on the repository’s default branch.
| def is_tool_repository() -> bool: | ||
| return (ROOT / TOOL_REPOSITORY_MARKER).is_file() |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | 🏗️ Heavy lift
Replace the path-only repository classifier.
An embedded target can contain tests/test_project_setup.py for its own tests. Line 105 then selects tool-source mode and requires source-only files such as pyproject.toml, source workflows, and source tests.
Pass the mode explicitly from the managed invocation, or use a source identity that an embedded target does not control. Add a regression test for an embedded target that already contains this path.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@scripts/validation/repo_quality.py` around lines 104 - 105, Replace the
path-only check in is_tool_repository with an explicit mode passed by the
managed invocation or a source identity that embedded targets cannot control.
Ensure embedded targets containing tests/test_project_setup.py remain in target
mode rather than tool-source mode. Add a regression test covering that
embedded-target layout.
1 participant
Linked Issue
Milestone
Summary
mainback intodevelopafter the completed Q.A → main promotion.developas the correct base for future implementation branches.How to test
main; their trees should be identical whiledevelopshould receive the released Q.A/main changes.Evidence
Known risks
mainHEAD and contains the already released state.DoD checklist
Summary by CodeRabbit
New Features
Bug Fixes
develop → Q.A. → main.Documentation
Tests