-
Notifications
You must be signed in to change notification settings - Fork 29
Allow for configuring a specific CML version #255
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
Conversation
|
I feel like this sort of thing (deps & versions of deps) should be part of the user's startup script or task instead... Should TPI really be particularly CML-aware? |
|
This suggestion is not applicable to the Although, the legacy |
|
Still, we1 chose to keep CML under the same minor version and avoid introducing breaking changes, so in theory, there shouldn't be any need of pinning it. Footnotes
|
|
I'll play with task today, and I have a few ideas how I want to use it. |
|
@dacbd I think that might be very interesting. CML should be backwards compatible, at least thats the philosophy but since we allow to pin in Just only one possible issue: Any thoughts @dacbd @iterative/cml ? |
|
I think it depends on how it's executed. I haven't really experienced any issues with the node deps with CML but I am well aware of the issues the ecosystem can have, plus it makes installing/portability simpler which I feel is your guys targeted goal. I see/have no issues against a standalone CLI. I personally feel that tools like these should have strong control/influence on their dependencies. I did a lot of work with the hapi.js framework a long time ago and their control over their dependencies offered a stable product than others. You never know what bonehead doesn't have 2FA on their npm account and now your dependency has a crypto-miner or a package.json build script dialing home, granted these things get caught pretty fast these days, and realistically they normally have a low impact but the damage to the "name" is done anyway. |
|
Since v0.10.0 (iterative/cml#825), CML can be installed as a single, standalone binary file. |
|
I'll take a look, plan to incorporate something this weekend that you can take a look at. |
|
I'd even remove the “classical” NPM support and include only the required logic for downloading binary releases. Apart from that, looks good to me! 🎉 @iterative/cml? |
This part of my covert 🔐 effort to make testing custom changes(in cml/tpi) easier (npm provides a convenient method for "installing" directly from a git ref), but that is secondary to actual function. 😄 |
|
Tip: |
|
I will make a couple house cleaning changes tonight and mark it ready. (saw at least one empty line that was superfluous) |
|
Boy, can I say my brain wasn't working tonight for some reason... After brute-forcing myself back to functional with some hacky e2e testing, I formed a couple questions: Should this be updated further? terraform-provider-iterative/iterative/resource_runner_test.go Lines 35 to 70 in 35ce161
Should Installing CML be part of Should that script actually log into that file? I'm fairly confident that I have unbroken all the things I broke. I tested it with aws/gcp (gcp lets you view the startup script the instance was made with which was nice) no longer relevant.
lol wut google error?I saw the instance appear with a spinning status in the GCP dashboard but they spit this error out... https://gist.github.com/dacbd/41b9821c200dd38709a3f671b830ac49 |
d058a74 to
7dd4915
Compare
|
Made a
|
I haven't played with the task branch yet so, with those changes in mind how relevant would the following be?
I want to be able to target a specific cml version here:
terraform-provider-iterative/iterative/resource_runner.go
Line 288 in 8121c66
adding an optional
cml_version/ defaulting to@dvcorg/cmlterraform-provider-iterative/iterative/resource_runner.go
Lines 409 to 433 in 8121c66
Thoughts @DavidGOrtega @0x2b3bfa0 ?