-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(job_attachment)!: Change osType and source_os names #37
Conversation
aeb1efa
to
7abe659
Compare
03ad36f
to
e2e4fe4
Compare
# TODO: remove sourceOs and make sourcePathFormat required | ||
sourceOs: NotRequired[str] | ||
"""The operating system family (posix/windows) associated with the source path""" | ||
|
||
sourcePathFormat: NotRequired[str] |
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 above todo mentions that this should be made required, is that no longer true? Just want to make sure we didn't miss something
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.
Thank you for pointing that out. It appears, as you mentioned, this sourcePathFormat
is defined as required in the backend service model. I will fix it in the next revision.
BREAKING CHANGES: - Renamed the field `osType` -> `rootPathFormat` - The workarounds that allowed the use of `source_os` in the path mapping rules are removed. Signed-off-by: Gahyun Suh <[email protected]>
e2e4fe4
to
503484c
Compare
BREAKING CHANGES: - Renamed the field `osType` -> `rootPathFormat` - The workarounds that allowed the use of `source_os` in the path mapping rules are removed. Signed-off-by: Gahyun Suh <[email protected]> Signed-off-by: Graeme McHale <[email protected]>
BREAKING CHANGES: - Renamed the field `osType` -> `rootPathFormat` - The workarounds that allowed the use of `source_os` in the path mapping rules are removed. Signed-off-by: Gahyun Suh <[email protected]> Signed-off-by: Graeme McHale <[email protected]>
BREAKING CHANGES: - Renamed the field `osType` -> `rootPathFormat` - The workarounds that allowed the use of `source_os` in the path mapping rules are removed. Signed-off-by: Gahyun Suh <[email protected]> Signed-off-by: Graeme McHale <[email protected]> Signed-off-by: Gahyun Suh <[email protected]>
BREAKING CHANGES: - Renamed the field `osType` -> `rootPathFormat` - The workarounds that allowed the use of `source_os` in the path mapping rules are removed. Signed-off-by: Gahyun Suh <[email protected]> Signed-off-by: Graeme McHale <[email protected]>
BREAKING CHANGES: - Renamed the field `osType` -> `rootPathFormat` - The workarounds that allowed the use of `source_os` in the path mapping rules are removed. Signed-off-by: Gahyun Suh <[email protected]> Signed-off-by: Graeme McHale <[email protected]>
What was the problem/requirement? (What/Why)
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 fieldosType
in 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: OperatingSystemFamily
->rootPathFormat: PathFormat
source_os
in the path mapping rules can now be safely removed."What is the impact of this change?
The field has a better/less-confusing name.
How was this change tested?
hatch run lint && hatch run test
Was this change documented?
No.
Is this a breaking change?
Yes!