-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
Fix CI #11
Conversation
I appreciate the desire here, however using the development version of the tools has a number of consequences -- most notably that still-in-development behaviours could end up committed to the inventory repo and thus foisted upon users who may not have (or even be able) to install that version of the tooling. (I'm also slightly surprised that this works -- the reason that we've not published a new version of the tools is that their build stack is somewhat broken) |
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'm afraid I agree with Peter here. Pinning like this is likely to cause us more headaches in future. Even if what's there now is stable enough for us to use, it might not always be true (although IMO main
should still be reasonably stable, even if not "production-grade").
I see 3 possible ways forward:
- Fix
sr.tools
upstream, ship a release, which should then fix CI here (preferred). - Pin to a specific commit. Sure, it's far from ideal, but at least this way we're at a stable-ish version which will more reliably work, even if we do this whilst going with Option 1.
- Just disable CI. Ignoring CI errors (and communicating that's what people should do) is objectively worse than having no CI.
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 like this totally temporary solution.
Use repo version of sr-tools