hashicorp / tfc-workflows-tooling Goto Github PK

This is a feature request to add support for CircleCI.

Preferably exposed through a re-usable orb.

Edit: Please let me know if there is an issue template I should be following for feature requests.

As multiple integrations attempt to trigger runs on a workspace, it can happen that one integration triggers a run on a workspace while it is locked and applying an existing run.

In the current logic, when a new run is attempted as the workspace has an existing run, it fails out with an error stating that the workspace is locked.

In desired behavior, if a workspace is locked due to an existing/pending run, it should queue the the run.

Is there any interest in having the ability to create/delete workspaces with this tooling? We have a use case to create a ephemeral workspace for testing and would like to use this cli.

This issue applies to a build I created from branch main on commit f0abf3b740ca3635db3ea03e75215d03bb6456d4 (commit).

I have a workspace set to auto-apply. I used tfci run create to trigger a run. The plan was applied, but tfci got stuck.

I built the container like this.

docker buildx build -t kentest . --load

I ran it like this.

docker run -it --rm \
  -e "TF_API_TOKEN" \
  -e "TF_CLOUD_ORGANIZATION" \
  kentest \
  tfci run create -workspace myworkspace

The symptom was that stdin was never released, and tfci kept on printing:

Run Status: 'applied'
Run Status: 'applied'
Run Status: 'applied'
Run Status: 'applied'
Run Status: 'applied'
Run Status: 'applied'

...for 1/2 hour after the successful apply showed completed in TF Cloud. I eventually pressed Ctrl-C to release stdin. The workspace had already been unlocked and other runs triggered.

Hello,

I just proposed PR -91 in order to be able to support tfci upload -auto-queue-runs=true .

configuration-versions API doc specifies that auto-queue-runs should default to true. tfci defaults to false, and option is not accessible. I added the option with default to false (to avoid breaking changes ).

Thanks,

Julien

As a consumer of these actions, I need to easily fetch the workspace terraform outputs after an apply run.

As an example, I need to pass a tf output to subsequent action in my pipeline.

Terraform outputs are in Go-tfe https://github.com/hashicorp/go-tfe/blob/main/state_version_output.go#L22

As a consumer of these actions, I need a detailed plan output including a detailed view of changes. Today I only have a summary view using the outputs of the standard actions.

I need this data to be able to understand what is, created, changed or destroyed beyond a count, this is a critical part of the review process.

As an example to understand what changes are in a plan, I can review the structured plan output in the TFC UI, whilst it's possible to provide a link to the plan detail in the UI for review this breaks the review process flow. It would be preferable to have the JSON data of this view so I can format and summarize in a PR comment

Hi,

I'd like to report an issue I started having with the create-run in v1.0.3 (it wasn't there in v1.0.2), so I hope we can get it fixed. I assume the following change in v1.0.3 is causing the issue (unfortunately, I'm not familiar with Go, so I can't really tell)

v1.0.2...v1.0.3#diff-081ffb9fc91bc673b661fe6e89423940f04d5b809bc666a0a4f8eb1f7d7d39e7R104-R108

Here's some more detail:

• I have created a GitHub Actions workflow identical to this: https://github.com/hashicorp/tfc-workflows-github/blob/main/workflow-templates/terraform-cloud.apply-run.workflow.yml
• the issue is in the last step where I need to use apply-run, the payload property in https://github.com/hashicorp/tfc-workflows-github/blob/b5ae00d6ff4f940fc11ec6e70346e9c693590b5e/workflow-templates/terraform-cloud.apply-run.workflow.yml#L58C26-L58C58 seems to be empty, and that's why fromJson is throwing an error.

On Friday last week, I had a GitHub workflow using tf cloud to do a plan etc from the guide below

https://developer.hashicorp.com/terraform/tutorials/automation/github-actions

It was working all ok. Nothing has changed, and I have checked API keys expiration and now it does not work.

Run hashicorp/tfc-workflows-github/actions/[email protected]
  with:
    workspace: learn-terraform-github-actions
    directory: ./
    speculative: true
  env:
    TF_CLOUD_ORGANIZATION: PLOT1[3](https://github.com/mpr555/learn-terraform-github-actions/actions/runs/5241610510/jobs/9464248028#step:4:3)
    TF_API_TOKEN: ***
    TF_WORKSPACE: learn-terraform-github-actions
    CONFIG_DIRECTORY: ./
/usr/bin/docker run --name hashicorptfciv100_abc991 --label ed8[6](https://github.com/mpr555/learn-terraform-github-actions/actions/runs/5241610510/jobs/9464248028#step:4:6)6e --workdir /github/workspace --rm -e "TF_CLOUD_ORGANIZATION" -e "TF_API_TOKEN" -e "TF_WORKSPACE" -e "CONFIG_DIRECTORY" -e "INPUT_WORKSPACE" -e "INPUT_DIRECTORY" -e "INPUT_SPECULATIVE" -e "INPUT_HOSTNAME" -e "INPUT_TOKEN" -e "INPUT_ORGANIZATION" -e "HOME" -e "GITHUB_JOB" -e "GITHUB_REF" -e "GITHUB_SHA" -e "GITHUB_REPOSITORY" -e "GITHUB_REPOSITORY_OWNER" -e "GITHUB_REPOSITORY_OWNER_ID" -e "GITHUB_RUN_ID" -e "GITHUB_RUN_NUMBER" -e "GITHUB_RETENTION_DAYS" -e "GITHUB_RUN_ATTEMPT" -e "GITHUB_REPOSITORY_ID" -e "GITHUB_ACTOR_ID" -e "GITHUB_ACTOR" -e "GITHUB_TRIGGERING_ACTOR" -e "GITHUB_WORKFLOW" -e "GITHUB_HEAD_REF" -e "GITHUB_BASE_REF" -e "GITHUB_EVENT_NAME" -e "GITHUB_SERVER_URL" -e "GITHUB_API_URL" -e "GITHUB_GRAPHQL_URL" -e "GITHUB_REF_NAME" -e "GITHUB_REF_PROTECTED" -e "GITHUB_REF_TYPE" -e "GITHUB_WORKFLOW_REF" -e "GITHUB_WORKFLOW_SHA" -e "GITHUB_WORKSPACE" -e "GITHUB_ACTION" -e "GITHUB_EVENT_PATH" -e "GITHUB_ACTION_REPOSITORY" -e "GITHUB_ACTION_REF" -e "GITHUB_PATH" -e "GITHUB_ENV" -e "GITHUB_STEP_SUMMARY" -e "GITHUB_STATE" -e "GITHUB_OUTPUT" -e "RUNNER_OS" -e "RUNNER_ARCH" -e "RUNNER_NAME" -e "RUNNER_TOOL_CACHE" -e "RUNNER_TEMP" -e "RUNNER_WORKSPACE" -e "ACTIONS_RUNTIME_URL" -e "ACTIONS_RUNTIME_TOKEN" -e "ACTIONS_CACHE_URL" -e GITHUB_ACTIONS=true -e CI=true -v "/var/run/docker.sock":"/var/run/docker.sock" -v "/home/runner/work/_temp/_github_home":"/github/home" -v "/home/runner/work/_temp/_github_workflow":"/github/workflow" -v "/home/runner/work/_temp/_runner_file_commands":"/github/file_commands" -v "/home/runner/work/learn-terraform-github-actions/learn-terraform-github-actions":"/github/workspace" hashicorp/tfci:v1.0.0  "tfci" "-hostname=" "-token=" "-organization=" "upload" "-workspace=learn-terraform-github-actions" "-directory=./" "-speculative=true"
error uploading configuration version to Terraform Cloud: unauthorized
{
  "status": "Error"
}

Kind regards,

Max

Hi there,

I've been experiencing an issue with hashicorp/tfc-workflows-github/actions/[email protected] where my apply completes in Terraform Cloud, but the Github action does not complete and continues to be 'pending'. This is occurring when being run with TF 1.6.4

I am seeing a case where the create-run command (I use it as a GHA action) will bail out early with auto-apply enabled. This isn't consistent because the loop that does run completion checking can be sleeping when the run transitions from planning -> planned -> apply_queued -> etc...

See https://github.com/hashicorp/tfc-workflows-tooling/blob/main/internal/cloud/run.go#L172

I am not sure what the best fix is here, but here are the options I see:

1. Turn off auto-apply and rely on auto applying in the caller (in my case using GHA)
2. Remove planned as a a desired status if auto-apply is enabled
3. Allow the desired status to be passed in
4. Something else I didn't think of

Hello,
I am currently facing an issue with tfci running in github actions.
I setup my Terraform cloud workspace directory to be layer0/infrastructure/eks
But tfci 1.3.0 command:

tfci -hostname= -token= -organization= run create -workspace=myworkspace -configuration_version=cv-xxxxxx -message= -plan-o
nly=true

returns

lstat /home/tfc-agent/.tfc-agent/component/terraform/runs/run-o2Mn1KYJt4F6TbGD/config/layer0

Only the root level of the working directory has been used.
If I trigger a run manually in Terraform cloud UI, no issue.

Full log:

tfci -hostname= -token= -organization= run create -workspace=pierre-eks-us-east-2 -configuration_version=cv-xxxx -message= -plan-o
nly=true
Created Run ID: "run-o2Mn1KYJt4F6TbGD"
Run Status: "plan_queued"
Run Status: "plan_queued"
Run Status: "errored"
-------------- Plan Log --------------
Terraform v1.7.5
on linux_amd64

Error: No Terraform configuration files found in working directory

Terraform requires configuration files to plan changes. Planning without a
configuration would mark everything for destruction, which is normally not what
is desired. If you would like to destroy everything, queue a destroy plan
instead. Otherwise, create a Terraform configuration file (.tf file), or check
that the working directory is set correctly on the workspace, and try again.
Operation failed: failed checking for terraform files: lstat /home/tfc-agent/.tfc-agent/component/terraform/runs/run-o2Mn1KYJt4F6TbGD/config/layer0: no such file or directory

Any idea?
Thanks.

The provided image might not be suitable for every use case. Provide guidance and if possible examples on leveraging the existing tooling codebase to create a customized image.

Issues I encountered:

1. Running tfci run should list available sub-commands of run, but only apply is listed in the first section of the output.
2. The global options are printed redundantly for each sub-command
3. Each sub-command's usage hint is obscured by the formatting. The hint is indented, but the redundant global options and sub-command options text are not indented, which hides the usage hint for each sub-command. A divider or heading or indentation-implied hierarchy would be helpful to distinguish where a sub-command's usage hint begins and ends.

Reproduce the output with this command:

docker run -it --rm \
  -e "TF_API_TOKEN" \
  -e "TF_CLOUD_ORGANIZATION" \
  hashicorp/tfci:v1.0.0 \
  tfci run

Support for saves plans has been added to the Terraform cloud API
This functionality has been added to go-tfe which the tfc-workflow-tooling utilises.

An initial look at this

To support this would need to expose an option for provisional configuration versions as a boolean to the upload command. Provisional configuration versions are utilised only when referenced on apply.

configuration_version.go Provisional

Update run command to support saved plan boolean
run.go SavePlan

Handle new plan run plan status RunPlannedAndSaved
run.go RunPlannedAndSaved

Whenever I try to execute something with tfci, I get the following error reported: /usr/local/bin/tfci: line 1: syntax error: unexpected "("

It works on my Mac Air M2 which also has ARM architecture but apparently does not work on Ubuntu with ARM architecture.

Example call:
docker run -it hashicorp/tfci tfci --help

You're publishing amd64 binary into arm64 image:

As you can see while busybox supplied by alpine base is indeed arm64, tfci binary is amd64. This results in an error like this: exec /usr/local/bin/tfci: exec format error on arm64 github custom runner host for example.

n@docker-ce-ubuntu-4gb-nbg1-arm64-1:~$ uname -a                                                                                                                                 15:32:31 [2/2]
Linux docker-ce-ubuntu-4gb-nbg1-arm64-1 6.8.0-35-generic #35-Ubuntu SMP PREEMPT_DYNAMIC Tue May 21 07:52:29 UTC 2024 aarch64 aarch64 aarch64 GNU/Linux                                        
n@docker-ce-ubuntu-4gb-nbg1-arm64-1:~$ docker images                                                                                                                                          
REPOSITORY       TAG       IMAGE ID       CREATED        SIZE                                                                                                                                 
hashicorp/tfci   v1.3.0    4a94f3cdc2c7   2 months ago   15.9MB                                                     
n@docker-ce-ubuntu-4gb-nbg1-arm64-1:~$ container_id=$(docker create --platform linux/arm64 hashicorp/tfci:v1.3.0 ls)                                                                          
n@docker-ce-ubuntu-4gb-nbg1-arm64-1:~$ docker cp "$container_id:/usr/local/bin/tfci" ./tfci                         
Successfully copied 8.21MB to /home/n/tfci                                                                                                                                                    
n@docker-ce-ubuntu-4gb-nbg1-arm64-1:~$ docker cp "$container_id:/bin/busybox" ./busybox                             
Successfully copied 921kB to /home/n/busybox                                                                        
n@docker-ce-ubuntu-4gb-nbg1-arm64-1:~$ file busybox                                              
busybox: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-aarch64.so.1, BuildID[sha1]=044386987bb479314c5fb9741167734e720bcc3e, stri
pped                                                                                             
n@docker-ce-ubuntu-4gb-nbg1-arm64-1:~$ file tfci                                                                                                                                              
tfci: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=ndcbfLDqBHSK11-tZREY/NiLfwhLJ1veHRnJ1XVfA/KJiUfC6okpkBNDcM5NG4/nAcESPk8EoooegHAcmD9, stripped
n@docker-ce-ubuntu-4gb-nbg1-arm64-1:~$                                                                                                                                                                                                                   

I think the problem is here: https://github.com/hashicorp/tfc-workflows-tooling/blob/main/Dockerfile#L10

You'd hope that buildx would take care of it here: https://github.com/hashicorp/tfc-workflows-tooling/blob/main/.github/workflows/build-release.workflow.yml#L37

And it looks like it does, but it doesn't. If you read the logs https://github.com/hashicorp/tfc-workflows-tooling/actions/runs/8666750031/job/23768250149#step:6:385

it looks like go build in amd64 takes 10 times less than in arm64 inside buildx. My theory is that go build actually cross compiles, following GOARCH=amd64 even inside arm64 branch of buildx