-
Notifications
You must be signed in to change notification settings - Fork 7
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great progress, and I like what I see so far! This is obviously the trickiest part of the implementation. You have a few formatting errors that the auto-checker caught, but I think those should be easy to fix. I have a few additional comments below.
|
||
def mock_run_cmd_fail(*args, **kwargs): | ||
""" | ||
Mock run_cmd for a Rigado Cascade 500 device (201810-26506), which doesn't |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no need for specific device data in places like this, please remove things like this.
|
||
def mock_run_cmd_unsupported(*args, **kwargs): | ||
""" | ||
Mock run_cmd for an Intel Desktop device (201808-26453), which doesn't |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's no need for specific device data in places like this, please remove things like this.
return ( | ||
255, | ||
"", | ||
"ssh: connect to host 10.102.161.93 port 22: No route to host", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
replace with some simpler fake IP that's easier to read for things like this - it's all mock data anyway
@@ -0,0 +1,387 @@ | |||
""" fwupdmgr json outputs """ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The data here seems very specific, and I'm guessing we grabbed it from a fwupdmgr run to use as test data. Can you add a few details in the comments here about how it was extracted, just in case the format ever changes and we need to update the unit test data?
@nancyc12 also here - we'll need to redo this patch against https://github.com/canonical/testflinger, let me know if there's anything I can do to help. |
@plars copy that. |
Move the changes to canonical/testflinger#141 |
Description
Base on CR033 - Firmware updates for regression testing, introduce a new optional phase firmware_update after provision phase to handle request for firmware update on the device. As in the spec, this new phase is implemented in
DefaultDevice
, so it won't need any change on existingDeviceConnector
codes.To trigger firmware_update phase, the following section needs to be provided in job.yaml. If the
firmware_update_data
section is missing from the job, this phase will not run.Variables in
firmware_update_data
:version
: The desired firmware level on the device. Currently it only supportslatest
(upgrading all components in the device with the latest firmware release). More options are planned to be implemented in the future once we gathering data for working firmware baseline on devices.ignore_failure
: When set tofalse
, Testflinger Agent will suspend the job if firmware_update phase return a status other than 0, which implies there's a failure during firmware_update phase. If set totrue
, the job will continue regardless the status of firmware_update phase.Code changes
Add
firmware_update
phase inDefaultDevice
to handle the firmware update for all childDeviceConnector
class. It will gather DMI chassis_vendor and chassis_type from the DUT to decide whether firmware update is applicable. The current support scope is limited the devices as below.In order to make it work as a whole, there're also PRs raised in testflinger and testflinger-agent.
Resolved issues
N/A
Documentation
Covered in testflinger monorepo.
Tests
It's tested by building a dev testflinger server with docker along with modified testflinger-agent and snappy-device-agents.