Update install page, changelog, and quickstarts for v0.12.0 - #227
Conversation
|
@lukehoban Merging now, but I'm still interested in your feedback. |
|
|
||
| ### Added | ||
|
|
||
| - Add a `pulumi cancel` command ([pulumi/pulumi#1230](https://github.com/pulumi/pulumi/pull/1230)). This command cancels any in-progress operation for the current stack. Note that the target stack may need to be manually repaired via `stack export` and `import`. |
There was a problem hiding this comment.
I'd leave off the last sentence - that's somewhat orthogonal - and in the cases it matters, is communicated to the user in context.
| ### Changed | ||
| - (**Breaking**) Eliminate `pulumi init` requirement ([pulumi/pulumi#1226](https://github.com/pulumi/pulumi/pull/1226)). The `pulumi init` command is no longer required and should not be used for new stacks. For stacks created prior to the v0.12.0 SDK, `pulumi init` should still be run in the project directory if you are connecting to an existing stack. For new projects, stacks will be created under the currently logged in account. After upgrading the CLI, it is necessary to run `pulumi stack select`, as the location of bookkeeping files has been changed. For more information, see [Creating Stacks](../reference/stack.html#create-stack). | ||
|
|
||
| - (**Breaking**) Remove the explicit 'pulumi preview' command ([pulumi/pulumi#1170](https://github.com/pulumi/pulumi/pull/1170)). The `pulumi preview` output has now been merged in to the `pulumi update` command. Before an update is run, the preview is shown you can choose whether to proceed or see more update details. To see just the preview operation, run `pulumi update --preview`. |
There was a problem hiding this comment.
"is shown AND you can choose"
|
|
||
| - (**Breaking**) Remove the explicit 'pulumi preview' command ([pulumi/pulumi#1170](https://github.com/pulumi/pulumi/pull/1170)). The `pulumi preview` output has now been merged in to the `pulumi update` command. Before an update is run, the preview is shown you can choose whether to proceed or see more update details. To see just the preview operation, run `pulumi update --preview`. | ||
|
|
||
| - (**Breaking**) Add support for Node 8.10 for Lambda implementations ([pulumi/pulumi-aws#195](https://github.com/pulumi/pulumi-aws/pull/195)). When provisioning an AWS Lambda, the target runtime is Node.js version 8.10, rather than 6.10.2. |
There was a problem hiding this comment.
Lambdas created with aws.serverless.Function and via JavaScript callbacks in @pulumi/cloud now default to Node.js 8.10.
|
|
||
| - (**Breaking**) Add support for Node 8.10 for Lambda implementations ([pulumi/pulumi-aws#195](https://github.com/pulumi/pulumi-aws/pull/195)). When provisioning an AWS Lambda, the target runtime is Node.js version 8.10, rather than 6.10.2. | ||
|
|
||
| - Switch to a more streamlined view for property diffs in `pulumi update` ([pulumi/pulumi#1212](https://github.com/pulumi/pulumi/pull/1212)). When just part of a property has changed, only the changed part is displayed. |
There was a problem hiding this comment.
Can just leave off the second sentence (it's not correct as phrased - the actual change is that we show the old and new on a single line instead of rendering two separate lines)
|
|
||
| - Switch to a more streamlined view for property diffs in `pulumi update` ([pulumi/pulumi#1212](https://github.com/pulumi/pulumi/pull/1212)). When just part of a property has changed, only the changed part is displayed. | ||
|
|
||
| - Allow multiple versions of the `@pulumi/pulumi` package to be loaded ([pulumi/pulumi#1209](https://github.com/pulumi/pulumi/pull/1209)). This change allows a program to use more than one version of `@pulumi/pulumi`. |
There was a problem hiding this comment.
Replace second sentence with "This allows packages and dependencies to be versioned independently".
|
|
||
| 1. Now, let's deploy the program and provision resources, via `pulumi update`. It takes about 30 seconds to | ||
| provision the EC2 instance. While the resources of the stack are being created, you will see a `Running...` progress indicator for the stack component. | ||
| 1. To see the exact resource that will be created, choose the "details" option: |
There was a problem hiding this comment.
Is this needed? Feels like we should only spend time on this if we want to highlight something in the output - which we don't here.
There was a problem hiding this comment.
Yeah, I was unsure as well. I'll remove.
| 1: pulumi:pulumi:Stack s3website-website-testing + create | ||
| 2: aws:s3:Bucket s3-website-bucket + create | ||
| 3: aws:s3:BucketObject favicon.png + create | ||
| 4: aws:s3:BucketObject index.html + create |
There was a problem hiding this comment.
For these tutorials, it's a little awkward that we always have to show both preview and update - since they look in this context like they are duplicating the same thing. I wonder if we should elide the "preview" part to keep things simpler? (or even elide all the output of this step if there's nothing we want to reference here)?
There was a problem hiding this comment.
I did that in later steps, but I should go ahead and do it everywhere in Part 2.
|
|
||
| info: 6 changes performed: | ||
| + 2 resources created | ||
| - 4 resources deleted |
There was a problem hiding this comment.
Looking at a few more of these - it does feel like we could largely skip including full output of CLI commands in this article - just show which commands to run, and summarize what should happen in prose "you will see two resources created, and 4 resources deleted". That may generally streamline the feel of this article significantly.
|
|
||
| The basic idea here is that, after running your usual CI processes upon merging a commit into a release branch, you can | ||
| proceed to doing a Pulumi deployment. This usually entails running `pulumi preview` followed by a `pulumi update`. | ||
| proceed to doing a Pulumi deployment. This usually entails running `pulumi update --preview` followed by a `pulumi update`. |
There was a problem hiding this comment.
Technically - if the goal is to be non-interactive - the latter needs to include --force.
| ``` | ||
|
|
||
| Because the changes are not actually applied during a preview, it is not possible for `pulumi preview` to know for sure whether a change will occur or not when it is dependent on the ouput of some resource being created or replaced. Because of this, `pulumi preview` always presents a conservative summary of the changes that will be applied. This means that when the corresponding `pulumi update` is run, it may observe fewer changes being needed, but will never observe more than what was shown during preview. | ||
| Because the changes are not actually applied during the preview phase, it is not possible for `pulumi update` to know for sure whether a change will occur or not when it is dependent on the output of some resource being created or replaced. Because of this, `pulumi update --preview` always presents a conservative summary of the changes that will be applied. This means that when changes are actually applied, it may observe fewer changes being needed, but will never observe more than what was shown during preview. |
There was a problem hiding this comment.
Might want to use a more abstract "the preview doesn't know" and "the preview always presents" instead of referring to commands, since this concept no longer has it's own dedicated command.
A suggestion is a whole-line replacement, so one landing on a line that also carries a blocker re-commits the blocking text if the author clicks it. Observed on fork PR #227: the 'Simply' suggestion's replacement line still read "Pulumi Service" and "click", both of which the same review had just flagged in 🚨. post-style-suggestions.py now reads .vale-findings.json and drops any entry whose (file, line) carries a blocker-tier finding, with the reason logged. Nothing is lost — the blocker stays flagged in 🚨 and the author fixes that line there. Non-blocker findings on the line do not trigger the drop, and a missing/unreadable artifact degrades to no filtering. The review prompt now says the same thing so the model doesn't waste an entry, but the deterministic filter is the guarantee. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RNTs4JzMiG36mQ2ChAyLF4
2 participants
No description provided.