-
Notifications
You must be signed in to change notification settings - Fork 0
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 base for Rust CI #1
Conversation
90b2af3
to
d17bcee
Compare
# with their own lockfile, rather than the version specified in this library's lockfile | ||
# remove this ignore rule if your package has binaries to ensure that the binaries are | ||
# built with the exact set of dependencies and those are up to date. | ||
update-types: |
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.
Do we want to ignore minor and patches?
I believe we don't distribute optd as a library.
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 don't distribute optd as a library now, but we likely will in the future (we want optd to be both a service and an embeddable library)
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.
Yes, but it will start as a service. So we should get notified imo.
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.
Actually I think it is the other way around right now, we will start as a library and then turn it into a service (we don't want to figure out our entire API immediately and keeping it as a library with a single process keeps it simple)
Also, this distinction has nothing to do with if we want to be aware of minor version updates or patches: even if we were to build a binary, we would only really want to know about specific binary dependencies, not the library crate dependencies the binary crate itself would depend on. So that doesn't really make sense for this project.
- package-ecosystem: cargo | ||
directory: / | ||
schedule: | ||
interval: daily |
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.
Daily is too much in the case we remove minor & patches.
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.
The checks are daily but we only receive a notification if something is likely wrong
The basis for the CI here is taken from https://github.com/jonhoo/rust-ci-conf/. See
DOCS.md
for more information.I added a temporary
optd-tmp
crate that we can remove once we figure out what needs to go there.I've commented out the public semver checks as well as the code coverage part so we can easily turn those on later.
Note that this intentionally strict. Since we have a blank slate, we can amortize the dirty work needed to pass this CI.