feat: demonstration of the sub-beta-branch creation#2623
feat: demonstration of the sub-beta-branch creation#2623Owen-Liuyuxuan wants to merge 12 commits intomainfrom
Conversation
Signed-off-by: YuxuanLiuTier4Desktop <619684051@qq.com>
|
shmpwk
requested review from
Autumn60,
Copilot,
paulsohn,
rej55 and
sasakisasaki
| sudo wget -qO /usr/local/bin/yq https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64 | ||
| sudo chmod +x /usr/local/bin/yq | ||
|
|
||
| - name: Update children-branches.yaml |
There was a problem hiding this comment.
nit: I would like "child branches" instead of "children branches" (here's the answer from Gemini)
In most contexts, "child branches" reads more naturally and is the standard convention in technical, botanical, and linguistic fields.
While "children" is the plural of "child," English grammar typically uses the singular form of a noun when it acts as an adjective (a "noun adjunct") to modify another noun.
Why "Child Branches" Wins
When you combine two nouns, the first noun describes the type or status of the second. Even if the second noun is plural, the first usually stays singular.
- The Rule: We say "shoe stores" (not shoes stores) or "apple trees" (not apples trees).
- The Application: * Child branch (singular)
- Child branches (plural)
There was a problem hiding this comment.
Pull request overview
This PR introduces a comprehensive workflow system for creating and managing sub-beta branches with automatic cherry-picking capabilities. The implementation allows integrators to create product-specific branches that automatically receive changes from their parent beta branch, with proper labeling and tracking mechanisms.
Changes:
- Added workflow for creating sub-beta branches with metadata and automatic registration
- Implemented automatic cherry-picking from base branches to child branches
- Added automatic labeling for manual PRs to child branches
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 28 comments.
| File | Description |
|---|---|
.github/create-sub-beta-branch.yaml |
Workflow dispatcher for creating and registering new sub-beta branches with validation and PR creation |
.github/workflow-templates/auto-update-child.yaml.template |
Template for base branch workflow that auto-labels PRs and cherry-picks to children |
.github/workflow-templates/auto-add-label.yaml.template |
Template for child branch workflow that auto-labels manual PRs with base branch and product info |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| private_key: ${{ secrets.PRIVATE_KEY }} | ||
|
|
||
| - name: Create label if it doesn't exist | ||
| uses: actions/github-script@v6 |
There was a problem hiding this comment.
The actions/github-script action is using version v6, but the existing codebase uses v7 (as seen in .github/workflows/co-pilot-auto-client.yaml). Consider updating to v7 for consistency with the rest of the codebase.
| if [[ -z "${{ inputs.branch_name }}" ]]; then | ||
| echo "Error: branch_name is required" | ||
| exit 1 | ||
| fi |
There was a problem hiding this comment.
The validation only checks if branch_name is non-empty using -z, but doesn't validate the format or check for invalid characters. Branch names with special characters, spaces, or invalid Git branch name patterns could cause issues later. Consider adding validation to ensure the branch name follows Git naming conventions (e.g., no spaces, no special characters like .., ~, ^, :, ?, *, [, \).
| if [[ -z "${{ inputs.branch_name }}" ]]; then | |
| echo "Error: branch_name is required" | |
| exit 1 | |
| fi | |
| branch_name="${{ inputs.branch_name }}" | |
| if [[ -z "$branch_name" ]]; then | |
| echo "Error: branch_name is required" | |
| exit 1 | |
| fi | |
| # Validate branch_name against Git's refname rules | |
| if ! git check-ref-format "refs/heads/$branch_name"; then | |
| echo "Error: branch_name '$branch_name' is not a valid Git branch name" | |
| exit 1 | |
| fi |
| - name: Generate token | ||
| id: generate-token | ||
| uses: tibdex/github-app-token@v2 | ||
| with: | ||
| app_id: ${{ secrets.APP_ID }} | ||
| private_key: ${{ secrets.PRIVATE_KEY }} |
There was a problem hiding this comment.
This job again uses the third-party GitHub Action tibdex/github-app-token@v2 pinned only to a mutable tag while minting a GitHub App token used to create cherry-pick PRs. Compromise of the action repository or tag would let an attacker run arbitrary code in this step to steal the generated token and perform privileged operations on the repository. Pin this action to a specific commit SHA and treat it as sensitive supply-chain code.
| - name: Cherry pick | ||
| id: cherry-pick | ||
| uses: tier4/action-auto-cherry-pick@v1.0.5 | ||
| with: | ||
| target-branch: ${{ matrix.child-branch }} | ||
| pr-title-suffix: 🍒${{ matrix.child-branch }} | ||
| pr-labels: bot,cherry-pick | ||
| pr-creator-token: ${{ steps.generate-token.outputs.token }} |
There was a problem hiding this comment.
The workflow invokes the third-party action tier4/action-auto-cherry-pick@v1.0.5 pinned only to a version tag and passes it a high-privilege GitHub App token via pr-creator-token. If the action's repository or the v1.0.5 tag is compromised, an attacker could modify the action code to exfiltrate this token or push arbitrary changes under the app's identity. Pin this action to an immutable commit SHA and review its usage as part of your supply-chain hardening.
| - name: Generate token | ||
| if: steps.meta.outputs.skip != 'true' | ||
| id: generate-token | ||
| uses: tibdex/github-app-token@v2 | ||
| with: | ||
| app_id: ${{ secrets.APP_ID }} | ||
| private_key: ${{ secrets.PRIVATE_KEY }} |
There was a problem hiding this comment.
This job uses the third-party GitHub Action tibdex/github-app-token@v2 pinned only to a mutable tag while passing it secrets.APP_ID and secrets.PRIVATE_KEY. If the action repository or tag is compromised, malicious code could exfiltrate these secrets or misuse the generated GitHub App token for privileged operations. Pin this action to a specific commit SHA and treat it as a high-value component in your supply-chain security posture.
| - name: Install yq | ||
| run: | | ||
| sudo wget -qO /usr/local/bin/yq https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64 | ||
| sudo chmod +x /usr/local/bin/yq | ||
|
|
There was a problem hiding this comment.
This step installs yq by downloading a precompiled binary from GitHub using the floating latest URL and executing it without any checksum or signature verification. If the upstream repository or release is compromised, an attacker could run arbitrary code in this CI job and exfiltrate GITHUB_TOKEN or modify build artifacts. Pin the download to a specific version and enforce integrity checking (or use a trusted package source) before executing the binary.
| - name: Install yq for YAML operations | ||
| run: | | ||
| sudo wget -qO /usr/local/bin/yq https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64 | ||
| sudo chmod +x /usr/local/bin/yq |
There was a problem hiding this comment.
somewhat nitty, but I would rather not use latest. Using a fixed version + checksum would be safer.
Alternatively, for github action, we can just have uses: mikefarah/yq@v4.52.2 (although this contains no checksum, but at least github will guarantee that the tag is not moved. We can also use commit hash if really doubtful)
https://github.com/marketplace/actions/yq-portable-yaml-processor
|
This seems good for a workaround. I'll look into this if this can be automated from release_infos. Adding workflow-call might be helpful. |
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Signed-off-by: YuxuanLiuTier4Desktop <619684051@qq.com>
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
There was a problem hiding this comment.
SonarCloud found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.
…are_universe into feat/sub-beta-branch
Signed-off-by: YuxuanLiuTier4Desktop <619684051@qq.com>
Signed-off-by: YuxuanLiuTier4Desktop <619684051@qq.com>
|
|
@paulsohn At this step, I added the workflow to update the pilot-auto hash for these automatically for the special branch. |
| required: false | ||
| type: string | ||
| branch_name: | ||
| description: Full name of the new sub-branch (e.g., beta/v4.2-pilotone) |
There was a problem hiding this comment.
I see pilotone is not a real project, but we want to prevent users from accidentally exposing their project name into this public repository. Can we add a warning statement for this?
There was a problem hiding this comment.
Actually, this is an OSS repository, so unreal project is good.
There was a problem hiding this comment.
Yes, I'm not commenting about 'pilotone'. I'm concerned about our developers can carelessly input our real project name instead of an anonymized one if we don't provide an appropriate description.
There was a problem hiding this comment.
@Owen-Liuyuxuan It seems that SI internal discussion disagree for creating sub branches for projects, even if it's a codename. As such, I can't fully support this PR for now.
https://star4.slack.com/archives/C03QU7K50D8/p1770957058736699
There was a problem hiding this comment.
@paulsohn
I also agree with this. But this test PR is the baseline for E2E branch developments.
There was a problem hiding this comment.
I see. Then maybe we'd better confine this for E2E purpose only, and it should be explicitly stated that this is not for creating proprietary project branches.
There was a problem hiding this comment.
@paulsohn This is also not for E2E only, as long as you believe the experiment/project is suitable to use a new branch, it is OK.
The question of whether the project should open a new private universe is out of the scope here.
At the current design we do not support creating sub universe
Example standard for creating sub-beta-branch
Design principle:
Use a workflow to create universe sub-beta-branch.
The workflow will:
flowchart TB subgraph setup [Initial Setup - One Time] A[Integrator decides to create product branch] --> B[Go to Actions tab] B --> C[Select 'Create Sub-Beta Branch'] C --> D[Fill in inputs] D --> D1[base_branch: beta/v4.2] D --> D2[branch_name: beta/v4.2-myproduct] D --> D3[product_name: myproduct] D --> D4[commit: optional] D1 & D2 & D3 & D4 --> E[Run workflow] E --> F[Review & merge the registration PR] F --> G[Child branch is ready!] end subgraph daily [Daily Operations] H[Developer creates PR to base branch] --> I{PR merged to base?} I -->|Yes| J[Auto cherry-pick to all children] J --> K[Review cherry-pick PRs] L[Developer creates PR to child branch] --> M{Is author a bot?} M -->|No| N[Auto-labeled with base_branch + product_name] M -->|Yes| O[No labels added - automated PR] end subgraph management [Branch Management] P[Add more child branches] --> Q[Run workflow again with same base] Q --> R[New child registered in children-branches.yaml] S[View all children] --> T[Check .github/children-branches.yaml in base branch] end G --> daily G --> managementWorking Example
Trigger action to create sub-branch
Register child branch to beta branch
Beta branch development will be automatically cherry-pick to children
Children will be marked how they created
Direct PR to children branches will be automatically tagged
Examine singular project PRs with tags
Support Multiple Children
Mechanism
flowchart TD subgraph creation [create-sub-beta-branch.yaml - Branch Creation] direction TB C1[Workflow triggered] --> C2[Cache templates from main branch] C2 --> C3[Checkout base_branch] C3 --> C4[Create child branch from commit] C4 --> C5[Add branch-meta.yaml to child] C5 --> C6[Add auto-add-label.yaml to child] C6 --> C7[Push child branch] C7 --> C8{auto-update-child.yaml exists?} C8 -->|No| C9[Create auto-update-child.yaml] C8 -->|Yes| C10[Skip] C9 --> C11[Update children-branches.yaml] C10 --> C11 C11 --> C12[Create PR to base branch] end subgraph baseBranch [Base Branch - auto-update-child.yaml] direction TB B1[PR opened/reopened to base] --> B2{Author contains 'bot'?} B2 -->|No| B3[Add tag:enable-automatic-cherry-pick label] B2 -->|Yes| B4[Skip labeling] B5[PR closed/labeled] --> B6{PR merged + has label + no cherry emoji?} B6 -->|Yes| B7[Read children-branches.yaml] B7 --> B8[For each child branch] B8 --> B9[Cherry-pick commit] B9 --> B10[Create PR to child with cherry emoji] B10 --> B11[Comment on original PR] B6 -->|No| B12[Skip cherry-pick] end subgraph childBranch [Child Branch - auto-add-label.yaml] direction TB CH1[PR opened/reopened to child] --> CH2{Author contains 'bot'?} CH2 -->|No| CH3[Read branch-meta.yaml] CH3 --> CH4[Wait 10 seconds] CH4 --> CH5[Create labels if not exist] CH5 --> CH6[Add base_branch + product_name labels] CH2 -->|Yes| CH7[Skip - automated cherry-pick PR] end subgraph files [Configuration Files] direction LR F1[".github/branch-meta.yaml<br/>(in child branch)"] F2[".github/children-branches.yaml<br/>(in base branch)"] F3[".github/workflow-templates/<br/>*.template (in main)"] end creation --> baseBranch creation --> childBranch baseBranch -->|Cherry-pick PRs| childBranch