mirror of
https://github.com/hashicorp/setup-terraform.git
synced 2025-12-16 08:32:34 +00:00
4dff81de7e
* Fix output malformed when wrapper enabled
Presently using a command such as `terraform output -json | jq` does not
work with the wrapper enabled, as it is by default.
In order to consume terraform's output having set it up with this
Action, it is necessary either to disable the wrapper (`with:
terraform_wrapper: false`) or run it in its own Actions step with an
explicit `id` (e.g. `id: foo`) so that it can be referred to and consumed
(`${{steps.foo.outputs.stdout}}` et al.) in later steps.
This seems to be the result of much confusion (issues passim) and is not
at all easy (#338) to debug/diagnose and come to the realisation that
it's due to the wrapper, or even that such a thing exists.
@austinvalle identified the issue as being due to the `@actions/exec`
package writing the spawned command to stdout (along with then its
actual stdout). This has previously been reported upstream in
actions/toolkit#649; I've proposed actions/toolkit#1573 to fix it.
This commit aims to address the issue for `setup-terraform` in the
meantime by silencing `@actions/exec` and then writing out to stdout &
stderr from the listener buffers, which it writes to without this
additional logging.
Closes #20, #80, #85, #149, #338, and probably more.
* add test for stdout with jq
* update test name
* remove debug lines and add changelog
* add additional note about the bug fix to wrapper
---------
Co-authored-by: Austin Valle <austinvalle@gmail.com>
60 lines
1.8 KiB
JavaScript
Executable file
60 lines
1.8 KiB
JavaScript
Executable file
#!/usr/bin/env node
|
|
/**
|
|
* Copyright (c) HashiCorp, Inc.
|
|
* SPDX-License-Identifier: MPL-2.0
|
|
*/
|
|
|
|
const io = require('@actions/io');
|
|
const core = require('@actions/core');
|
|
const { exec } = require('@actions/exec');
|
|
|
|
const OutputListener = require('./lib/output-listener');
|
|
const pathToCLI = require('./lib/terraform-bin');
|
|
|
|
async function checkTerraform () {
|
|
// Setting check to `true` will cause `which` to throw if terraform isn't found
|
|
const check = true;
|
|
return io.which(pathToCLI, check);
|
|
}
|
|
|
|
(async () => {
|
|
// This will fail if Terraform isn't found, which is what we want
|
|
await checkTerraform();
|
|
|
|
// Create listeners to receive output (in memory) as well
|
|
const stdout = new OutputListener();
|
|
const stderr = new OutputListener();
|
|
const listeners = {
|
|
stdout: stdout.listener,
|
|
stderr: stderr.listener
|
|
};
|
|
|
|
// Execute terraform and capture output
|
|
const args = process.argv.slice(2);
|
|
const options = {
|
|
listeners,
|
|
ignoreReturnCode: true,
|
|
silent: true, // avoid printing command in stdout: https://github.com/actions/toolkit/issues/649
|
|
};
|
|
const exitCode = await exec(pathToCLI, args, options);
|
|
|
|
// Pass-through stdout/err as `exec` won't due to `silent: true` option
|
|
process.stdout.write(stdout.contents);
|
|
process.stderr.write(stderr.contents);
|
|
|
|
// Set outputs, result, exitcode, and stderr
|
|
core.setOutput('stdout', stdout.contents);
|
|
core.setOutput('stderr', stderr.contents);
|
|
core.setOutput('exitcode', exitCode.toString(10));
|
|
|
|
if (exitCode === 0 || exitCode === 2) {
|
|
// A exitCode of 0 is considered a success
|
|
// An exitCode of 2 may be returned when the '-detailed-exitcode' option
|
|
// is passed to plan. This denotes Success with non-empty
|
|
// diff (changes present).
|
|
return;
|
|
}
|
|
|
|
// A non-zero exitCode is considered an error
|
|
core.setFailed(`Terraform exited with code ${exitCode}.`);
|
|
})();
|