The field osType: OperatingSystemFamily in job/attachments/manifests is currently being used just to determine how to handle the rootPath (i.e., is it 'posix' or 'windows',) in the API, so it follows more closely with the path mapping rules rather than storage profiles. The field osType in job attachment settings should be renamed to something else, to avoid inconsistencies around the usage of osType, osFamily, and whatever encapsulates 'windows' vs. 'posix' paths.
What was the solution? (How)
Renamed the field osType -> rootPathFormat
What is the impact of this change?
The field has a better/less-confusing name.
How was this change tested?
Ran unit tests: hatch run lint && hatch run test
Ran integ tests from deadline-cloud: hatch run integ:test
⚠️ This change is not ready to be merged yet 🙏
What was the problem/requirement? (What/Why)
The field
osType: OperatingSystemFamilyin job/attachments/manifests is currently being used just to determine how to handle the rootPath (i.e., is it 'posix' or 'windows',) in the API, so it follows more closely with the path mapping rules rather than storage profiles. The fieldosTypein job attachment settings should be renamed to something else, to avoid inconsistencies around the usage ofosType,osFamily, and whatever encapsulates 'windows' vs. 'posix' paths.What was the solution? (How)
osType->rootPathFormatWhat is the impact of this change?
The field has a better/less-confusing name.
How was this change tested?
hatch run lint && hatch run testhatch run integ:testWas this change documented?
No.
Is this a breaking change?
Yes!