-
Notifications
You must be signed in to change notification settings - Fork 24
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
Add guide for writing a Provider
?
#2
Comments
(Disclosure: my interest here is that it would be nice to add a GitLab provider which works similarly to the GitHub provider, downloading released artifacts built by CI from a GitLab instance) |
From the current docs:
Relatedly, I don't think that we are ready to commit to the contract of
Yes, that is correct. |
Totally makes sense regarding not wanting to commit to the There's also the fact that so far the docs for Dotslash appear to be focused on users of it, not contributors to it, so docs on how to write a Thanks! Happy to consider this issue resolved for now then. |
@alilleybrinker FYI, I just put up an RFC for this: #7. |
Summary: it's been a while since the last update of [rstest](https://docs.rs/rstest/latest/rstest/index.html) and and there's been many new features: https://github.com/la10736/rstest/releases NOTE: It appears that the "crate-name" feature is not compatible with non-cargo builds as the one requiring a materialized Cargo.toml file ([source #1](https://github.com/la10736/rstest/blob/v0.24.0/rstest_macros/src/render/crate_resolver.rs#L9), [source #2](https://github.com/bkchr/proc-macro-crate/blob/master/src/lib.rs#L185-L186)). For that reason, I'm opting-out from that feature and enabling the rest of them ([list](https://docs.rs/crate/rstest/latest/features)), which is "async-timeout". Reviewed By: dtolnay Differential Revision: D69493566 fbshipit-source-id: 715cb1706b4f304f26b878250fe60708cc2142bd
It looks like new providers could be added in the following way:
Provider
trait (seeGitHubReleaseProvider
)get_provider
impl forDefaultProviderFactory
inmain.rs
.It would be nice to have this reflected in the documentation!
If y'all are open to contributions, I'd be happy to take a crack at it. Looks like the docs themselves are built with Docusaurus, which shouldn't be difficult to work with.
My only question to validate at the moment is the proper handling of the provider config. It looks like the intent is that the provider config is given as a valid "loosely parsed" JSON value, which the provider itself is then able to deserialize into any specific structure it likes. Do I have that right?
The text was updated successfully, but these errors were encountered: