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.45.1	v1.46.0
github.com/aws/aws-sdk-go-v2/config	require	minor	v1.32.14 → v1.33.2	v1.33.3
github.com/aws/aws-sdk-go-v2/service/s3	require	minor	v1.98.0 → v1.110.0	v1.111.0
github.com/aws/aws-sdk-go-v2/service/secretsmanager	require	minor	v1.41.5 → v1.47.0	v1.48.0

---

Release Notes

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

v1.45.1

Compare Source

General Highlights

• Bug Fix: Add assurance test for operation order.
• Dependency Update: Updated to the latest SDK module versions

Module Highlights

• github.com/aws/aws-sdk-go-v2/service/elasticache: v1.45.1
  • Documentation: Doc only update, listing 'valkey7' and 'valkey8' as engine options for parameter groups.
• github.com/aws/aws-sdk-go-v2/service/iotmanagedintegrations: v1.0.0
  • Release: New AWS service client module
  • Feature: Adding managed integrations APIs for IoT Device Management to setup and control devices across different manufacturers and connectivity protocols. APIs include managedthing operations, credential and provisioning profile management, notification configuration, and OTA update.
• github.com/aws/aws-sdk-go-v2/service/iotsitewise: v1.47.0
  • Feature: AWS IoT SiteWise now supports MQTT-enabled, V3 gateways. Configure data destinations for real-time ingestion into AWS IoT SiteWise or buffered ingestion using Amazon S3 storage. You can also use path filters for precise data collection from specific MQTT topics.
• github.com/aws/aws-sdk-go-v2/service/rds: v1.94.1
  • Documentation: Note support for Database Insights for Amazon RDS.

v1.45.0

Compare Source

General Highlights

• Dependency Update: Updated to the latest SDK module versions

Module Highlights

• github.com/aws/aws-sdk-go-v2/service/apigateway: v1.38.0
  • Feature: API Gateway supports VPC link V2 for REST APIs.
• github.com/aws/aws-sdk-go-v2/service/athena: v1.56.0
  • Feature: Introduces Spark workgroup features including log persistence, S3/CloudWatch delivery, UI and History Server APIs, and SparkConnect 3.5.6 support. Adds DPU usage limits at workgroup and query levels as well as DPU usage tracking for Capacity Reservation queries to optimize performance and costs.
• github.com/aws/aws-sdk-go-v2/service/bedrock: v1.50.0
  • Feature: Add support to automatically enforce safeguards across accounts within an AWS Organization.
• github.com/aws/aws-sdk-go-v2/service/bedrockagentcorecontrol: v1.14.0
  • Feature: Support for agentcore gateway interceptor configurations and NONE authorizer type
• github.com/aws/aws-sdk-go-v2/service/bedrockdataautomationruntime: v1.9.0
  • Feature: Adding new fields to GetDataAutomationStatus: jobSubmissionTime, jobCompletionTime, and jobDurationInSeconds
• github.com/aws/aws-sdk-go-v2/service/bedrockruntime: v1.45.0
  • Feature: Add support to automatically enforce safeguards across accounts within an AWS Organization.
• github.com/aws/aws-sdk-go-v2/service/cloudformation: v1.71.0
  • Feature: Adds the DependsOn field to the AutoDeployment configuration parameter for CreateStackSet, UpdateStackSet, and DescribeStackSet APIs, allowing users to set and read auto-deployment dependencies between StackSets
• github.com/aws/aws-sdk-go-v2/service/computeoptimizerautomation: v1.0.0
  • Release: New AWS service client module
  • Feature: Initial release of AWS Compute Optimizer Automation. Create automation rules to implement recommended actions on a recurring schedule based on your specified criteria. Supported actions include: snapshot and delete unattached EBS volumes and upgrade volume types to the latest generation.
• github.com/aws/aws-sdk-go-v2/service/connect: v1.148.0
  • Feature: New APIs to support aliases and versions for ContactFlowModule. Updated ContactFlowModule APIs to support custom blocks.
• github.com/aws/aws-sdk-go-v2/service/controltower: v1.28.0
  • Feature: The manifest field is now optional for the AWS Control Tower CreateLandingZone and UpdateLandingZone APIs for Landing Zone version 4.0
• github.com/aws/aws-sdk-go-v2/service/ec2: v1.274.0
  • Feature: This release adds a new capability to create and manage interruptible EC2 Capacity Reservations.
• github.com/aws/aws-sdk-go-v2/service/ecr: v1.54.0
  • Feature: Add support for ECR managed signing
• github.com/aws/aws-sdk-go-v2/service/eks: v1.75.0
  • Feature: Adds support for controlPlaneScalingConfig on EKS Clusters.
• github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2: v1.54.1
  • Documentation: This release adds the health check log feature in ALB, allowing customers to send detailed target health check log data directly to their designated Amazon S3 bucket.
• github.com/aws/aws-sdk-go-v2/service/invoicing: v1.9.0
  • Feature: Added the CreateProcurementPortalPreference, GetProcurementPortalPreference, PutProcurementPortalPreference, UpdateProcurementPortalPreferenceStatus, ListProcurementPortalPreferences and DeleteProcurementPortalPreference APIs for procurement portal preference management.
• github.com/aws/aws-sdk-go-v2/service/kinesisvideo: v1.33.0
  • Feature: This release adds support for Tiered Storage
• github.com/aws/aws-sdk-go-v2/service/kms: v1.49.0
  • Feature: Support for on-demand rotation of AWS KMS Multi-Region keys with imported key material
• github.com/aws/aws-sdk-go-v2/service/lambda: v1.83.0
  • Feature: Launching Enhanced Error Handling and ESM Grouping capabilities for Kafka ESMs
• github.com/aws/aws-sdk-go-v2/service/lexmodelsv2: v1.58.0
  • Feature: Adds support for Intent Disambiguation, allowing resolution of ambiguous user inputs when multiple intents match by presenting clarifying questions to users. Also adds Speech Detection Sensitivity configuration for optimizing voice activity detection sensitivity levels in various noise environments.
• github.com/aws/aws-sdk-go-v2/service/marketplaceentitlementservice: v1.35.0
  • Feature: Endpoint update for new region
• github.com/aws/aws-sdk-go-v2/service/marketplacemetering: v1.35.0
  • Feature: Endpoint update for new region
• github.com/aws/aws-sdk-go-v2/service/mediapackagev2: v1.34.0
  • Feature: Adds support for excluding session key tags from HLS multivariant playlists
• github.com/aws/aws-sdk-go-v2/service/odb: v1.6.0
  • Feature: Adds AssociateIamRoleToResource and DisassociateIamRoleFromResource APIs for managing IAM roles. Enhances CreateOdbNetwork and UpdateOdbNetwork APIs with KMS, STS, and cross-region S3 parameters. Adds OCI identity domain support to InitializeService API.
• github.com/aws/aws-sdk-go-v2/service/organizations: v1.48.0
  • Feature: Add support for policy operations on the UPGRADE_ROLLOUT_POLICY policy type.
• github.com/aws/aws-sdk-go-v2/service/qconnect: v1.24.0
  • Feature: This release introduces two new messaging channel subtypes: Push, WhatsApp, under MessageTemplate which is a resource in Amazon Q in Connect.
• github.com/aws/aws-sdk-go-v2/service/quicksight: v1.98.0
  • Feature: Amazon Quick Suite now supports QuickChat as an embedding type when calling the GenerateEmbedUrlForRegisteredUser API, enabling developers to embed conversational AI agents directly into their applications.
• github.com/aws/aws-sdk-go-v2/service/rds: v1.111.0
  • Feature: Add support for Upgrade Rollout Order
• github.com/aws/aws-sdk-go-v2/service/redshift: v1.61.0
  • Feature: Added support for Amazon Redshift Federated Permissions and AWS IAM Identity Center trusted identity propagation.
• github.com/aws/aws-sdk-go-v2/service/redshiftserverless: v1.32.0
  • Feature: Added UpdateLakehouseConfiguration API to manage Amazon Redshift Federated Permissions and AWS IAM Identity Center trusted identity propagation for namespaces.
• github.com/aws/aws-sdk-go-v2/service/sagemaker: v1.226.0
  • Feature: Enhanced SageMaker HyperPod instance groups with support for MinInstanceCount, CapacityRequirements (Spot/On-Demand), and KubernetesConfig (labels and taints). Also Added speculative decoding and MaxInstanceCount for model optimization jobs.
• github.com/aws/aws-sdk-go-v2/service/sagemakerruntimehttp2: v1.0.0
  • Release: New AWS service client module
  • Feature: Add support for bidirectional streaming invocations on SageMaker AI real-time endpoints
• github.com/aws/aws-sdk-go-v2/service/securityir: v1.10.0
  • Feature: Add ListInvestigations and SendFeedback APIs to support SecurityIR AI agents
• github.com/aws/aws-sdk-go-v2/service/sesv2: v1.55.0
  • Feature: Added support for new SES regions - Asia Pacific (Malaysia) and Canada (Calgary)
• github.com/aws/aws-sdk-go-v2/service/transfer: v1.68.0
  • Feature: Adds support for creating Webapps accessible from a VPC.

v1.44.0

Compare Source

General Highlights

• Dependency Update: Updated to the latest SDK module versions

Module Highlights

• github.com/aws/aws-sdk-go-v2/service/apigateway: v1.37.0
  • Feature: API Gateway now supports response streaming and new security policies for REST APIs and custom domain names.
• github.com/aws/aws-sdk-go-v2/service/apigatewayv2: v1.33.0
  • Feature: Support for API Gateway portals and portal products.
• github.com/aws/aws-sdk-go-v2/service/backup: v1.54.0
  • Feature: Amazon GuardDuty Malware Protection now supports AWS Backup, extending malware detection capabilities to EC2, EBS, and S3 backups.
• github.com/aws/aws-sdk-go-v2/service/bcmpricingcalculator: v1.10.0
  • Feature: Add GroupSharingPreference, CostCategoryGroupSharingPreferenceArn, and CostCategoryGroupSharingPreferenceEffectiveDate to Bill Estimate. Add GroupSharingPreference and CostCategoryGroupSharingPreferenceArn to Bill Scenario.
• github.com/aws/aws-sdk-go-v2/service/bedrockruntime: v1.44.0
  • Feature: This release includes support for Search Results.
• github.com/aws/aws-sdk-go-v2/service/billing: v1.9.0
  • Feature: Added name filtering support to ListBillingViews API through the new names parameter to efficiently filter billing views by name.
• github.com/aws/aws-sdk-go-v2/service/billingconductor: v1.27.0
  • Feature: This release adds support for Billing Transfers, enabling management of billing transfers with billing groups on AWS Billing Conductor.
• github.com/aws/aws-sdk-go-v2/service/cloudtrail: v1.54.0
  • Feature: AWS CloudTrail now supports Insights for data events, expanding beyond management events to automatically detect unusual activity on data plane operations.
• github.com/aws/aws-sdk-go-v2/service/cloudwatchlogs: v1.60.0
  • Feature: Adding support for ocsf version 1.5, add optional parameter MappingVersion
• github.com/aws/aws-sdk-go-v2/service/connectcampaignsv2: v1.9.0
  • Feature: This release added support for ring timer configuration for campaign calls.
• github.com/aws/aws-sdk-go-v2/service/costexplorer: v1.60.0
  • Feature: Add support for COST_CATEGORY, TAG, and LINKED_ACCOUNT AWS managed cost anomaly detection monitors
• github.com/aws/aws-sdk-go-v2/service/costoptimizationhub: v1.21.0
  • Feature: Release ListEfficiencyMetrics API
• github.com/aws/aws-sdk-go-v2/service/datazone: v1.48.0
  • Feature: Amazon DataZone now supports business metadata (readme and metadata forms) at the individual attribute (column) level, a new rule type for glossary terms, and the ability to update the owner of the root domain unit.
• github.com/aws/aws-sdk-go-v2/service/dynamodb: v1.53.0
  • Feature: Extended Global Secondary Index (GSI) composite keys to support up to 8 attributes.
• github.com/aws/aws-sdk-go-v2/service/ec2: v1.272.0
  • Feature: This launch adds support for two new features: Regional NAT Gateway and IPAM Policies. IPAM policies offers customers central control for public IPv4 assignments across AWS services. Regional NAT is a single NAT Gateway that automatically expands across AZs in a VPC to maintain high availability.
• github.com/aws/aws-sdk-go-v2/service/ecr: v1.53.0
  • Feature: Add support for ECR archival storage class and Inspector org policy for scanning
• github.com/aws/aws-sdk-go-v2/service/ecs: v1.68.0
  • Feature: Added support for Amazon ECS Managed Instances infrastructure optimization configuration.
• github.com/aws/aws-sdk-go-v2/service/emr: v1.56.0
  • Feature: Add CloudWatch Logs integration for Spark driver, executor and step logs
• github.com/aws/aws-sdk-go-v2/service/fsx: v1.64.0
  • Feature: Adding File Server Resource Manager configuration to FSx Windows
• github.com/aws/aws-sdk-go-v2/service/guardduty: v1.68.0
  • Feature: Add support for scanning and viewing scan results for backup resource types
• github.com/aws/aws-sdk-go-v2/service/health: v1.35.0
  • Feature: Adds actionability and personas properties to Health events exposed through DescribeEvents, DescribeEventsForOrganization, DescribeEventDetails, and DescribeEventTypes APIs. Adds filtering by actionabilities and personas in EventFilter, OrganizationEventFilter, EventTypeFilter.
• github.com/aws/aws-sdk-go-v2/service/iam: v1.52.0
  • Feature: Added the EnableOutboundWebIdentityFederation, DisableOutboundWebIdentityFederation and GetOutboundWebIdentityFederationInfo APIs for the IAM outbound federation feature.
• github.com/aws/aws-sdk-go-v2/service/inspector2: v1.45.0
  • Feature: This release introduces BLOCKED_BY_ORGANIZATION_POLICY error code and IMAGE_ARCHIVED scanStatusReason. BLOCKED_BY_ORGANIZATION_POLICY error code is returned when an operation is blocked by an AWS Organizations policy. IMAGE_ARCHIVED scanStatusReason is returned when an Image is archived in ECR.
• github.com/aws/aws-sdk-go-v2/service/invoicing: v1.8.0
  • Feature: Add support for adding Billing transfers in Invoice configuration
• github.com/aws/aws-sdk-go-v2/service/lambda: v1.82.0
  • Feature: Added support for creating and invoking Tenant Isolated functions in AWS Lambda APIs.
• github.com/aws/aws-sdk-go-v2/service/mediaconnect: v1.46.0
  • Feature: This release adds support for global routing in AWS Elemental MediaConnect. You can now use router inputs and router outputs to manage global video and audio routing workflows both within the AWS-Cloud and over the public internet.
• github.com/aws/aws-sdk-go-v2/service/medialive: v1.87.0
  • Feature: MediaLive is adding support for MediaConnect Router by supporting a new input type called MEDIACONNECT_ROUTER. This new input type will provide seamless encrypted transport between MediaConnect Router and your MediaLive channel.
• github.com/aws/aws-sdk-go-v2/service/networkfirewall: v1.58.0
  • Feature: Partner Managed Rulegroup feature support
• github.com/aws/aws-sdk-go-v2/service/networkflowmonitor: v1.11.0
  • Feature: Added new enum value (AWS::EKS::Cluster) for type field under MonitorLocalResource
• github.com/aws/aws-sdk-go-v2/service/partnercentralchannel: v1.0.0
  • Release: New AWS service client module
  • Feature: Initial GA launch of Partner Central Channel
• github.com/aws/aws-sdk-go-v2/service/route53: v1.60.0
  • Feature: Add dual-stack endpoint support for Route53
• github.com/aws/aws-sdk-go-v2/service/rum: v1.30.0
  • Feature: CloudWatch RUM now supports mobile application monitoring for Android and iOS platforms
• github.com/aws/aws-sdk-go-v2/service/s3: v1.91.0
  • Feature: Adds support for blocking SSE-C writes to general purpose buckets.
• github.com/aws/aws-sdk-go-v2/service/sagemaker: v1.224.0
  • Feature: Added support for enhanced metrics for SageMaker AI Endpoints. This features provides Utilization Metrics at instance and container granularity and also provides easy configuration of metric publish frequency from 10 sec -> 5 mins
• github.com/aws/aws-sdk-go-v2/service/secretsmanager: v1.40.0
  • Feature: Adds support to create, update, retrieve, rotate, and delete managed external secrets.
• github.com/aws/aws-sdk-go-v2/service/sfn: v1.40.0
  • Feature: Adds support to TestState for mocked results and exceptions, along with additional inspection data.
• github.com/aws/aws-sdk-go-v2/service/signin: v1.0.0
  • Release: New AWS service client module
  • Feature: AWS Sign-In manages authentication for AWS services. This service provides secure authentication flows for accessing AWS resources from the console and developer tools. This release adds the CreateOAuth2Token API, which can be used to fetch OAuth2 access tokens and refresh tokens from Sign-In.
• github.com/aws/aws-sdk-go-v2/service/sts: v1.41.0
  • Feature: IAM now supports outbound identity federation via the STS GetWebIdentityToken API, enabling AWS workloads to securely authenticate with external services using short-lived JSON Web Tokens.
• github.com/aws/aws-sdk-go-v2/service/transcribestreaming: v1.33.0
  • Feature: This release adds support for additional locales in AWS transcribe streaming.

v1.43.8

Compare Source

General Highlights

• Dependency Update: Update to smithy-go v1.27.10.
• Dependency Update: Updated to the latest SDK module versions

Module Highlights

• github.com/aws/aws-sdk-go-v2: v1.43.8
  • Bug Fix: Make X-Amz-Checksum-Mode appear on query parameters on presigned URLs
• github.com/aws/aws-sdk-go-v2/service/account: v1.36.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/acmpca: v1.51.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/autoscaling: v1.73.0
  • Feature: Adds support for Distribution Segments in mixed instances policies, providing ordered prioritization across On-Demand Capacity Reservations, Capacity Blocks, interruptible Capacity Reservations, and On-Demand capacity.
• github.com/aws/aws-sdk-go-v2/service/billingconductor: v1.33.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/cloudcontrol: v1.33.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/cloudhsmv2: v1.38.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/cloudwatchevents: v1.36.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/codebuild: v1.73.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/codegurureviewer: v1.38.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/codepipeline: v1.50.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/dataexchange: v1.45.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/deadline: v1.37.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/detective: v1.42.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/devopsagent: v1.11.0
  • Feature: Adds the UpdateApprovalAction API for resolving agent action approvals in AWS DevOps Agent agent spaces.
• github.com/aws/aws-sdk-go-v2/service/directoryservice: v1.42.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/drs: v1.44.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/ec2: v1.323.0
  • Feature: Fleet feature to support Capacity Reservation Resource Groups with Amazon EC2 Capacity Blocks and interruptible Capacity Reservations
• github.com/aws/aws-sdk-go-v2/service/eks: v1.93.0
  • Feature: This feature would give customers the ability to tune TerminatedPodGcThreshold configuration in an Amazon EKS cluster.
• github.com/aws/aws-sdk-go-v2/service/emrcontainers: v1.46.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/eventbridge: v1.49.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/evs: v1.14.0
  • Feature: EVS now supports i7i.metal-48xl EC2 bare metal instance type, delivering high random IOPS performance with real-time latency, ideal for IO intensive and latency-sensitive workloads such as transactional databases, real-time analytics, and AI ML pre-processing.
• github.com/aws/aws-sdk-go-v2/service/frauddetector: v1.45.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/fsx: v1.69.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/globalaccelerator: v1.39.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/iamtoolbox: v1.0.0
  • Release: New AWS service client module
  • Feature: AWS Identity and Access Management (IAM) announces access troubleshooter, helping you debug access denied errors faster. Supported error messages now include an identifier you can use to retrieve detailed evaluations of the policies considered and their results. Preview in US East (N. Virginia).
• github.com/aws/aws-sdk-go-v2/service/inspector: v1.34.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/iot: v1.78.0
  • Feature: As part of this release, we are extending capability of AWS IoT Rules Engine to support IoT InfluxDB Action. The IoT InfluxDB action lets customers send messages from IoT sensors and applications to InfluxDB.
• github.com/aws/aws-sdk-go-v2/service/iotsecuretunneling: v1.37.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/iottwinmaker: v1.33.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/ivs: v1.56.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/ivsrealtime: v1.38.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/licensemanager: v1.42.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/marketplacecatalog: v1.46.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/marketplacemetering: v1.40.3
  • Documentation: Updated documentation to clarify duplicate-billing prevention and BatchMeterUsage retry guidance
• github.com/aws/aws-sdk-go-v2/service/mediapackage: v1.43.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/mediapackagevod: v1.43.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/mediastore: v1.33.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/networkmanager: v1.45.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/outposts: v1.68.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/paymentcryptography: v1.34.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/pi: v1.40.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/qconnect: v1.35.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/resourceexplorer2: v1.28.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/servicecatalogappregistry: v1.39.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/servicediscovery: v1.44.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/shield: v1.38.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/signer: v1.36.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/storagegateway: v1.47.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/swf: v1.38.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/transcribestreaming: v1.39.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/transfer: v1.76.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/translate: v1.37.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/voiceid: v1.34.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/vpclattice: v1.27.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/wafv2: v1.78.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/wisdom: v1.36.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/workspacesthinclient: v1.24.0
  • Feature: Enable schema-based (de)serialization for this service.
• github.com/aws/aws-sdk-go-v2/service/xray: v1.40.0
  • Feature: Enable schema-based (de)serialization for this service.

v1.43.7

Compare Source

Module Highlights

• github.com/aws/aws-sdk-go-v2/service/aiops: v1.7.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/applicationcostprofiler: v1.28.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/apprunner: v1.40.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/backup: v1.57.0
  • Feature: Launching S3 PITR malware scanning support for AWS Backup
• github.com/aws/aws-sdk-go-v2/service/batch: v1.65.0
  • Feature: Increase the maximum value of jobExecutionTimeoutMinutes to support longer job timeouts during compute environment infrastructure updates.
• github.com/aws/aws-sdk-go-v2/service/bcmdataexports: v1.16.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/bedrockagentcore: v1.27.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/bedrockagentcorecontrol: v1.40.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/bedrockdataautomation: v1.15.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/billing: v1.11.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/budgets: v1.43.7
  • Documentation: AWS Budget Name Validation Documentation Updates.
• github.com/aws/aws-sdk-go-v2/service/chimesdkidentity: v1.28.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/chimesdkmediapipelines: v1.27.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/cleanrooms: v1.45.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/cleanroomsml: v1.24.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/codeconnections: v1.11.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/connecthealth: v1.2.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/controlcatalog: v1.15.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/datazone: v1.62.0
  • Feature: Added resourceConfigurations and allowUserProvidedConfigurations fields to environment blueprint configuration APIs, enabling customers who migrated from V1 to V2 domains to update resource configurations (such as lineage schedules) programmatically via the SDK.
• github.com/aws/aws-sdk-go-v2/service/devopsguru: v1.41.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/emrserverless: v1.41.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/evs: v1.10.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/greengrassv2: v1.43.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/guardduty: v1.78.0
  • Feature: Add malware scan support for Continuous Backups, also known as Point-In-Time Recovery Points (PITR).
• github.com/aws/aws-sdk-go-v2/service/identitystore: v1.37.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/iotmanagedintegrations: v1.10.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/ivschat: v1.22.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/keyspacesstreams: v1.7.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/kinesisvideowebrtcstorage: v1.21.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/managedblockchainquery: v1.23.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/marketplaceagreement: v1.16.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/mediapackagev2: v1.39.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/medicalimaging: v1.26.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/notifications: v1.8.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/observabilityadmin: v1.16.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/odb: v1.11.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/osis: v1.22.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/partnercentralchannel: v1.2.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/pcaconnectorscep: v1.12.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/pipes: v1.24.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/redshiftserverless: v1.35.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/resiliencehub: v1.36.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/resourcegroupstaggingapi: v1.32.0
  • Feature: The GetResources API now returns MissingTagKeys in ComplianceDetails, listing tag keys defined as required in the ReportRequiredTagBlock block of the effective tag policy that are absent from the resource.
• github.com/aws/aws-sdk-go-v2/service/rolesanywhere: v1.23.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/route53globalresolver: v1.3.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/s3tables: v1.16.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/sagemakeredge: v1.32.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/sagemakergeospatial: v1.20.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/scheduler: v1.18.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/servicediscovery: v1.40.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/servicequotas: v1.35.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/ssmquicksetup: v1.9.0
  • Feature: Adding new BDD representation of endpoint ruleset
• github.com/aws/aws-sdk-go-v2/service/workspacesthinclient: v1.21.0
  • Feature: Adding new BDD representation of endpoint ruleset

v1.43.6

v1.43.5

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
  • **Bu

✂ 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

Due to Go's usage of Minimal Version Selection (MVS), these packages have been updated to the minimum version available, so will still abide by minimumReleaseAge=5 days

Details:

Package	Change
github.com/aws/aws-sdk-go-v2/aws/protocol/eventstream	v1.7.8 -> v1.7.20
github.com/aws/aws-sdk-go-v2/credentials	v1.19.14 -> v1.20.2
github.com/aws/aws-sdk-go-v2/feature/ec2/imds	v1.18.21 -> v1.19.1
github.com/aws/aws-sdk-go-v2/internal/configsources	v1.4.21 -> v1.5.1
github.com/aws/aws-sdk-go-v2/internal/endpoints/v2	v2.7.21 -> v2.8.1
github.com/aws/aws-sdk-go-v2/internal/v4a	v1.4.22 -> v1.5.1
github.com/aws/aws-sdk-go-v2/service/internal/accept-encoding	v1.13.7 -> v1.13.19
github.com/aws/aws-sdk-go-v2/service/internal/checksum	v1.9.13 -> v1.11.1
github.com/aws/aws-sdk-go-v2/service/internal/presigned-url	v1.13.21 -> v1.14.1
github.com/aws/aws-sdk-go-v2/service/internal/s3shared	v1.19.21 -> v1.20.1
github.com/aws/aws-sdk-go-v2/service/signin	v1.0.9 -> v1.8.0
github.com/aws/aws-sdk-go-v2/service/sso	v1.30.15 -> v1.36.0
github.com/aws/aws-sdk-go-v2/service/ssooidc	v1.35.19 -> v1.41.0
github.com/aws/aws-sdk-go-v2/service/sts	v1.41.10 -> v1.48.0
github.com/aws/smithy-go	v1.24.2 -> v1.28.1

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

Due to Go's usage of Minimal Version Selection (MVS), these packages have been updated to the minimum version available, so will still abide by minimumReleaseAge=5 days

Details:

Package	Change
github.com/aws/aws-sdk-go-v2/credentials	v1.19.14 -> v1.20.2
github.com/aws/aws-sdk-go-v2/feature/ec2/imds	v1.18.21 -> v1.19.1
github.com/aws/aws-sdk-go-v2/internal/configsources	v1.4.21 -> v1.5.1
github.com/aws/aws-sdk-go-v2/internal/endpoints/v2	v2.7.21 -> v2.8.1
github.com/aws/aws-sdk-go-v2/service/internal/accept-encoding	v1.13.7 -> v1.13.19
github.com/aws/aws-sdk-go-v2/service/internal/presigned-url	v1.13.21 -> v1.14.1
github.com/aws/aws-sdk-go-v2/service/signin	v1.0.9 -> v1.8.0
github.com/aws/aws-sdk-go-v2/service/sso	v1.30.15 -> v1.36.0
github.com/aws/aws-sdk-go-v2/service/ssooidc	v1.35.19 -> v1.41.0
github.com/aws/aws-sdk-go-v2/service/sts	v1.41.10 -> v1.48.0
github.com/aws/smithy-go	v1.24.2 -> v1.28.1

[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]

🌊 Neptune Plan Results

Terraform Stacks: stack-a, stack-b

Neptune completed the plan with status: ✅

For more details, see the GitHub Actions run

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

Click to see the command output

stderr:


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

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

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

Terraform has been successfully initialized!

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

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

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

Click to see the command output

stderr:


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

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

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

Terraform has been successfully initialized!

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

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

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

Click to see the command output

stderr:


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

Terraform will perform the following actions:

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

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

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

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

Saved the plan to: tfplan

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

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

Click to see the command output

stderr:


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

Terraform will perform the following actions:

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

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

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

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

Saved the plan to: tfplan

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

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

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

Click to see the command output

stderr:


stdout:
[stack-a] local_file.out: Creating...
null_resource.stack_a: Creating...
null_resource.stack_a: Creation complete after 0s [id=5293755628728291549]
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=6857478873884772456]
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: 8c38cd3
• Repo: devopsfactory-io/neptune

[github-actions]

🌊 Neptune Plan Results

Terraform Stacks: stack-a, stack-b

Neptune completed the plan with status: ✅

For more details, see the GitHub Actions run

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

Click to see the command output

stderr:


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

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

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

Terraform has been successfully initialized!

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

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

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

Click to see the command output

stderr:


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

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

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

Terraform has been successfully initialized!

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

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

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

Click to see the command output

stderr:


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

Terraform will perform the following actions:

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

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

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

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

Saved the plan to: tfplan

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

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

Click to see the command output

stderr:


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

Terraform will perform the following actions:

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

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

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

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

Saved the plan to: tfplan

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

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

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

Click to see the command output

stderr:


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

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

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

Click to see the command output

stderr:


stdout:
[stack-b] local_file.out: Creating...
null_resource.stack_b: Creating...
null_resource.stack_b: Creation complete after 0s [id=8955438704348488956]
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: d353ac5
• 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.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

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

Terraform has been successfully initialized!

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

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

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

Click to see the command output

stderr:


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

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

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

Terraform has been successfully initialized!

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

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

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

Click to see the command output

stderr:


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

Terraform will perform the following actions:

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

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

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

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

Saved the plan to: tfplan

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

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

Click to see the command output

stderr:


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

Terraform will perform the following actions:

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

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

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

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

Saved the plan to: tfplan

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

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

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

Click to see the command output

stderr:


stdout:
[stack-a] null_resource.stack_a: Creating...
null_resource.stack_a: Creation complete after 0s [id=8664113090340879463]
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...
null_resource.stack_b: Creation complete after 0s [id=5923476529523941335]
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: c3bfed7
• Repo: devopsfactory-io/neptune

[github-actions]

🌊 Neptune Plan Results

Terraform Stacks: stack-a, stack-b

Neptune completed the plan with status: ✅

For more details, see the GitHub Actions run

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

Click to see the command output

stderr:


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

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

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

Terraform has been successfully initialized!

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

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

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

Click to see the command output

stderr:


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

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

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

Terraform has been successfully initialized!

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

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

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

Click to see the command output

stderr:


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

Terraform will perform the following actions:

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

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

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

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

Saved the plan to: tfplan

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

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

Click to see the command output

stderr:


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

Terraform will perform the following actions:

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

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

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

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

Saved the plan to: tfplan

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

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

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

Click to see the command output

stderr:


stdout:
[stack-a] null_resource.stack_a: Creating...
null_resource.stack_a: Creation complete after 0s [id=5267425663372994050]
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=2113880465157686143]
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: 22f03aa
• 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.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)

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

Terraform has been successfully initialized!

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

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

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

Click to see the command output

stderr:


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

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

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

Terraform has been successfully initialized!

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

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

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

Click to see the command output

stderr:


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

Terraform will perform the following actions:

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

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

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

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

Saved the plan to: tfplan

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

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

Click to see the command output

stderr:


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

Terraform will perform the following actions:

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

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

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

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

Saved the plan to: tfplan

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

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

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

Click to see the command output

stderr:


stdout:
[stack-a] null_resource.stack_a: Creating...
null_resource.stack_a: Creation complete after 0s [id=3370972471002021047]
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=6613789491240681711]
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: aa0e3ac
• Repo: devopsfactory-io/neptune

[github-actions]

🌊 Neptune Plan Results

Terraform Stacks: stack-a, stack-b

Neptune completed the plan with status: ✅

For more details, see the GitHub Actions run

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

Click to see the command output

stderr:


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

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

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

Terraform has been successfully initialized!

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

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

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

Click to see the command output

stderr:


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

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

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

Terraform has been successfully initialized!

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

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

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

Click to see the command output

stderr:


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

Terraform will perform the following actions:

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

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

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

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

Saved the plan to: tfplan

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

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

Click to see the command output

stderr:


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

Terraform will perform the following actions:

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

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

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

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

Saved the plan to: tfplan

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

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

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

Click to see the command output

stderr:


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

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

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

Click to see the command output

stderr:


stdout:
[stack-b] local_file.out: Creating...
null_resource.stack_b: Creating...
null_resource.stack_b: Creation complete after 0s [id=1417273673671433996]
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: 828b202
• Repo: devopsfactory-io/neptune

[github-actions]

🌊 Neptune Plan Results

Terraform Stacks: stack-a, stack-b

Neptune completed the plan with status: ✅

For more details, see the GitHub Actions run

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

Click to see the command output

stderr:


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

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

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

Terraform has been successfully initialized!

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

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

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

Click to see the command output

stderr:


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

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

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

Terraform has been successfully initialized!

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

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

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

Click to see the command output

stderr:


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

Terraform will perform the following actions:

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

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

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

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

Saved the plan to: tfplan

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

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

Click to see the command output

stderr:


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

Terraform will perform the following actions:

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

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

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

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

Saved the plan to: tfplan

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

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

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

Click to see the command output

stderr:


stdout:
[stack-a] null_resource.stack_a: Creating...
null_resource.stack_a: Creation complete after 0s [id=6383120596850030493]
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...
null_resource.stack_b: Creation complete after 0s [id=5922254049236904687]
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: 0465f49
• 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.1...
- Installed hashicorp/null v3.3.1 (signed by HashiCorp)
- Installing hashicorp/local v2.9.0...
- Installed hashicorp/local v2.9.0 (signed by HashiCorp)

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

Terraform has been successfully initialized!

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

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

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

Click to see the command output

stderr:


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

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

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

Terraform has been successfully initialized!

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

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

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

Click to see the command output

stderr:


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

Terraform will perform the following actions:

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

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

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

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

Saved the plan to: tfplan

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

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

Click to see the command output

stderr:


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

Terraform will perform the following actions:

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

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

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

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

Saved the plan to: tfplan

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

To apply these changes, comment:

@neptbot apply

[github-actions]

🌊 Neptune Apply Results

Terraform Stacks: stack-a, stack-b

Neptune completed the apply with status: ✅

For more details, see the GitHub Actions run

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

Click to see the command output

stderr:


stdout:
[stack-a] null_resource.stack_a: Creating...
local_file.out: Creating...
null_resource.stack_a: Creation complete after 0s [id=1729325202596409303]
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=3527274522693145026]
local_file.out: Creation complete after 0s [id=2d8eff4b1ddeb10a7cfb78093bc91edb5b3318f8]

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