github actions: Add automated CLK rebase workflow

[bmastbergen]

Add a new GitHub Actions workflow to automate the process of rebasing CLK kernel branches against upstream stable releases. The workflow:

• Triggers on workflow_dispatch or repository_dispatch
• Performs rebase using lt_rebase.sh from kernel-src-tree-tools
• Builds the kernel (with virtme-ng compatible configuration tweaks)
• Runs kernel selftests in a virtme-ng vm
• Creates a pull request with build logs, test results, and config changes
• Tracks test pass rates across rebase iterations

Also modifies sync.yml to trigger the rebase workflow via repository_dispatch when stable branches receive updates, creating an end-to-end automation pipeline for keeping CLK branches synchronized with upstream stable releases.

[Copilot]

Pull request overview

This PR adds comprehensive automation for rebasing CLK kernel branches against upstream stable releases. The workflow integrates with the existing sync workflow to create an end-to-end pipeline that automatically detects stable branch updates, performs rebases, builds and tests kernels, and creates pull requests with detailed results.

Changes:

• Modified sync.yml to detect when stable branches are updated and trigger the rebase workflow via repository_dispatch
• Added clk-rebase.yml workflow that performs automated rebasing, kernel building with virtme-ng configuration, selftest execution, and PR creation with test results and metrics tracking

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 13 comments.

File	Description
.github/workflows/sync.yml	Added logic to detect changes after rebase and trigger CLK rebase workflow for stable branches via repository_dispatch API
.github/workflows/clk-rebase.yml	New comprehensive workflow that automates CLK kernel branch rebasing, building, testing, and PR creation with metrics tracking

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The repository_dispatch API call doesn't check for errors. If the curl command fails (e.g., network issues, authentication problems), the workflow will continue silently without triggering the rebase workflow. Consider adding error handling to check the HTTP response status or use the -f flag with curl to fail on HTTP errors, combined with proper error checking.

[bmastbergen]

This isn't a terrible idea

[Copilot]

The gh pr create command doesn't handle the case where a PR from TMP_CLK_NEXT_BRANCH to CLK_NEXT_BRANCH already exists. If the workflow runs multiple times before a PR is merged, subsequent runs will fail at this step with an error about a PR already existing. Consider adding logic to check for existing PRs and either update them or skip PR creation with a message.

Suggested change

	# Create the PR
	gh pr create \
	--title "[CIQ ${CLK_VERSION}] Rebase to v${STABLE_VERSION}" \
	--body-file /tmp/pr_body.md \
	--base ${CLK_NEXT_BRANCH} \
	--head ${TMP_CLK_NEXT_BRANCH} \
	--reviewer bmastbergen
	# Check for an existing open PR from TMP_CLK_NEXT_BRANCH to CLK_NEXT_BRANCH
	EXISTING_PR_NUMBER=$(gh pr list \
	--base "${CLK_NEXT_BRANCH}" \
	--head "${TMP_CLK_NEXT_BRANCH}" \
	--state open \
	--json number \
	--jq '.[0].number' || true)
	if [ -n "${EXISTING_PR_NUMBER}" ]; then
	echo "Found existing PR #${EXISTING_PR_NUMBER} from ${TMP_CLK_NEXT_BRANCH} to ${CLK_NEXT_BRANCH}; updating title and body."
	gh pr edit "${EXISTING_PR_NUMBER}" \
	--title "[CIQ ${CLK_VERSION}] Rebase to v${STABLE_VERSION}" \
	--body-file /tmp/pr_body.md
	else
	echo "No existing PR from ${TMP_CLK_NEXT_BRANCH} to ${CLK_NEXT_BRANCH}; creating a new one."
	gh pr create \
	--title "[CIQ ${CLK_VERSION}] Rebase to v${STABLE_VERSION}" \
	--body-file /tmp/pr_body.md \
	--base ${CLK_NEXT_BRANCH} \
	--head ${TMP_CLK_NEXT_BRANCH} \
	--reviewer bmastbergen
	fi

[bmastbergen]

This isn't a terrible idea

[shreeya-patel98]

This is great!

[shreeya-patel98]

@bmastbergen what do you think about making this work with the Kernel CI Workflow instead of having it's own PR creation or testing steps?
I'm not thinking about doing this optimization right now but I feel we can do this in future.

[bmastbergen]

@bmastbergen what do you think about making this work with the Kernel CI Workflow instead of having it's own PR creation or testing steps? I'm not thinking about doing this optimization right now but I feel we can do this in future.

@shreeya-patel98 Yea, eventually this should probably morph into using that. But I've actually been wondering if both the clk-rebase workflow and our build-and-test workflows shouldn't be converted over to use kt. For this workflow that could be as simple as something like 'kt checkout clk-6.12 && kt vm clk-6.12 --test'. And then use a common PR creation workflow.

In the future.....

[PlaidCat]

Should we just enable these by default?

I'm not found of 9P so I'm not keep on providing support BUT VIRTIO stuff seems pretty much like an easy win, and OVERLAY_FS

[bmastbergen]

I did wonder about just enabling these things by default. I'm not 100% we need all of these for our particular usecase, this is just all of the configs the vng turns on if I use it to create the config. TODO: investigate what is actually necessary here

[PlaidCat]