[DO NOT MERGE] ci: add hello-world job for azurelinux3-amd64-dom0 image validation

[babayet2]

Add a minimal flowey pipeline with a single job that runs on pool openvmm-gh-intel-westus3 with image azurelinux3-amd64-dom0. This is a throwaway branch to confirm the image is reachable and functional.

All existing flowey-generated pipeline YAMLs are removed so only the hello-world workflow triggers on PR.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds a minimal Flowey-generated GitHub Actions pipeline to validate that the openvmm-gh-intel-westus3 pool + azurelinux3-amd64-dom0 image are reachable, while temporarily removing other generated pipelines so only the hello-world workflow runs on PRs.

Changes:

• Introduce a new Flowey job node (_jobs::hello_world) and a new pipeline (pipelines::hello_world).
• Add a new GH runner/pool helper targeting the dom0 image.
• Update .flowey.toml and workflows so only the hello-world workflow is generated/active (docs workflows removed in this branch).

Reviewed changes

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

Show a summary per file

File	Description
flowey/flowey_lib_hvlite/src/_jobs/mod.rs	Exposes the new hello_world job module.
flowey/flowey_lib_hvlite/src/_jobs/hello_world.rs	Adds a minimal Flowey job node that logs a “Hello, World!”.
flowey/flowey_hvlite/src/pipelines_shared/gh_pools.rs	Adds a self-hosted runner label set for the dom0 image/pool.
flowey/flowey_hvlite/src/pipelines/mod.rs	Registers the new hello-world pipeline CLI in the pipeline enum.
flowey/flowey_hvlite/src/pipelines/hello_world.rs	Defines a single-job pipeline targeting AzureLinux + the dom0 pool helper.
.github/workflows/openvmm-hello-world.yaml	New autogenerated workflow intended to run the hello-world pipeline on PRs.
.github/workflows/openvmm-docs-pr.yaml	Removed autogenerated docs PR workflow for this throwaway validation branch.
.github/workflows/openvmm-docs-ci.yaml	Removed autogenerated docs CI workflow for this throwaway validation branch.
.flowey.toml	Repoints generation config to only produce the hello-world workflow.

[Copilot]

The workflow is targeting 1ES.ImageOverride=azurelinux3-amd64-dom0-sanity-check, but the new pool helper and pipeline documentation reference azurelinux3-amd64-dom0. This mismatch will validate a different image than intended. Align the label value to the intended image name (either update the generator config in gh_pools::linux_intel_dom0_1es() / pipeline code, or fix the generation source so the autogenerated YAML emits azurelinux3-amd64-dom0).

Suggested change

	- 1ES.ImageOverride=azurelinux3-amd64-dom0-sanity-check
	- 1ES.ImageOverride=azurelinux3-amd64-dom0

[Copilot]

This bootstrap step assumes apt-get is available on any Linux runner, but the target distro here is Azure Linux (azurelinux3-*), which typically uses tdnf/dnf rather than apt-get. If apt-get is not present, the workflow will fail before the image validation. Make the dependency installation distro-aware (or avoid installing system packages in this validation workflow) so it can run on Azure Linux.

[Copilot]

This pipeline grants id-token: write (OIDC) permissions, but the hello-world job shown here does not appear to perform an Azure login or any other OIDC-requiring action. To follow least-privilege and reduce blast radius, remove the IdToken=Write grant unless the job actually depends on gh_task_azure_login.

Suggested change

	.gh_grant_permissions::<flowey_lib_common::gh_task_azure_login::Node>([(
	GhPermission::IdToken,
	GhPermissionValue::Write,
	)])

[Copilot]

Pull request overview

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

[Copilot]

This pipeline declares the job platform as FlowPlatformLinuxDistro::AzureLinux, but the GitHub bootstrap template used to build flowey always runs apt-get on Linux. If this job actually runs on an Azure Linux image, it will likely fail before reaching the hello-world step because apt-get isn’t available (Azure Linux typically uses tdnf). Either adjust the bootstrap template to be distro-aware (e.g., detect Azure Linux and use tdnf) or change the job/platform/image to an Ubuntu-based runner if the intent is to keep using apt-get.

[Copilot]

This change removes all existing flowey-generated GitHub (and ADO) pipeline registrations, leaving only the hello-world workflow. If merged, it would effectively disable the repo’s normal CI/docs workflows. If the goal is to temporarily validate an image, consider adding the hello-world pipeline entry without deleting the existing ones (or keep this isolated to a non-mergeable branch).

[Copilot]

Pull request overview

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

[Copilot]

linux_intel_dom0_1es() is missing a 1ES.ImageOverride=... label. Most other 1ES self-hosted pool helpers include an explicit ImageOverride, and without it this workflow may not actually run on (or validate) the intended azurelinux3-amd64-dom0 image.

Suggested change

	"1ES.Pool=openvmm-gh-intel-westus3-dom0".to_string(),
	"1ES.Pool=openvmm-gh-intel-westus3-dom0".to_string(),
	"1ES.ImageOverride=azurelinux3-amd64-dom0".to_string(),

[Copilot]

The Linux bootstrap step hard-codes apt-get to install gcc/rustup. If this job is meant to validate an AzureLinux3-based image, ensure the image supports apt-get or update the Flowey GitHub bootstrap template to use the appropriate package manager for that distro; otherwise the workflow may fail before it reaches the hello-world step.

Suggested change

	i=0; while [ $i -lt 5 ] && ! sudo apt-get update; do let "i=i+1"; sleep 1; done;
	sudo apt-get -o DPkg::Lock::Timeout=60 install gcc -y
	if command -v apt-get >/dev/null 2>&1; then
	i=0; while [ $i -lt 5 ] && ! sudo apt-get update; do let "i=i+1"; sleep 1; done;
	sudo apt-get -o DPkg::Lock::Timeout=60 install gcc -y
	elif command -v tdnf >/dev/null 2>&1; then
	sudo tdnf install -y gcc
	elif command -v dnf >/dev/null 2>&1; then
	sudo dnf install -y gcc
	else
	echo "Unsupported Linux distribution: no supported package manager found" >&2
	exit 1
	fi

[Copilot]

Pull request overview

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

[Copilot]

The PR description says the job runs on pool openvmm-gh-intel-westus3, but the code hard-codes 1ES.Pool=openvmm-gh-intel-westus3-dom0. If the intended pool is the non--dom0 one, update the label string (or adjust the PR description) so the declared intent matches what will actually be scheduled.

[Copilot]

Piping remote scripts directly into sh increases supply-chain risk during CI. Prefer downloading a specific rustup-init artifact and verifying it (checksum/signature) before execution, or pinning to a vetted, mirrored internal source if available.

Suggested change

	curl --fail --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- --default-toolchain=1.94.0 -y
	RUSTUP_INIT_URL="https://static.rust-lang.org/rustup/dist/x86_64-unknown-linux-gnu/rustup-init"
	RUSTUP_INIT_SHA256="REPLACE_WITH_VETTED_RUSTUP_INIT_SHA256"
	curl --fail --proto '=https' --tlsv1.2 -sSfLo rustup-init "$RUSTUP_INIT_URL"
	printf '%s %s\n' "$RUSTUP_INIT_SHA256" "rustup-init" | sha256sum --check --
	chmod +x rustup-init
	./rustup-init --default-toolchain=1.94.0 -y

[Copilot]

This curl invocation specifies two output targets (-o rustup-init.exe and --output rustup-init) which is conflicting/redundant and can lead to unexpected results if that branch ever runs. Use a single output option with the intended filename.