* Improve download discoverability
We know users have trouble simply downloading Pulumi. This used to be
very easy, but over time, as we optimized the Getting Started flows, it
got pushed further and further away from the core user experience.
I don't know about you, but the first thing I care about when I'm
trying out a new open source tool is downloading it!
This change aims to do two things:
1. Make downloading a more prominent CTA.
2. Improve the download page so it's less noisy and more focused.
This entails:
* Adding a DOWNLOAD secondary CTA on the homepage.
* Summarizing the recommended download options at the top of the
download page, very clearly, and without any preamble. This
hopefully tells you instantly what you wanted for the 80% case.
* I exerted some artistic freedom which I'd love feedback on. The
recommended options were our Official Brew Tap for macOS, curl
command for Linux, and MSI Installer for Windows. Peers to those
are simple download links for the binaries, as that's the simplest
possible thing, which today is actually the hardest thing to find.
Notably for Windows, I thought of using Chocolatey or Winget, but
I don't perceive that either is "the default" for Windows users.
Winget is the future but it isn't supported pre-Win11, which I have
to assume most users aren't on yet. MSI has been around since the
dinosaurs, so it seems like the safest choice to promote.
* Moving the list of download options for each operating system
underneath a collapsable accordion list, which is collapsed by
default, and clearly labeling it as "Other"; as in, if the heading
didn't work for you, here are some other options.
* A few other wordsmithing tweaks to make the page a little more
streamlined and to flow better.
This is absolutely NOT the final destination for any of this,
however, I am hopeful it will be a simple incremental improvement
that moves the needle on key metrics. We'll watch it in the weeks
to come and course correct as needed -- as well as continuing to
think about ways we can improve all of this overall!
One note: This depends on a new secondary hero button style that
isn't yet merged in the upstream Hugo component library. Assuming
I did that correctly (a big if!) I'll need to rev the go.mod file
after it merges. See: https://github.com/pulumi/theme/pull/159.
* Apply suggestions from code review
Co-authored-by: susan evans <susan.ra.evans@gmail.com>
* Fix up some styling
* Update themes/default/layouts/index.html
Co-authored-by: susan evans <susan.ra.evans@gmail.com>
* Use new theme/style
Co-authored-by: susan evans <susan.ra.evans@gmail.com>
Co-authored-by: zchase <zachary@pulumi.com>
* A handful of updates
Here are some updates based on recent conversations and feedback:
* Update the homepage subheading to be a bit clearer about what
Pulumi is and what it does.
* Change the Cloud Engineering menu item to Why Pulumi, and sort
it to the right of Product. This more clearly speaks to what
this navigation item represents as well as its importance
relative to learning about Pulumi's Product offerings.
* Change the Pulumi Product landing page to say Pulumi Overview,
not Cloud Engineering Platform, since that's what you click to
get there and it currently feels very disconnected from all of
the surrounding marketing which speaks in terms of IaC.
* Add a paragraph to that overview page speaking simply to what
Pulumi is, and making sure to mention open source.
* Add a sentence to the Get Started page about open source.
* Add more customer logos -- we should be updating this much more
often!! Also change the logos to scroll horizontally so that
we aren't afraid to continue adding new ones from time to time.
* Add recent news stories -- we should be updating this much
more often too!! Apparently it's been over a year, despite having
tons of news coverage to share.
* Run prettier to format things
* Sort the case studies
* crop tfir logo
Signed-off-by: susanev <susan.ra.evans@gmail.com>
Co-authored-by: susanev <susan.ra.evans@gmail.com>
* Add docs about plugins section in Pulumi.yaml
* Add (optional)
* Full stop and casing
Co-authored-by: susan evans <susan.ra.evans@gmail.com>
Co-authored-by: susan evans <susan.ra.evans@gmail.com>
* Update getting started guides for dotnet 6 using newer templates
* lint
* update ec2-webserver how-to guide for csharp
* Fix inconsistencies found by Mikhail 🙏
* Retarget YAML button on SDK home page
.. in sympathy with this menu change:
https://github.com/pulumi/docs/pull/7764
* Remove the implicit Pulumi YAML spec menu item
The PR https://github.com/pulumi/docs/pull/7764 adds a menu item
pointing at the Pulumi YAML spec, from the SDK part of the navigation
menu; this commit removes the `menu` stanza from the doc file itself,
which would normally generate a(nother) menu item for itself.
Mysteriously, the implicit menu item appears in previews but not in the
live site. Removing it will at least make sure it doesn't accidentally
appear at some later time.
Signed-off-by: Michael Bridgen <mbridgen@pulumi.com>
This adds the Pulumi YAML spec, as taken from
https://github.com/pulumi/pulumi-yaml/blob/main/README.md
to the reference docs part of the website, and links to it from the
intro part, navigation, and reference home page.
Signed-off-by: Michael Bridgen <mbridgen@pulumi.com>
* Add PULUMI_TEST_MODE to guides/testing/unit
I was pulling my hair out trying to figure out why `pulumi.isDryRun`
was returning `false` when I was running my unit tests, given that
[the docs on the method][1] say:
> Note that we always consider executions in test mode to be
> “dry-runs”, since we will never actually carry out an update, and
> therefore certain output properties will never be resolved.
I’m still not sure if/where there is any canonical documentation on
“test mode” but I feel that it should probably always be enabled when
running unit tests. I’d prefer that there be a programmatic/imperative
way to enable it, e.g. `runtime.setDryRun(true)` or something similar,
but in lieu of that I feel the examples should include setting the env
var so as to plant seeds of awareness about this feature and how it
works.
[1]: https://www.pulumi.com/docs/reference/pkg/nodejs/pulumi/pulumi/runtime/#isDryRun
* Revert "Add PULUMI_TEST_MODE to guides/testing/unit"
f4adeec976811d64fe066b5084a9eeaf91b63814
As per discussion in pulumi/pulumi-hugo#1642
* guides/testing/unit: show how to set dryRun flag
Which, as per the discussion in pulumi/pulumi-hugo#1642, should
really/probably be renamed to `isPreview` or something along those
lines.
Anyway, it looks like the C# example already includes passing a value
for this flag, and I don’t know enough Go to add it to the Go example.
Now that I’m writing this commit message, the situation with `dryRun`
is confusing enough (especially given the docs on `runtime.isDryRun`)
that it could probably merit adding a small dedicated section to this
page. I’ll ask in the PR whether that’d be desirable.
* guides/testing/unit.md: better description of a flag
Co-authored-by: Ian Wahbe <ian@wahbe.com>
Co-authored-by: Ian Wahbe <ian@wahbe.com>
