-
Notifications
You must be signed in to change notification settings - Fork 140
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: clean up logic around config.toml handling #1222
Closed
+10
−10
Closed
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
With the old version of the task, explicitly passing a non-existent CONFIG_TOML_FILE would result in a failure (intentionally) rather than ignoring the problem and creating an empty config.
IMO that's the saner behavior that one would expect from most tools, but there seems to be a natural pull towards creating the empty config instead (both in your and in Andrew's PRs 😄 )
I'm fine with it either way, the log message should make it clear why e.g. a mis-spelled config file path is being ignored
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.
Aha. Now that you say that, I do remember those iterations two weeks back. I think that the reason that both @ralphbean and myself did that is because it enables cleaner/clearer logic.
Once I tried to allow failures when a nonexistent file is specified, the logic became more confusing.
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.
See the table for intended behavior from the prior PR: #1171 (comment)
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.
I wouldn't say it enables cleaner logic, it's just a touch easier to make it clean. Can still be clean and behave nicely though
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.
I fear I've made a mess. I wasn't aware of the conversations you guys had the other week about this and I assumed this section of code was just carelessly written in the first place during fast-hacking to make vm building work in early June, when in reality you guys had really thought it through. The code was written more recently than I knew!
My real goal here was to get https://gitlab.com/redhat/rhel-ai/disk-images/nvidia-bootc/-/commit/3ab9e272069e9469abc2ace36bf11b63a438f456 to happen - and it did.
I'm inclined to drop this PR without merging it, just to let it exist as you guys defined it in #1171 (comment). WDYT?
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 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.
@ralphbean , @chmeliik 's suggestion above is similar to what you proposed. It still defines the failure criteria and clearly describes why a failure happens instead of falling back to other processes to fail (i.e. rsync). I think this would still be an improvement.
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.
Ack, if we adopt that - we'll need a version bump per this comment, true?
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.
No, If the only failure is a user specifying a file path that does not exist then that is consistent. The breaking change previously is if no file was specified. We would not create an empty file for them.