fix(deps): update aws-sdk-go-v2 monorepo in lambda/go.mod (main)

[renovate]

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Type	Update	Change	Pending	OpenSSF
github.com/aws/aws-sdk-go-v2	require	minor	v1.41.5 → v1.42.1
github.com/aws/aws-sdk-go-v2/config	require	patch	v1.32.14 → v1.32.29	v1.32.30
github.com/aws/aws-sdk-go-v2/service/s3	require	minor	v1.98.0 → v1.105.0	v1.105.1
github.com/aws/aws-sdk-go-v2/service/secretsmanager	require	minor	v1.41.5 → v1.43.0	v1.43.1

---

Release Notes

aws/aws-sdk-go-v2 (github.com/aws/aws-sdk-go-v2)

v1.42.1

Compare Source

Module Highlights

• github.com/aws/aws-sdk-go-v2/service/acm: v1.37.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/aiops: v1.6.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/appflow: v1.50.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/appsync: v1.51.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/athena: v1.55.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/autoscaling: v1.58.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/b2bi: v1.0.0-preview.79
  • Feature: Updated APIs to support custom validation rules.
• github.com/aws/aws-sdk-go-v2/service/bedrock: v1.45.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/bedrockagent: v1.50.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/bedrockdataautomation: v1.9.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/bedrockdataautomationruntime: v1.7.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/braket: v1.37.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/chatbot: v1.14.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/chimesdkmediapipelines: v1.26.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/chimesdkmessaging: v1.31.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/cloudcontrol: v1.28.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/cloudformation: v1.65.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/cloudsearch: v1.31.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/cloudtraildata: v1.16.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/cloudwatchevents: v1.32.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/cloudwatchlogs: v1.57.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/codeartifact: v1.38.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/codegurusecurity: v1.16.3
  • Documentation: Documentation update to notify users of the discontinuation of Amazon CodeGuru Security.
• github.com/aws/aws-sdk-go-v2/service/codestarnotifications: v1.31.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/connectparticipant: v1.34.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/controltower: v1.26.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/costandusagereportservice: v1.33.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/datazone: v1.39.0
  • Feature: Releasing the following features - Asset classification that lets users use restricted terms for classifying assets if they have the right permissions. Also adding a new enum value "Moving" to project status.
• github.com/aws/aws-sdk-go-v2/service/dax: v1.28.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/devicefarm: v1.35.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/devopsguru: v1.39.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/directconnect: v1.37.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/docdbelastic: v1.19.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/ec2: v1.246.0
  • Feature: Added IPv6 support for AWS Client VPN.
• github.com/aws/aws-sdk-go-v2/service/eks: v1.72.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/emrcontainers: v1.39.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/finspacedata: v1.33.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/forecast: v1.41.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/fsx: v1.61.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/groundstation: v1.37.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/health: v1.34.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/iotdataplane: v1.32.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/iotfleethub: v1.29.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/iotsitewise: v1.51.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/kendra: v1.60.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/keyspaces: v1.23.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/kinesisanalytics: v1.30.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/kinesisvideoarchivedmedia: v1.32.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/lambda: v1.77.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/lexmodelsv2: v1.56.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/lexruntimeservice: v1.29.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/licensemanager: v1.36.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/lookoutequipment: v1.35.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/mailmanager: v1.17.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/marketplacecatalog: v1.36.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/mediaconvert: v1.82.0
  • Feature: This release adds support for input rendition selection for HLS input, adds new Share API to enable sharing jobs with AWS Support for support investigations, and adds INCLUDE_AS_TS to iFrameOnlyManifest setting for HLS outputs.
• github.com/aws/aws-sdk-go-v2/service/mediapackagevod: v1.39.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/mediastore: v1.29.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/migrationhubstrategy: v1.26.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/odb: v1.4.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/opensearchserverless: v1.25.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/opsworkscm: v1.32.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/outposts: v1.56.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/pcaconnectorad: v1.15.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/personalizeruntime: v1.32.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/qbusiness: v1.33.0
  • Feature: The Amazon Q Business GetDocumentContent operation now supports retrieval of the extracted text content in JSON format.
• github.com/aws/aws-sdk-go-v2/service/redshiftserverless: v1.31.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/repostspace: v1.14.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/resiliencehub: v1.34.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/resourcegroupstaggingapi: v1.30.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/sagemakeredge: v1.30.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/sagemakerfeaturestoreruntime: v1.34.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/sagemakerruntime: v1.37.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/serverlessapplicationrepository: v1.29.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/servicecatalog: v1.38.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/sfn: v1.39.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/shield: v1.34.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/snowball: v1.35.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/sqs: v1.42.1
  • Documentation: Documentation update for Amazon SQS Supports Large Payload Message feature
• github.com/aws/aws-sdk-go-v2/service/ssoadmin: v1.35.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/storagegateway: v1.42.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/support: v1.31.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/supportapp: v1.18.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/taxsettings: v1.16.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/timestreaminfluxdb: v1.16.0
  • Feature: Add MAINTENANCE status for DbInstance and DbCluster
• github.com/aws/aws-sdk-go-v2/service/transcribe: v1.52.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/transcribestreaming: v1.31.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/translate: v1.33.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/wellarchitected: v1.39.0
  • Feature: Remove incorrect endpoint tests
• github.com/aws/aws-sdk-go-v2/service/workspacesthinclient: v1.20.0
  • Feature: Remove incorrect endpoint tests

v1.42.0

Compare Source

General Highlights

• Dependency Update: Bump smithy-go to 1.25.0 to support endpointBdd trait
• Dependency Update: Updated to the latest SDK module versions

Module Highlights

• github.com/aws/aws-sdk-go-v2/service/cleanrooms: v1.43.0
  • Feature: This release adds support for configurable spark properties for Cleanrooms PySpark workloads.
• github.com/aws/aws-sdk-go-v2/service/connect: v1.171.0
  • Feature: Fixes in SDK for customers using TestCase APIs
• github.com/aws/aws-sdk-go-v2/service/connectcampaignsv2: v1.12.0
  • Feature: This release adds support for campaign entry limits configuration and hourly refresh frequency in Amazon Connect Outbound Campaigns.
• github.com/aws/aws-sdk-go-v2/service/groundstation: v1.41.0
  • Feature: Adds support for updating contacts, listing antennas, and listing ground station reservations. New API operations - UpdateContact, ListContactVersions, DescribeContactVersion, ListAntennas, and ListGroundStationReservations.
• github.com/aws/aws-sdk-go-v2/service/imagebuilder: v1.53.0
  • Feature: ImportDiskImage API adds registerImageOptions for Secure Boot control and custom UEFI data. It adds windowsConfiguration for selecting a specific edition from multi-image .wim files during ISO import.
• github.com/aws/aws-sdk-go-v2/service/neptune: v1.44.4
  • Documentation: Improving Documentation for Neptune
• github.com/aws/aws-sdk-go-v2/service/quicksight: v1.107.0
  • Feature: Public release of dashboard customization summary, S3 Tables data source type, Athena cross-account connector, custom sorting for controls, and AI-powered analysis generation.
• github.com/aws/aws-sdk-go-v2/service/sagemaker: v1.241.0
  • Feature: Adds support for providing NetworkInterface for efa enabled instances and Simplified cluster creation for Slurm-orchestrated clusters with optional Lifecycle Script (LCS) configuration.
• github.com/aws/aws-sdk-go-v2/service/sts: v1.42.0
  • Feature: The STS client now supports configuring SigV4a through the auth scheme preference setting. SigV4a uses asymmetric cryptography, enabling customers using long-term IAM credentials to continue making STS API calls even when a region is isolated from the partition leader.

v1.41.12

Compare Source

General Highlights

• Dependency Update: Updated to the latest SDK module versions

Module Highlights

• github.com/aws/aws-sdk-go-v2: v1.41.5
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/accessanalyzer: v1.45.12
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/account: v1.30.5
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/acm: v1.37.23
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/acmpca: v1.46.12
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/aiops: v1.6.21
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/amp: v1.42.9
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/amplify: v1.38.14
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/amplifybackend: v1.32.20
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/amplifyuibuilder: v1.28.20
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/apigateway: v1.39.1
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/apigatewaymanagementapi: v1.29.14
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/apigatewayv2: v1.34.1
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/appconfig: v1.43.13
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/appconfigdata: v1.23.22
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/appfabric: v1.16.21
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/appflow: v1.51.12
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/appintegrations: v1.37.7
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/applicationautoscaling: v1.41.14
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/applicationcostprofiler: v1.27.12
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/applicationdiscoveryservice: v1.35.13
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/applicationinsights: v1.34.20
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/applicationsignals: v1.19.1
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/appmesh: v1.35.12
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/apprunner: v1.39.14
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/appstream: v1.54.4
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/appsync: v1.53.5
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/arcregionswitch: v1.6.3
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/arczonalshift: v1.22.23
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/artifact: v1.15.5
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/athena: v1.57.4
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/auditmanager: v1.46.12
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/autoscaling: v1.64.4
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/autoscalingplans: v1.30.14
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/b2bi: v1.0.0-preview.100
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/backup: v1.54.11
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/backupgateway: v1.26.3
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/backupsearch: v1.6.23
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/batch: v1.63.2
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/bcmdashboards: v1.1.4
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/bcmdataexports: v1.14.0
  • Feature: With this release we are providing an option to accounts to have their export delivered to an S3 bucket that is not owned by the account.
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/bcmpricingcalculator: v1.10.9
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/bcmrecommendedactions: v1.1.5
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/bedrock: v1.57.1
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/bedrockagent: v1.52.7
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/bedrockagentcore: v1.15.2
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/bedrockagentcorecontrol: v1.25.1
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/bedrockagentruntime: v1.51.8
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/bedrockdataautomation: v1.13.5
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/bedrockdataautomationruntime: v1.10.4
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/bedrockruntime: v1.50.4
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/billing: v1.10.4
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/billingconductor: v1.28.5
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/braket: v1.39.8
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/budgets: v1.43.4
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/chatbot: v1.14.21
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/chime: v1.41.12
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/chimesdkidentity: v1.27.20
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/chimesdkmediapipelines: v1.26.21
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/chimesdkmeetings: v1.33.15
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/chimesdkmessaging: v1.32.17
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/chimesdkvoice: v1.28.13
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cleanrooms: v1.42.4
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cleanroomsml: v1.22.5
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cloud9: v1.33.20
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cloudcontrol: v1.29.13
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/clouddirectory: v1.30.12
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cloudformation: v1.71.9
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cloudfront: v1.60.4
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cloudfrontkeyvaluestore: v1.12.24
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cloudhsm: v1.29.21
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cloudhsmv2: v1.34.21
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cloudsearch: v1.32.12
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cloudsearchdomain: v1.28.20
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cloudtrail: v1.55.9
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cloudtraildata: v1.17.13
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cloudwatch: v1.55.3
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cloudwatchevents: v1.32.23
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cloudwatchlogs: v1.65.0
  • Feature: This release adds parameter support to saved queries in CloudWatch Logs Insights. Define reusable query templates with named placeholders, invoke them using start query. Available in Console, CLI and SDK
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/codeartifact: v1.38.21
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/codebuild: v1.68.13
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/codecatalyst: v1.21.12
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/codecommit: v1.33.12
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/codeconnections: v1.10.20
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/codedeploy: v1.35.13
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/codeguruprofiler: v1.29.20
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/codegurureviewer: v1.34.20
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/codegurusecurity: v1.16.24
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/codepipeline: v1.46.21
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/codestarconnections: v1.35.13
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/codestarnotifications: v1.31.21
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cognitoidentity: v1.33.22
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cognitoidentityprovider: v1.59.3
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/cognitosync: v1.29.12
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/comprehend: v1.40.21
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/comprehendmedical: v1.31.21
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/computeoptimizer: v1.49.8
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/computeoptimizerautomation: v1.0.8
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/configservice: v1.62.1
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/connect: v1.166.1
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/connectcampaigns: v1.20.20
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/connectcampaignsv2: v1.11.4
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/connectcases: v1.39.1
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/connectcontactlens: v1.33.13
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/connecthealth: v1.0.3
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/connectparticipant: v1.36.7
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/controlcatalog: v1.14.9
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/controltower: v1.28.9
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/costandusagereportservice: v1.34.13
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/costexplorer: v1.63.6
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/costoptimizationhub: v1.22.8
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/customerprofiles: v1.57.2
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/databasemigrationservice: v1.61.10
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/databrew: v1.39.14
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/dataexchange: v1.40.14
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/datapipeline: v1.30.20
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/datasync: v1.58.2
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/datazone: v1.54.2
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/dax: v1.29.16
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/deadline: v1.26.2
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/detective: v1.38.13
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/devicefarm: v1.38.8
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/devopsguru: v1.40.12
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/directconnect: v1.38.15
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/directoryservice: v1.38.16
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/directoryservicedata: v1.7.21
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/dlm: v1.35.16
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/docdb: v1.48.13
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/docdbelastic: v1.20.13
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/drs: v1.36.13
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/dsql: v1.12.8
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/dynamodb: v1.57.1
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/dynamodbstreams: v1.32.14
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/ebs: v1.33.14
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/ec2: v1.296.1
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/ec2instanceconnect: v1.32.20
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/ecr: v1.56.2
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/ecrpublic: v1.38.13
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• github.com/aws/aws-sdk-go-v2/service/ecs: v1.74.1
  • Bug Fix: Fix a bug where a recorded clock skew could persist on the client even if the client and server clock ended up realigning.
• `github.co

✂ Note

PR body was truncated to here.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • Between 12:00 AM and 03:59 AM (* 0-3 * * *)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Enabled.

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

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

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

---

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

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: fix(deps): update aws-sdk-go-v2 monorepo in lambda/go.mod (main) #131
• Branch: renovate/main-aws-sdk-go-v2-monorepo
• Command: plan
• SHA: 65bba25
• 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.2.4...
- Installed hashicorp/null v3.2.4 (signed by HashiCorp)
- Installing hashicorp/local v2.8.0...
- Installed hashicorp/local v2.8.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.2.4...
- Installed hashicorp/null v3.2.4 (signed by HashiCorp)
- Installing hashicorp/local v2.8.0...
- Installed hashicorp/local v2.8.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=1672035333654671910]
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=1793228703302593031]
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: fix(deps): update aws-sdk-go-v2 monorepo in lambda/go.mod (main) #131
• Branch: renovate/main-aws-sdk-go-v2-monorepo
• Command: plan
• SHA: b04c298
• 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/null v3.2.4...
- Installed hashicorp/null v3.2.4 (signed by HashiCorp)
- Installing hashicorp/local v2.8.0...
- Installed hashicorp/local v2.8.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.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=192325180287796311]
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=7533449980934697436]
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: fix(deps): update aws-sdk-go-v2 monorepo in lambda/go.mod (main) #131
• Branch: renovate/main-aws-sdk-go-v2-monorepo
• Command: plan
• SHA: b85da25
• 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.2.4...
- Installed hashicorp/null v3.2.4 (signed by HashiCorp)
- Installing hashicorp/local v2.8.0...
- Installed hashicorp/local v2.8.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/null v3.2.4...
- Installed hashicorp/null v3.2.4 (signed by HashiCorp)
- Installing hashicorp/local v2.8.0...
- Installed hashicorp/local v2.8.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=3776322936138890563]
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...
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]
null_resource.stack_b: Creation complete after 0s [id=1181713196680866156]

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

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: fix(deps): update aws-sdk-go-v2 monorepo in lambda/go.mod (main) #131
• Branch: renovate/main-aws-sdk-go-v2-monorepo
• Command: plan
• SHA: 3d5b53c
• Repo: devopsfactory-io/neptune

[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):

• 15 additional dependencies were updated

Details:

Package	Change
github.com/aws/aws-sdk-go-v2/aws/protocol/eventstream	v1.7.8 -> v1.7.14
github.com/aws/aws-sdk-go-v2/credentials	v1.19.14 -> v1.19.28
github.com/aws/aws-sdk-go-v2/feature/ec2/imds	v1.18.21 -> v1.18.30
github.com/aws/aws-sdk-go-v2/internal/configsources	v1.4.21 -> v1.4.30
github.com/aws/aws-sdk-go-v2/internal/endpoints/v2	v2.7.21 -> v2.7.30
github.com/aws/aws-sdk-go-v2/internal/v4a	v1.4.22 -> v1.4.31
github.com/aws/aws-sdk-go-v2/service/internal/accept-encoding	v1.13.7 -> v1.13.13
github.com/aws/aws-sdk-go-v2/service/internal/checksum	v1.9.13 -> v1.9.23
github.com/aws/aws-sdk-go-v2/service/internal/presigned-url	v1.13.21 -> v1.13.30
github.com/aws/aws-sdk-go-v2/service/internal/s3shared	v1.19.21 -> v1.19.31
github.com/aws/aws-sdk-go-v2/service/signin	v1.0.9 -> v1.4.0
github.com/aws/aws-sdk-go-v2/service/sso	v1.30.15 -> v1.32.0
github.com/aws/aws-sdk-go-v2/service/ssooidc	v1.35.19 -> v1.37.0
github.com/aws/aws-sdk-go-v2/service/sts	v1.41.10 -> v1.44.0
github.com/aws/smithy-go	v1.24.2 -> v1.27.3

File name: lambda/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):

• 11 additional dependencies were updated

Details:

Package	Change
github.com/aws/aws-sdk-go-v2/credentials	v1.19.14 -> v1.19.28
github.com/aws/aws-sdk-go-v2/feature/ec2/imds	v1.18.21 -> v1.18.30
github.com/aws/aws-sdk-go-v2/internal/configsources	v1.4.21 -> v1.4.30
github.com/aws/aws-sdk-go-v2/internal/endpoints/v2	v2.7.21 -> v2.7.30
github.com/aws/aws-sdk-go-v2/service/internal/accept-encoding	v1.13.7 -> v1.13.13
github.com/aws/aws-sdk-go-v2/service/internal/presigned-url	v1.13.21 -> v1.13.30
github.com/aws/aws-sdk-go-v2/service/signin	v1.0.9 -> v1.4.0
github.com/aws/aws-sdk-go-v2/service/sso	v1.30.15 -> v1.32.0
github.com/aws/aws-sdk-go-v2/service/ssooidc	v1.35.19 -> v1.37.0
github.com/aws/aws-sdk-go-v2/service/sts	v1.41.10 -> v1.44.0
github.com/aws/smithy-go	v1.24.2 -> v1.27.3

[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/null versions matching "~> 3.0"...
- Finding hashicorp/local versions matching "~> 2.0"...
- Installing hashicorp/null v3.2.4...
- Installed hashicorp/null v3.2.4 (signed by HashiCorp)
- Installing hashicorp/local v2.8.0...
- Installed hashicorp/local v2.8.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] 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=3196650288103566860]

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...
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]
null_resource.stack_b: Creation complete after 0s [id=7428081722819201608]

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

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: fix(deps): update aws-sdk-go-v2 monorepo in lambda/go.mod (main) #131
• Branch: renovate/main-aws-sdk-go-v2-monorepo
• Command: plan
• SHA: c62a881
• 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.2.4...
- Installed hashicorp/null v3.2.4 (signed by HashiCorp)
- Installing hashicorp/local v2.8.0...
- Installed hashicorp/local v2.8.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.2.4...
- Installed hashicorp/null v3.2.4 (signed by HashiCorp)
- Installing hashicorp/local v2.8.0...
- Installed hashicorp/local v2.8.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] 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=3507466482357218995]

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=8765085218958696063]
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: fix(deps): update aws-sdk-go-v2 monorepo in lambda/go.mod (main) #131
• Branch: renovate/main-aws-sdk-go-v2-monorepo
• Command: plan
• SHA: 6825aa6
• Repo: devopsfactory-io/neptune

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: fix(deps): update aws-sdk-go-v2 monorepo in lambda/go.mod (main) #131
• Branch: renovate/main-aws-sdk-go-v2-monorepo
• Command: plan
• SHA: 6c2d0d6
• 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] local_file.out: Creating...
null_resource.stack_a: Creating...
null_resource.stack_a: Creation complete after 0s [id=1602788455352738793]
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=4047602468803308907]
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: fix(deps): update aws-sdk-go-v2 monorepo in lambda/go.mod (main) #131
• Branch: renovate/main-aws-sdk-go-v2-monorepo
• Command: plan
• SHA: 4bc4ec6
• 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.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 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=8199359433370328997]
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] local_file.out: Creating...
null_resource.stack_b: Creating...
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]
null_resource.stack_b: Creation complete after 0s [id=8619782565737898870]

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

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: fix(deps): update aws-sdk-go-v2 monorepo in lambda/go.mod (main) #131
• Branch: renovate/main-aws-sdk-go-v2-monorepo
• Command: plan
• SHA: bdd869a
• 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=6873303774854479497]
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=1251025161694264823]
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: fix(deps): update aws-sdk-go-v2 monorepo in lambda/go.mod (main) #131
• Branch: renovate/main-aws-sdk-go-v2-monorepo
• Command: plan
• SHA: 8305cf0
• 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/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 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=3085900009365241939]
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...
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]
null_resource.stack_b: Creation complete after 0s [id=6046235781100598558]

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

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: fix(deps): update aws-sdk-go-v2 monorepo in lambda/go.mod (main) #131
• Branch: renovate/main-aws-sdk-go-v2-monorepo
• Command: plan
• SHA: 26961c7
• 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.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 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/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=3407837753421309921]
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] local_file.out: Creating...
null_resource.stack_b: Creating...
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]
null_resource.stack_b: Creation complete after 0s [id=8145588124582157826]

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

[github-actions]

Lambda integration test executed with success...

client_payload:

• PR: fix(deps): update aws-sdk-go-v2 monorepo in lambda/go.mod (main) #131
• Branch: renovate/main-aws-sdk-go-v2-monorepo
• Command: plan
• SHA: 2cbcb98
• 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.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 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=7818259857956910774]
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=8711779477383111440]
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]

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