-
Notifications
You must be signed in to change notification settings - Fork 855
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: normalize path for creation rules #1523
base: main
Are you sure you want to change the base?
Conversation
Signed-off-by: Sizhe Zhao <prc.zhao@outlook.com>
Signed-off-by: Sizhe Zhao <prc.zhao@outlook.com>
535c0df
to
1aabe5c
Compare
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.
Thanks for your contribution!
@@ -368,6 +368,8 @@ func parseCreationRuleForFile(conf *configFile, confPath, filePath string, kmsEn | |||
|
|||
// compare file path relative to path of config file | |||
filePath = strings.TrimPrefix(filePath, configDir+string(filepath.Separator)) | |||
// replace \ with / | |||
filePath = filepath.ToSlash(filePath) |
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.
For everyone using regexes that support both Windows and Unix paths, this is not a breaking change. But for users that use Windows paths exclusively and wrote their regexes that way, it's a breaking change since their regexes won't work anymore.
To avoid breaking changes, we'll have to (for some time) keep the old behavior, but warn the user if it will change in the future. So better do something like:
filePath = filepath.ToSlash(filePath) | |
filePathAlt := filepath.ToSlash(filePath) |
here, and below before calling reg.MatchString(filePath)
do newMatch := reg.MatchString(filePathAlt)
and then emit a warning if it's value is different from reg.MatchString(filePath)
.
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.
Let's also add a option to silence that warning (by opting in to the new behavior).
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.
In Ansible we usually proceed as follows:
- Add a new option that allows to select the behavior. The default is the old behavior.
- A version later, deprecate the option's default value - i.e. start warning the user if they didn't specify a value for that option and if the change to the new default would produce a change. Then users have time to figure out whether they prefer the old or new behavior, and can explicitly set the option to the value they prefer (and as soon as it has a value, there will be no more warnings).
- Eventually flip the default of the option to the new value.
@getsops/maintainers what do you think, and what would you prefer?
Fixes #1036.
This may be a breaking change. 🤔