This patch ensures, if `package.json` exists, that `npm install` is
always run prior to any pulumi command. This will trigger any scripts
that install plugins; ensuring most CI systems can build Pulumi projects
without hacky workarounds.
During a GitHub Actions run, because we currently capture CLI output in a variable and exit immediately on failure, we prevent the details of the failure from being rendered in the Actions log. This change has us `tee` stdout instead (as the intent is to use it to post a PR comment later), allowing errors to be rendered properly in the log.
Signed-off-by: Christian Nunciato <c@nunciato.org>
* Remove pulumi.io reference in tests
* Remove pulumi.io references in Dockerfiles
* Remove pulumi.io references in CONTRIBUTING.md
* Update README.md's
* Use correct logo
- Pick python as a base image. Debian build tools depend on 3.5, so don't fight that battle, just use an existing solution
- Fixes#2435
- Move the pulumi install to the bottom. Rule of thumb is you always install deps first then your software so you're not thrashing the dockerfile build because you only build images when your code changes, not when deps change.
- Do all of the dep work in one step and clean up. This makes the image have way fewer layers and makes the image a bit smaller
- Get consistent with repo addition. I'm not sure if this is the best way, but it's better.
- Add some failure handling to curl commands
- Avoid crazy ass curl-pipe-bash install scripts when possible in favor of crazy ass curl-pipe-apt-key 😨
- Add some github actions stuff in case people want to use this for actions. I'm here because the github action is wack, and I'm trying to align your dockerfiles across both repos.
This change does two things:
- It ensures that as part of publishing the SDK, we also publish an
updated pulumi/pulumi docker image (tagged with both `latest` and
`vX.Y.Z`
- Makes this image published by this repository less perscriptive in a
workflow. The instead of having wrapper scripts that try to invoke
Pulumi based on conventions. It is now just a base image that has
the pulumi CLI installed, as well as the SDKs for the major cloud
providers. We'll use this base layer in our github actions image,
which will layer on a github actions centric workflow
Fixes#1991
Pulumi used to have a much more complicated install process, whereas
today, this is no longer the case. You simply unpack pulumi to a
folder of your choice, add it to the `$PATH` and then go.
The `install.sh` was writtten back when Pulumi had to be installed
into its own directory. It assumed that it "owned" this directory and
when the script hit an error would clean up its half processed state
before trying to exit. While this was fine out of the box (since we
default to installing to `/usr/local/pulumi`) if you overrode the
install location to just say `/usr/local` *and* we hit an error in the
script, the script would try to remove everything from `/usr/local` as
part of cleaning itself up.
Since we no longer need any of this extra install logic, we'll just
remove `install.sh` completely. The SDK tarball will now contain a
single top level directory (named `pulumi`) with all of our binaries
under it. Manual installs will now just mean unpacking the tarball
somewhere and putting that `pulumi` folder on your path, or as a
simplification, copying all the binaries from the `pulumi` folder into
an existing folder that is already on your path.
This also removes the need to ever ask the user to `sudo` during an
install. Users now have complete control over where they put our
binaries, which is exactly what you want from a manual install
process.
This change eliminates our dependencies on the SDK repo. Now that
SDKs are comprised solely of pulumi/pulumi artifacts, a separate repo
isn't required. This allows us to simplify some of the distribution.
The install.sh script is modified slightly, to permit overriding the
default install location using $PULUMI_INSTALL_PATH.
The windows build was still on the old plan from way back when where
we had binaries littered in the build tree and you had to add parts of
your build-tree to the `%PATH%` for the integration tests to work.
This cleans that up and moves all of our scripts that invoke
javascript to be on the same plan. They invoke our specially named
node with a relative path to the JS code we want to run.
- `go build` handles appending .exe to the built binary, so we need not do
it ourselves. In fact, when we did we generated a binary called
`pulumi.exe.exe` which is not what we wanted.
- Remove the development versions of the langhost and dynamic provider,
from the `<root>/node_modules/pulumi` folder. The `dist` version gets
copied into bin.
- Add the dummy_argument workaround to the dist version of the langhost.
