-
-
Notifications
You must be signed in to change notification settings - Fork 18
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
Support full automatic asset guess even when 'AssetName' is not provided #50
Comments
This is needed because in the new release we also generate SHA256 sums and those assets could be found before the actual archive. So I specify the asset name more precisely. I guess we need #50 to address this problem gracefully 😮💨 ### Additional tasks - [ ] Documentation for changes provided/changed - [ ] Tests added
I propose the following design for better maintainability and understandability: Model selection rules as an enum data type in a declarative way and specify rules for each OS. To be more precise, model query as the following type: enum Rule {
/// Asset name should contain a specified substring
Substring(String),
/// Asset name shouldn't contain a specified substring
Exclude(String),
/// Both rules should be satisfied
And(Box<Rule>, Box<Rule>),
/// At least one rule should be satisfied
Or(Box<Rule>, Box<Rule>),
} Then, one can easily implement a recursive function for matching a string with a rule: fn match(rule: Rule, s: &str) -> bool { ... } A possible rule for macOS could look like this with some eDSL capabilities (after implementing Substring("apple-darwin") & (Substring(".zip") | Substring(".tar.gz")) & Exclude(".sha256") & Exclude(".md5") Then, we just define such rules for each OS. And, ideally, users of However, users still might want the ability to override the default rules for specific assets in case our rules don't cover their use case or some specific tool. So there's an open question: how much of this eDLS do we want to expose to users? Maybe we should just add another constructor like cc @MitchellBerend @slyshykO What do you think? |
I like this idea, not operations in regex are a real pain to do. I think the implementation of this feature depends on how much of the functionality we want exposed to the user. I think regex is common enough to assume users already know how to write correct patterns. |
CLI tools on GitHub releases follow common naming schemes.
tool-sync
could guess asset names from releases without the need to specify part of the name.The text was updated successfully, but these errors were encountered: