chore(deps): update module golang.org/x/net to v0.60.0 [security] (main)

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
golang.org/x/net	v0.52.0 → v0.60.0

---

Infinite loop in HTTP/2 transport when given bad SETTINGS_MAX_FRAME_SIZE in net/http/internal/http2 in golang.org/x/net

BIT-golang-2026-33814 / CVE-2026-33814 / GO-2026-4918

More information

Details

When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0.

Severity

Unknown

References

• https://go.dev/cl/761581
• https://go.dev/cl/761640
• https://go.dev/issue/78476
• https://groups.google.com/g/golang-announce/c/qcCIEXso47M

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

Go Net HTML parser is vulnerable to denial of service

CVE-2026-25680 / GHSA-5cv4-jp36-h3mw / GO-2026-5028

More information

Details

In Go Net (golang.org/x/net) before verion 0.55.0, parsing arbitrary HTML can consume excessive CPU time, possibly leading to denial of service.

Severity

• CVSS Score: 6.5 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

References

• https://nvd.nist.gov/vuln/detail/CVE-2026-25680
• https://go.dev/cl/781702
• https://go.dev/issue/79573
• https://go.googlesource.com/net/+/08be507abce89191d78cd49da60f4501fc910472
• https://go.googlesource.com/net/+/refs/tags/v0.55.0
• https://groups.google.com/g/golang-announce/c/iI-mYSI0lu8
• https://pkg.go.dev/vuln/GO-2026-5028
• cs.opensource.google/go/x/net

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

Invoking incorrect handling of namespaced elements in foreign content in golang.org/x/net/html

CVE-2026-42506 / GO-2026-5025

More information

Details

Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.

Severity

Unknown

References

• https://go.dev/issue/79571
• https://groups.google.com/g/golang-announce/c/iI-mYSI0lu8
• https://go.dev/cl/781700

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

Invoking failure to reject ASCII-only Punycode-encoded labels in golang.org/x/net/idna

CVE-2026-39821 / GO-2026-5026

More information

Details

The ToASCII and ToUnicode functions incorrectly accept Punycode-encoded labels that decode to an ASCII-only label. For example, ToUnicode("xn--example-.com") incorrectly returns the name "example.com" rather than an error.

This behavior can lead to privilege escalation in programs using the idna package. For example, a program which performs privilege checks on the ASCII hostname may reject "example.com" but permit "xn--example-.com". If that program subsequently converts the ASCII hostname to Unicode, it will inadvertently permits access to the Unicode name "example.com".

Severity

Unknown

References

• https://go.dev/cl/767220
• https://go.dev/issue/78760
• https://groups.google.com/g/golang-announce/c/iI-mYSI0lu8
• https://groups.google.com/g/golang-announce/c/94pEornpRlI

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

Invoking incorrect handling of HTML elements in foreign content in golang.org/x/net/html

CVE-2026-42502 / GO-2026-5027

More information

Details

Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.

Severity

Unknown

References

• https://go.dev/issue/79572
• https://groups.google.com/g/golang-announce/c/iI-mYSI0lu8
• https://go.dev/cl/781701

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

Invoking denial of service when parsing arbitrary HTML in golang.org/x/net/html

CVE-2026-25680 / GHSA-5cv4-jp36-h3mw / GO-2026-5028

More information

Details

Parsing arbitrary HTML can consume excessive CPU time, possibly leading to denial of service.

Severity

Unknown

References

• https://go.dev/cl/781702
• https://go.dev/issue/79573
• https://groups.google.com/g/golang-announce/c/iI-mYSI0lu8

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

Invoking incorrect handling of character references in DOCTYPE nodes in golang.org/x/net/html

CVE-2026-25681 / GO-2026-5029

More information

Details

Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.

Severity

Unknown

References

• https://go.dev/issue/79574
• https://groups.google.com/g/golang-announce/c/iI-mYSI0lu8
• https://go.dev/cl/781703

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

Invoking duplicate attributes can cause XSS in golang.org/x/net/html

CVE-2026-27136 / GO-2026-5030

More information

Details

Parsing arbitrary HTML which is then rendered using Render can result in an unexpected HTML tree. This can be leveraged to execute XSS attacks in applications that attempt to sanitize input HTML before rendering.

Severity

Unknown

References

• https://go.dev/issue/79575
• https://groups.google.com/g/golang-announce/c/iI-mYSI0lu8
• https://go.dev/cl/781685

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

Parsing an invalid SVCB or HTTPS RR can panic in golang.org/x/net/dns/dnsmessage

BIT-golang-2026-46600 / CVE-2026-46600 / GO-2026-5942

More information

Details

Parsing an invalid SVCB or HTTPS RR can panic when the size of a parameter value overflows the message buffer.

Severity

Unknown

References

• https://go.dev/cl/786345
• https://go.dev/issue/79795
• https://groups.google.com/g/golang-announce/c/94pEornpRlI

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

HTTP/2 server memory exhaustion due to Trailer headers in net/http

CVE-2026-78659 / GO-2026-6603

More information

Details

When "Trailer" headers are sent by a client, the HTTP server internally uses the header values to populate the Request.Trailer map passed to the server handler. Because Request.Trailer is a map, each entry incurs memory overhead. For HTTP/2 servers, a malicious client can exploit this by sending a "Trailer" header that declares a large number of fields, causing the server to allocate a disproportionate amount of memory while bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits. This exploit is not applicable for HTTP/1 servers, which do not support multiplexing a large number of requests over one TCP connection, and whose Server.MaxHeaderBytes are calculated differently.

Severity

Unknown

References

• https://go.dev/cl/847185
• https://go.dev/cl/847314
• https://go.dev/issue/81857
• https://groups.google.com/g/golang-announce/c/U2fTuyDJznI
• https://groups.google.com/g/golang-announce/c/ZPwCyRUuGBs

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

HTTP/2 transport accepts malformed framing-related headers in net/http

CVE-2026-78660 / GO-2026-6610

More information

Details

Historically, we have been rather lax about malformed framing-related headers in our HTTP/2 implementation, as they cannot interfere with HTTP/2 framing. However, this makes it possible for our HTTP/2 implementation to forward responses containing such headers to an HTTP/1 client when acting as a reverse proxy. If the HTTP/1 client also does not behave strictly enough, this can result in response smuggling.

Severity

Unknown

References

• https://go.dev/cl/835145
• https://go.dev/cl/836385
• https://go.dev/issue/81115
• https://groups.google.com/g/golang-announce/c/U2fTuyDJznI

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

Excessive CPU consumption from repeated initial window changes in net/http

CVE-2026-78669 / GO-2026-6611

More information

Details

A malicious HTTP/2 peer can cause excessive CPU consumption in the client or server by opening a large number of streams and then sending many small SETTINGS frames containing SETTINGS_INITIAL_WINDOW_SIZE values.

Severity

Unknown

References

• https://go.dev/cl/847186
• https://go.dev/cl/847308
• https://go.dev/issue/81742
• https://groups.google.com/g/golang-announce/c/U2fTuyDJznI
• https://groups.google.com/g/golang-announce/c/ZPwCyRUuGBs

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

Double flow control refund on HTTP/2 server streams in net/http

CVE-2026-78663 / GO-2026-6612

More information

Details

The HTTP/2 server can refund connection-level flow control twice for the same data: Once when a client resets a stream (refunding data for any sent-but-unread portion of the stream), and again when a request handler reads the buffered data. A malicious client can exploit this to bypass the configured connection-level flow control limit (MaxReceiveBufferPerConnection). Total buffered data is still limited by the concurrent stream limit and stream-level flow control.

Severity

Unknown

References

• https://go.dev/cl/847187
• https://go.dev/cl/847310
• https://go.dev/issue/81743
• https://groups.google.com/g/golang-announce/c/U2fTuyDJznI
• https://groups.google.com/g/golang-announce/c/ZPwCyRUuGBs

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

HTTP/2 server crash due to HPACK encoder race in net/http

CVE-2026-97032 / GO-2026-6617

More information

Details

HTTP/2 servers could end up crashing due to inadvertently modifying its HPACK encoder concurrently. This happens because the server modifies the HPACK encoder from two goroutines without synchronization: one uses the encoder to encode a HEADERS frame as part of a response sent to a client and the other modifies the encoder's table size when handling a SETTINGS frame containing SETTINGS_HEADER_TABLE_SIZE that a client sends. A malicious client can repeatedly send a request while changing the header table size to crash the server.

Severity

Unknown

References

• https://go.dev/cl/847188
• https://go.dev/cl/847313
• https://go.dev/issue/81867
• https://groups.google.com/g/golang-announce/c/U2fTuyDJznI
• https://groups.google.com/g/golang-announce/c/ZPwCyRUuGBs

This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[renovate]

ℹ️ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

• 7 additional dependencies were updated

Details:

Package	Change
golang.org/x/crypto	v0.49.0 -> v0.57.0
golang.org/x/mod	v0.33.0 -> v0.41.0
golang.org/x/sync	v0.20.0 -> v0.23.0
golang.org/x/sys	v0.42.0 -> v0.48.0
golang.org/x/term	v0.41.0 -> v0.46.0
golang.org/x/text	v0.35.0 -> v0.42.0
golang.org/x/tools	v0.42.0 -> v0.49.0

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: chore(deps): update module golang.org/x/net to v0.60.0 [security] (main) #140
• Branch: renovate/main-go-golang.org-x-net-vulnerability
• Command: plan
• SHA: d25a7c7
• Repo: devopsfactory-io/neptune

[github-actions]

OpenSSF Scorecard — 7.2/10 ✅

Check	Score	Details
Binary-Artifacts	10/10	no binaries found in the repo
CI-Tests	10/10	29 out of 29 merged PRs checked by a CI test -- score normalized to 10
Code-Review	0/10	Found 0/30 approved changesets -- score normalized to 0
Dangerous-Workflow	10/10	no dangerous workflow patterns detected
License	10/10	license file detected
Pinned-Dependencies	9/10	dependency not pinned by hash detected -- score normalized to 9
Security-Policy	10/10	security policy file detected
Token-Permissions	10/10	GitHub workflow tokens follow principle of least privilege
Vulnerabilities	0/10	15 existing vulnerabilities detected

Threshold: 7 | Full report

[github-actions]

🌊 Neptune Plan Results

Terraform Stacks: stack-a, stack-b

Neptune completed the plan with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform init -input=false (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/local versions matching "~> 2.0"...
- Finding hashicorp/null versions matching "~> 3.0"...
- Installing hashicorp/local v2.8.0...
- Installed hashicorp/local v2.8.0 (signed by HashiCorp)
- Installing hashicorp/null v3.2.4...
- Installed hashicorp/null v3.2.4 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform init -input=false (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/local versions matching "~> 2.0"...
- Finding hashicorp/null versions matching "~> 3.0"...
- Installing hashicorp/local v2.8.0...
- Installed hashicorp/local v2.8.0 (signed by HashiCorp)
- Installing hashicorp/null v3.2.4...
- Installed hashicorp/null v3.2.4 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-a output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_a will be created
  + resource "null_resource" "stack_a" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-a"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-b output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_b will be created
  + resource "null_resource" "stack_b" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-b"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform apply -input=false tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] null_resource.stack_a: Creating...
null_resource.stack_a: Creation complete after 0s [id=2498055012854443745]
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=a57cdd3e7db0022635e46b54e3ae6357944d9ed4]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Command ✅ terraform apply -input=false tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] null_resource.stack_b: Creating...
local_file.out: Creating...
null_resource.stack_b: Creation complete after 0s [id=5697709556313134815]
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: chore(deps): update module golang.org/x/net to v0.60.0 [security] (main) #140
• Branch: renovate/main-go-golang.org-x-net-vulnerability
• Command: plan
• SHA: 1da9c25
• Repo: devopsfactory-io/neptune

[github-actions]

🌊 Neptune Plan Results

Terraform Stacks: stack-a, stack-b

Neptune completed the plan with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform init -input=false (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/null versions matching "~> 3.0"...
- Finding hashicorp/local versions matching "~> 2.0"...
- Installing hashicorp/null v3.3.0...
- Installed hashicorp/null v3.3.0 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform init -input=false (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/null versions matching "~> 3.0"...
- Finding hashicorp/local versions matching "~> 2.0"...
- Installing hashicorp/null v3.3.0...
- Installed hashicorp/null v3.3.0 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-a output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_a will be created
  + resource "null_resource" "stack_a" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-a"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-b output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_b will be created
  + resource "null_resource" "stack_b" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-b"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform apply -input=false tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] null_resource.stack_a: Creating...
local_file.out: Creating...
null_resource.stack_a: Creation complete after 0s [id=3216350278656034487]
local_file.out: Creation complete after 0s [id=a57cdd3e7db0022635e46b54e3ae6357944d9ed4]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Command ✅ terraform apply -input=false tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] local_file.out: Creating...
null_resource.stack_b: Creating...
null_resource.stack_b: Creation complete after 0s [id=4602916111974216548]
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: chore(deps): update module golang.org/x/net to v0.60.0 [security] (main) #140
• Branch: renovate/main-go-golang.org-x-net-vulnerability
• Command: plan
• SHA: 1da9c25
• Repo: devopsfactory-io/neptune

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: chore(deps): update module golang.org/x/net to v0.60.0 [security] (main) #140
• Branch: renovate/main-go-golang.org-x-net-vulnerability
• Command: plan
• SHA: 1f3b24a
• Repo: devopsfactory-io/neptune

[github-actions]

🌊 Neptune Plan Results

Terraform Stacks: stack-a, stack-b

Neptune completed the plan with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform init -input=false (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/null versions matching "~> 3.0"...
- Finding hashicorp/local versions matching "~> 2.0"...
- Installing hashicorp/null v3.3.0...
- Installed hashicorp/null v3.3.0 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform init -input=false (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/local versions matching "~> 2.0"...
- Finding hashicorp/null versions matching "~> 3.0"...
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)
- Installing hashicorp/null v3.3.0...
- Installed hashicorp/null v3.3.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-a output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_a will be created
  + resource "null_resource" "stack_a" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-a"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-b output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_b will be created
  + resource "null_resource" "stack_b" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-b"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform apply -input=false tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] null_resource.stack_a: Creating...
null_resource.stack_a: Creation complete after 0s [id=7539256123583311001]
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=a57cdd3e7db0022635e46b54e3ae6357944d9ed4]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Command ✅ terraform apply -input=false tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] null_resource.stack_b: Creating...
null_resource.stack_b: Creation complete after 0s [id=179812565576778214]
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

[github-actions]

🌊 Neptune Plan Results

Terraform Stacks: stack-a, stack-b

Neptune completed the plan with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform init -input=false (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/null versions matching "~> 3.0"...
- Finding hashicorp/local versions matching "~> 2.0"...
- Installing hashicorp/null v3.3.0...
- Installed hashicorp/null v3.3.0 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform init -input=false (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/null versions matching "~> 3.0"...
- Finding hashicorp/local versions matching "~> 2.0"...
- Installing hashicorp/null v3.3.0...
- Installed hashicorp/null v3.3.0 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-a output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_a will be created
  + resource "null_resource" "stack_a" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-a"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-b output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_b will be created
  + resource "null_resource" "stack_b" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-b"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform apply -input=false tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] null_resource.stack_a: Creating...
null_resource.stack_a: Creation complete after 0s [id=8193949113145704086]
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=a57cdd3e7db0022635e46b54e3ae6357944d9ed4]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Command ✅ terraform apply -input=false tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] null_resource.stack_b: Creating...
null_resource.stack_b: Creation complete after 0s [id=7673376148047562192]
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

[github-actions]

🌊 Neptune Plan Results

Terraform Stacks: stack-a, stack-b

Neptune completed the plan with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform init -input=false (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/local versions matching "~> 2.0"...
- Finding hashicorp/null versions matching "~> 3.0"...
- Installing hashicorp/null v3.3.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform init -input=false (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/local versions matching "~> 2.0"...
- Finding hashicorp/null versions matching "~> 3.0"...
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)
- Installing hashicorp/null v3.3.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-a output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_a will be created
  + resource "null_resource" "stack_a" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-a"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-b output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_b will be created
  + resource "null_resource" "stack_b" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-b"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform apply -input=false tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] null_resource.stack_a: Creating...
null_resource.stack_a: Creation complete after 0s [id=5199021413837271160]
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=a57cdd3e7db0022635e46b54e3ae6357944d9ed4]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Command ✅ terraform apply -input=false tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] null_resource.stack_b: Creating...
null_resource.stack_b: Creation complete after 0s [id=2965820535847853632]
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: chore(deps): update module golang.org/x/net to v0.60.0 [security] (main) #140
• Branch: renovate/main-go-golang.org-x-net-vulnerability
• Command: plan
• SHA: 1ddeb77
• Repo: devopsfactory-io/neptune

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: chore(deps): update module golang.org/x/net to v0.60.0 [security] (main) #140
• Branch: renovate/main-go-golang.org-x-net-vulnerability
• Command: plan
• SHA: 5e32efb
• Repo: devopsfactory-io/neptune

[github-actions]

🌊 Neptune Plan Results

Terraform Stacks: stack-a, stack-b

Neptune completed the plan with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform init -input=false (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/local versions matching "~> 2.0"...
- Finding hashicorp/null versions matching "~> 3.0"...
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)
- Installing hashicorp/null v3.3.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform init -input=false (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/null versions matching "~> 3.0"...
- Finding hashicorp/local versions matching "~> 2.0"...
- Installing hashicorp/null v3.3.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-a output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_a will be created
  + resource "null_resource" "stack_a" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-a"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-b output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_b will be created
  + resource "null_resource" "stack_b" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-b"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform apply -input=false tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] null_resource.stack_a: Creating...
null_resource.stack_a: Creation complete after 0s [id=1713190558228468710]
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=a57cdd3e7db0022635e46b54e3ae6357944d9ed4]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Command ✅ terraform apply -input=false tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] null_resource.stack_b: Creating...
null_resource.stack_b: Creation complete after 0s [id=527682152072617926]
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

[github-actions]

🌊 Neptune Plan Results

Terraform Stacks: stack-a, stack-b

Neptune completed the plan with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform init -input=false (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/null versions matching "~> 3.0"...
- Finding hashicorp/local versions matching "~> 2.0"...
- Installing hashicorp/null v3.3.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform init -input=false (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Initializing the backend...

Initializing provider plugins...
- Finding hashicorp/local versions matching "~> 2.0"...
- Finding hashicorp/null versions matching "~> 3.0"...
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)
- Installing hashicorp/null v3.3.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)

Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-a output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_a will be created
  + resource "null_resource" "stack_a" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-a"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

Command ✅ terraform plan -input=false -out=tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # local_file.out will be created
  + resource "local_file" "out" {
      + content              = "stack-b output"
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "./out.txt"
      + id                   = (known after apply)
    }

  # null_resource.stack_b will be created
  + resource "null_resource" "stack_b" {
      + id       = (known after apply)
      + triggers = {
          + "stack" = "stack-b"
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

─────────────────────────────────────────────────────────────────────────────

Saved the plan to: tfplan

To perform exactly these actions, run the following command to apply:
    terraform apply "tfplan"

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

Command ✅ terraform apply -input=false tfplan (stack: stack-a)

Click to see the command output

stderr:


stdout:
[stack-a] local_file.out: Creating...
null_resource.stack_a: Creating...
local_file.out: Creation complete after 0s [id=a57cdd3e7db0022635e46b54e3ae6357944d9ed4]
null_resource.stack_a: Creation complete after 0s [id=9016422158159676821]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

Command ✅ terraform apply -input=false tfplan (stack: stack-b)

Click to see the command output

stderr:


stdout:
[stack-b] null_resource.stack_b: Creating...
null_resource.stack_b: Creation complete after 0s [id=5290763577890364290]
local_file.out: Creating...
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]

Apply complete! Resources: 2 added, 0 changed, 0 destroyed.

[coderabbitai]

Important

Review skipped

Bot user detected.

To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: ed1aa1b3-6931-4b02-9b88-75342218ebda

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

• Autopilot · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: chore(deps): update module golang.org/x/net to v0.60.0 [security] (main) #140
• Branch: renovate/main-go-golang.org-x-net-vulnerability
• Command: plan
• SHA: 5e32efb
• Repo: devopsfactory-io/neptune

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: chore(deps): update module golang.org/x/net to v0.60.0 [security] (main) #140
• Branch: renovate/main-go-golang.org-x-net-vulnerability
• Command: plan
• SHA: 16b0d5e
• Repo: devopsfactory-io/neptune

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: chore(deps): update module golang.org/x/net to v0.60.0 [security] (main) #140
• Branch: renovate/main-go-golang.org-x-net-vulnerability
• Command: plan
• SHA: 8e97707
• Repo: devopsfactory-io/neptune