ci: add ci workflow #102

yih-redhat · 2025-11-04T06:47:43Z

This pull request:

create CI workflow that will be trigger by new pull request, reopen pull request, commit to pull request.
CI will run device onboarding test on a fedora 43 bootc image, includes:
Setup and start go-fdo-server, includes manufacture, rendevous and owner
build a fedora 43 bootc anaconda-iso image with go-fdo-client installed
provision a vm with anaconda-iso file
device initialize during provision in %post kickstart file
after vm boot, TO0 is triggered manually in vm
after TO0, onboarding is triggered manually in vm

Please be noted the last two steps should run automatically after vm boot, will update test script later once go-fdo-client can do it automatically.

gemini-code-assist · 2025-11-04T06:48:01Z

Summary of Changes

Hello @yih-redhat, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request establishes a foundational Continuous Integration (CI) workflow to automatically validate the FIDO Device Onboard (FDO) process for Fedora bootc images. By integrating this workflow, the project ensures that any new changes are tested against a full device onboarding scenario, from image creation and VM provisioning to the successful completion of the FDO handshake, thereby enhancing reliability and preventing regressions in the critical onboarding path.

Highlights

New CI Workflow: A new Continuous Integration (CI) workflow has been introduced to automate testing processes.
Trigger Conditions: The CI workflow is configured to run automatically on new pull requests, reopened pull requests, and any new commits made to existing pull requests.
Device Onboarding Test: The CI executes a comprehensive device onboarding test specifically designed for Fedora 43 bootc images.
FDO Server Setup: The test environment includes the setup and initiation of the go-fdo-server components, covering manufacturer, rendezvous, and owner services.
Custom Bootc Image Creation: A custom Fedora 43 bootc anaconda-iso image is built, which includes the go-fdo-client pre-installed for the onboarding process.
VM Provisioning and Initialization: A virtual machine is provisioned using the custom ISO, with device initialization handled automatically during provisioning via a kickstart file.
Manual TO0/Onboarding (Temporary): Currently, the TO0 (Transfer of Ownership) and subsequent onboarding steps are manually triggered within the VM, with a clear plan to automate these steps in a future update.

Ignored Files

Ignored by pattern: .github/workflows/** (1)
- .github/workflows/integration.yml

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

gemini-code-assist

Code Review

This pull request introduces a new CI workflow for integration testing go-fdo-server. The workflow sets up a test environment, builds a custom bootc ISO image, provisions a VM, and runs FDO onboarding tests. While this is a great addition for automated testing, the review has identified a critical security vulnerability due to a committed private SSH key. Additionally, there are several high and medium severity issues concerning script robustness, resource management, and maintainability that should be addressed to make the CI process more reliable and secure.

test/fmf/tests/key/ostree_key

test/fmf/tests/integration.sh

test/fmf/tests/integration-setup.sh

test/fmf/tests/integration.sh

yih-redhat · 2025-11-07T07:24:28Z

Hi @mmartinv , I found the integration test script in this pull request is also executed in e2e test (which should not) and caused failures in check jobs.
I suspect maybe the reason is that e2e test plan does not specify the test case names at https://github.com/fido-device-onboard/go-fdo-server/blob/main/test/fmf/plans/e2e.fmf#L4 , so it just run all the tests. But I'm not sure, could you please help to confirm this?

mmartinv

Is there a reason why we do not use current packit integration instead of testing-farm-as-github-action so we don't have to build the RPMs twice? If we use packit integration the correct server rpms will be already installed, we don't need to install them.

The test uses functions from the utils.sh but the test doesn't look like existing tests at all. Would it be possible to move all the common functions to the utils.sh file and make the proper integration?

mmartinv · 2025-11-26T10:13:43Z

test/fmf/plans/bootc-e2e.fmf

+
+discover:
+    how: fmf
+    test: bootc-test-onboarding


Suggested change

test: bootc-test-onboarding

filter: tag:bootc

Similar change needs to be done for rpm-e2e plan

mmartinv · 2025-11-26T10:14:04Z

test/fmf/tests/bootc-test-onboarding.fmf

+tag:
+  - fdo
+  - e2e
+  - onboarding


Suggested change

- onboarding

- onboarding

- bootc

Similar change needs to be done to all the rpm tests so we can filter the tests by a meaningful tag

mmartinv · 2025-11-26T10:25:01Z

test/fmf/plans/bootc-e2e.fmf

+      processors: ">= 2"
+    memory: ">= 6 GB"
+    disk: ">= 20 GB"


This seems to be wrong, just add the required CPUs/Memory/Disk, no >= symbols

Without >=, tmt reports error when prepare vm.
With >=, tmt is more flexible to provide vms.

mmartinv · 2025-11-26T10:32:49Z

test/bootc/utils.sh

+    sed -i "/%post --erroronfail/i\
+sshkey --username admin \"${ssh_key_pub}\"" "${new_ks_file}"
+    sed -i "/bootc switch/a\
+go-fdo-client --blob /boot/device_credential --debug device-init http://${manufacturer_ip}:8038 --device-info=iot-device --key ec256" "${new_ks_file}"


Suggested change

go-fdo-client --blob /boot/device_credential --debug device-init http://${manufacturer_ip}:8038 --device-info=iot-device --key ec256" "${new_ks_file}"

go-fdo-client --blob /boot/device_credential --debug device-init ${manufacturer_protocol}://${manufacturer_ip}:${manufacturer_port} --device-info=iot-device --key ec256" "${new_ks_file}"

mmartinv · 2025-11-26T10:35:27Z

test/bootc/utils.sh

+  configure_libvirt
+
+  # Configure firewall
+  configure_firewall


add the libvirtd service and firewalld services to the services array with the variables at the beginning of this file.

services+=("libvirtd" "firewalld")

Then declare the {start,stop,configure}_service_{libvirtd,firewalld} functions and implement them.

Tried it after we discussed, but failed due to some kind of libvirt service ip not found error. Didn't remember the exact error message, but seems the configure_service_libvirt seems to look for service ip.

mmartinv · 2025-11-26T10:58:09Z

test/bootc/utils.sh

+    log_info "Install required packages"
+    local packages=(golang make podman jq qemu-img qemu-kvm libvirt-client libvirt-daemon-kvm libvirt-daemon virt-install ansible-core firewalld lorax gobject-introspection)
+    dnf install -y "${packages[@]}"


I would move the installation of each package to the function that needs it and they need to be installed if not running on tmt: if the test is running in tmt the packages must be installed in the prepare section so they are available to all the tests.

Fixed.

install all required packages in tmt plan file.

move packages to functions that needs it, and add condition if [[ ! -v "PACKIT_COPR_RPMS" ]] to install it.

mmartinv · 2025-11-26T11:00:42Z

test/bootc/utils.sh

+    log_info "Adding host entries for FDO services in vm"
+    sudo ssh "${ssh_options[@]}" -i "${ssh_key}" "admin@${guest_ip}" \
+        'echo -e "192.168.100.1 manufacturer\n192.168.100.1 rendezvous\n192.168.100.1 owner" | sudo tee -a /etc/hosts > /dev/null'


Do this in the libvirt configuration function, Please see: https://serverfault.com/questions/976107/how-to-assign-vm-hostname-by-host-definition-in-libvirt-virtual-network-interf

This is to add go-fdo-server hostname and ip address in /etc/hosts file of virtual machine provisioned in the test script, so the go-fdo-client in virtual machine can connect to go-fdo-servers to finish fido device onboard.
I think there is no libvirt configuration in the bootc virtual machine.

mmartinv · 2025-11-26T11:02:34Z

test/bootc/utils.sh

+    local os_variant=$1
+    local boot_args=$2
+    local guest_ip="192.168.100.50"
+    sudo qemu-img create -f qcow2 "/var/lib/libvirt/images/disk.qcow2" 10G
+    sudo restorecon -Rv /var/lib/libvirt/images/
+    sudo virt-install --name="fdo-bootc" \
+        --disk "path=/var/lib/libvirt/images/disk.qcow2,format=qcow2" \
+        --ram 3072 \
+        --vcpus 2 \
+        --network "network=integration,mac=34:49:22:B0:83:30" \
+        --os-type linux \
+        --os-variant "${os_variant}" \
+        --cdrom "/var/lib/libvirt/images/install.iso" \
+        --boot "${boot_args}" \
+        --nographics \
+        --noautoconsole \
+        --wait=-1 \
+        --noreboot
+
+    log_info "Starting VM..."
+    sudo virsh start "fdo-bootc"
+
+    # Wait for SSH
+    if ! wait_for_ssh $guest_ip; then
+        return 1
+    fi
+
+    # FDO onboarding process
+    log_info "Get device initialization voucher guid"
+    guid=$(curl --fail --silent "${manufacturer_url}/api/v1/vouchers" | jq -r '.[0].guid')


Move this to a run_device_initialization function

mmartinv · 2025-11-26T11:03:06Z

test/bootc/utils.sh

+    log_info "Sending Ownership Voucher to the Owner"
+    send_manufacturer_ov_to_owner "${manufacturer_url}" "${guid}" "${owner_url}"
+
+    log_info "Setting or updating Owner Redirect Info (RVTO2Addr)"
+    set_or_update_owner_redirect_info "${owner_url}" "${owner_service_name}" "${owner_dns}" "${owner_port}"
+
+    sleep 60
+
+    log_info "Running FIDO Device Onboard"
+    sudo ssh "${ssh_options[@]}" -i "${ssh_key}" "admin@${guest_ip}" \
+        'set -o pipefail; sudo go-fdo-client --blob /boot/device_credential onboard --key ec256 --kex ECDH256 --debug | tee /tmp/onboarding.log'
+
+    log_info "Check Device Onboard result"
+    result=$(sudo ssh "${ssh_options[@]}" -i "${ssh_key}" "admin@${guest_ip}" 'cat /tmp/onboarding.log')
+    if [[ ! "$result" =~ "FIDO Device Onboard Complete" ]]; then
+        return 1
+    fi
+
+    return 0


Move this to the run_test function

Signed-off-by: Yi He <[email protected]>

gemini-code-assist bot reviewed Nov 4, 2025

View reviewed changes

yih-redhat force-pushed the add-ci branch 2 times, most recently from fce199e to a5d5ddc Compare November 6, 2025 15:18

yih-redhat force-pushed the add-ci branch 2 times, most recently from dcec3dc to 7bcd10d Compare November 18, 2025 08:22

mmartinv reviewed Nov 19, 2025

View reviewed changes

yih-redhat force-pushed the add-ci branch 10 times, most recently from 7447a65 to a7bf865 Compare November 26, 2025 09:54

mmartinv reviewed Nov 26, 2025

View reviewed changes

yih-redhat force-pushed the add-ci branch 6 times, most recently from 1e61daf to 24f9e68 Compare November 27, 2025 14:52

ci: add ci workflow

b2910e4

Signed-off-by: Yi He <[email protected]>

yih-redhat force-pushed the add-ci branch from 24f9e68 to b2910e4 Compare November 28, 2025 04:38

	go-fdo-client --blob /boot/device_credential --debug device-init http://${manufacturer_ip}:8038 --device-info=iot-device --key ec256" "${new_ks_file}"
	go-fdo-client --blob /boot/device_credential --debug device-init ${manufacturer_protocol}://${manufacturer_ip}:${manufacturer_port} --device-info=iot-device --key ec256" "${new_ks_file}"

ci: add ci workflow #102

Are you sure you want to change the base?

ci: add ci workflow #102

Uh oh!

Conversation

yih-redhat commented Nov 4, 2025

Uh oh!

gemini-code-assist bot commented Nov 4, 2025

Summary of Changes

Highlights

Footnotes

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

yih-redhat commented Nov 7, 2025

Uh oh!

mmartinv left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yih-redhat Nov 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

yih-redhat Nov 27, 2025 •

edited

Loading