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.
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
feat(RELEASE-1252): make run-file-updates task idempotent #727
base: development
Are you sure you want to change the base?
feat(RELEASE-1252): make run-file-updates task idempotent #727
Changes from all commits
4df7129
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
What does this do? Can you add a comment explaining what it will print?
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.
It's to deal with a line like "@@ -4,7 +4,7 @@ $schema: /app-interface/app-interface-settings-1.yml". Usually it should be "@@ -4,7 +4,7 @@" in a line and " $schema: /app-interface/app-interface-settings-1.yml" in a seperated line.
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 still don't get it 😂 but can you make that comment in the code? This will be lost once this is merged
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.
OK. Added a 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.
It seems to me this whole logic is only for the use case that there is replacement to be done, but maybe one of the open MRs already contains it. That's definitely a valid use case.
But what if the change has already been merged? Then we will probably fail on line 235, saying there is nothing to change, right? But if you run the same release repeatedly, that use case shouldn't fail.
Now the question is how to handle this - we will need to separate these two cases:
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.
How to differentiate the MR is merged and the file doesn't need to be changed at all? Do we still need to check the merged PRs?
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.
We might need to discuss this with the whole team to decide how to handle this. Originally when this was implemented, the idea was that if there is nothing to be updated, then there's definitely something wrong. But now that we want to take a release pipeline rerun into account, we shouldn't automatically fail on this. We will need to be more granular. If we can find the file to update and then we search for the line to update and find it, but the line already contains the target string, then that's still ok. We only fail if we cannot find the file to update or cannot match the line to update.
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 guess that would be one way to handle it. But probably not necessary. It would be difficult to decide how far into the history we want to go.
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.
IMO, if the "goal string" aka the string you are trying to insert already exists in the proper file, exit 0. No need to check merged MRs. If an MR is open with the exact change already, say that (idempotent) and exit 0 (ideally printing the existing MR url). If the file to be changed doesn't exist, exit 1. I think this is in agreement with what Martin has been commenting
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.
But yes, the case where the change is already merged seems already addressed. It just has to be updated to no longer fail (the line 235 piece Martin mentioned)
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.
If only the return value is changed from "Failed" to "Success" in the block of "line 235", the test case of "test-process-file-updates-replacements-error.yaml" fails. I added a variable of "keyNotFound" to check if the key is correct. And if the file is not valid, it's handled in line 157. Is that ok?
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 am reading through what the script does and I am not sure now. Until now, if a key is not found, that replacement will be skipped, but at the end we check that at least one replacement happened, otherwise we fail.
So yes, I think what you say sounds correct - we should fail if we cannot find the target file or the target key. But if those are found and there is no diff once the replacement is applied, it's still ok.
But I noticed there is also this
seed
option. It seems that one should be ok - if you run it again, it will just override the file with the seed string again, so there will be no diff. Previously this would fail on "no diff", but as we said, we will no longer fail on "no diff".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 didn't change the logic of seed/replacement before, just add/set the "keyNotFound" variable. If there is no replacement and all the keys can be found, it return true because the MR may be merged. If some key can't be found, it fails.