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
Adds remote .zip archive support to pulumi new
#14443
Conversation
Changelog[uncommitted] (2023-10-31)Features
|
61bb8fe
to
5ce130d
Compare
Added |
5ce130d
to
b5c6a9e
Compare
b5c6a9e
to
2ea8a1f
Compare
My suggested approach for this feature is a bit different from what is implemented here.
This avoids coupling details of AI to the Pulumi new feature, and maintains more flexibility to iterate and improve on the Pulumi AI server side, while exposing a more generally useful and foundational capability in the CLI. Thoughts? |
I considered this approach initially, but wanted to avoid building an API that would be difficult to iterate upon and test - providing the data in a structured format as I've done here has made it much simpler to work on prompt engineering, etc, while (with @Frassle 's prompting) keeping the logic in the CLI as simple as possible - we just need a list of filenames and contents which the CLI writes in the same place it would expect a standard template to exist. Notably, this does not couple the CLI to "AI" other than nominally in this case. We could just as easily rename all of these concepts and consider this a "REST standard" for Pulumi templates. I suppose we could add a layer which, rather than returning the JSON we see here, returns the same contents as an archive, but it does make the API a bit more opaque (and any contracts provided by the service more difficult to enforce). I'd personally prefer to stick to structured data where we can, but I acknowledge the value you mention as well. |
This seems fine to me. Could then just allow any http://host/path.zip url.
I'm not sure I really follow why a zip file is any harder to test than the JSON files? A template is just a file tree, I don't think the CLI will ever accept anything more than that (given the constraints of what git gives us). A zip file seems a perfectly good representation of a file tree. Why does this make testing the AI service harder? |
It's not about the CLI when it comes to testing the service - if we're relying on the CLI for all of our iteration and testing, or worse, manually extracting an archive and checking the files each time, it's just going to be too slow. As I describe above, we can provide the capability to download a zipfile, but if we're already providing all of the required data in a way that provides some amount of structural guarantees, what's the downside? Do we have users asking to Anyway, I mentioned a possible middle-ground above. We can easily use an |
2ea8a1f
to
f39222e
Compare
f39222e
to
ac7884a
Compare
ai://
scheme support to pulumi new
pulumi new
d95a734
to
d2f39fa
Compare
…zipfiles We depend upon the user to provide a URL with a .zip suffix in order to determine which methodology to use, and assume the API serves this artifact on a PUT endpoint at the given path. We also provide a clean passthrough of any query parameters, though providing those on the command line can be a bit cumbersome.
d2f39fa
to
f13801c
Compare
I like the simplicity of the ZIP approach here. Two things:
|
Absolutely - just added a description above. Will add tests now. |
Probably reasonable to add the changelog entry for this now as well? |
Since it's not tied to AI, I suppose we can. Do we want to consider the API contract (GET |
Yeh that seems reasonable to me. |
a04b05a
to
e788c30
Compare
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.
Just a question on the URL handling, the Zip test looks good though with the mock server.
e788c30
to
fd084eb
Compare
Description
Fixes https://github.com/pulumi/pulumi.ai/issues/363
This change introduces a new accepted suffix to
pulumi new
HTTP arguments -.zip
.When a URL of the form
http[s]://<url>.zip
is provided topulumi new
, we send a GET request to<url>
(without the .zip suffix) with theaccept
header set toapplication/zip
. It is then up to whatever is hosted at that location to correctly return a binary zip archive in its response.We then parse that response in memory and write each file to a tempdir as we do with current templates, which can then be picked up by the standard
pulumi new
templating logic.Checklist
make tidy
to update any new dependenciesmake lint
to verify my code passes the lint checkgofumpt
make changelog
and committed thechangelog/pending/<file>
documenting my change