{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":17728164,"defaultBranch":"main","name":"terraform","ownerLogin":"hashicorp","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2014-03-13T22:25:48.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/761456?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1717782718.0","currentOid":""},"activityList":{"items":[{"before":null,"after":"efe70f0cb6215384efbd204e1bd872c48bc6aa34","ref":"refs/heads/f-cmd-console-release-lock","pushedAt":"2024-06-07T17:51:58.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"apparentlymart","name":"Martin Atkins","path":"/apparentlymart","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/20180?s=80&v=4"},"commit":{"message":"command/console: Release the state lock once state work is complete\n\nThis therefore avoids holding the lock unnecessarily for the interactive\npart of the console session. This is safe because console will never create\nany new state snapshots based on what it fetched, and so the worst case is\nthat console returns some stale information that was current at the time\nwhen it started up.","shortMessageHtmlLink":"command/console: Release the state lock once state work is complete"}},{"before":null,"after":"185e28fc6b067df4e01aa563d7794e36176deea4","ref":"refs/heads/RK/renameAzureAD","pushedAt":"2024-06-07T17:45:35.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"rkoron007","name":"Rose M Koron","path":"/rkoron007","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/32436232?s=80&v=4"},"commit":{"message":"Rename to Microsoft Entra ID","shortMessageHtmlLink":"Rename to Microsoft Entra ID"}},{"before":"fe8d652fa68c16db38b69532a13d15934e985267","after":"44e3740e391fab011ce4a8e19c36bbefb8e47d68","ref":"refs/heads/liamcervante/deferred-actions/unknown-import-to","pushedAt":"2024-06-07T15:03:20.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"liamcervante","name":"Liam Cervante","path":"/liamcervante","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/56838463?s=80&v=4"},"commit":{"message":"deferred actions: allow unknown foreach attributes within import blocks","shortMessageHtmlLink":"deferred actions: allow unknown foreach attributes within import blocks"}},{"before":null,"after":"fe8d652fa68c16db38b69532a13d15934e985267","ref":"refs/heads/liamcervante/deferred-actions/unknown-import-to","pushedAt":"2024-06-07T14:30:55.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"liamcervante","name":"Liam Cervante","path":"/liamcervante","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/56838463?s=80&v=4"},"commit":{"message":"deferred actions: allow unknown foreach attributes within import blocks","shortMessageHtmlLink":"deferred actions: allow unknown foreach attributes within import blocks"}},{"before":"26b16ebd3eafa654e20f85e2887575542b1675d7","after":"4e296a52b5a79621e94716c3b23feb50471e0f52","ref":"refs/heads/TF-10060","pushedAt":"2024-06-07T13:22:34.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"DanielMSchmidt","name":"Daniel Schmidt","path":"/DanielMSchmidt","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1337046?s=80&v=4"},"commit":{"message":"WIP","shortMessageHtmlLink":"WIP"}},{"before":"fc390038f3f9453e4fa0995b5891044ae60d39a0","after":"26b16ebd3eafa654e20f85e2887575542b1675d7","ref":"refs/heads/TF-10060","pushedAt":"2024-06-07T13:19:50.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"DanielMSchmidt","name":"Daniel Schmidt","path":"/DanielMSchmidt","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1337046?s=80&v=4"},"commit":{"message":"WIP","shortMessageHtmlLink":"WIP"}},{"before":"773e7ea2f8a88551eecc3f7904c6b569990b9190","after":"7f9cfc38dcaf308124429cb5e1b3a0c055e203e1","ref":"refs/heads/nf/may24-data-planned-deferred-changes","pushedAt":"2024-06-06T21:26:57.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"nfagerlund","name":"Nick Fagerlund","path":"/nfagerlund","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/484309?s=80&v=4"},"commit":{"message":"Normalize semi-unknown outputs to wholly unknown when writing to state\n\nWhen deferred actions are enabled, outputs can end up with an unknown value at\nthe end of an apply if they reference a resource or data source that got\ndeferred to a future run. (It looks like outputs can already have unknown values\nat this point even without deferral, but I'm not sure what those scenarios are\nat the moment.)\n\nHowever, it's possible to get confusing results if the output is a structural\ntype and only _some_ of its elements are unknown. (Consider a deferred resource\nwith some computed attributes: we report a deferred change that includes\nconcrete values for the attributes we control, and unknown values for anything\ncomputed. The evaluator will let the output get concrete values for anything\nwe're sure we can predict, and unknowns for the rest.)\n\nThis commit adds an extra normalization step for root output values. If the\nvalue contains _some_ unknown elements, we turn it into a wholly unknown value\nof the appropriate type before serializing to state. (We continue our existing\npractice of serializing unknown root output values as nulls for JSON.) This\nmakes it easier to avoid mistaking the case of \"this one attribute was known to\nhave a null value\" for the case of \"some of the attributes were unknown\".\n\nNote that outputs that reference deferred resources can still end up with\nconcrete values, *IF* they only refer to uncomputed attributes with\nconfig-provided values for resource instances with known instance keys. You\ncould make an argument either way for this, since the resource technically is in\nan \"unready\" (or nonexistent) state, but we do at least know what we're gonna\nset the provided attributes to.","shortMessageHtmlLink":"Normalize semi-unknown outputs to wholly unknown when writing to state"}},{"before":"1d1e979e4682349f66ebe7506296e9a41df6adfa","after":"8e4d4663fe37bbae3c0dc1c0bb20b6bcb17b637c","ref":"refs/heads/main","pushedAt":"2024-06-06T16:59:38.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"liamcervante","name":"Liam Cervante","path":"/liamcervante","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/56838463?s=80&v=4"},"commit":{"message":"cleanup after 1.10.0-alpha20240606 release","shortMessageHtmlLink":"cleanup after 1.10.0-alpha20240606 release"}},{"before":"fc390038f3f9453e4fa0995b5891044ae60d39a0","after":"1d1e979e4682349f66ebe7506296e9a41df6adfa","ref":"refs/heads/main","pushedAt":"2024-06-06T16:54:05.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"liamcervante","name":"Liam Cervante","path":"/liamcervante","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/56838463?s=80&v=4"},"commit":{"message":"prepare for v1.10.0-alpha20240606 release","shortMessageHtmlLink":"prepare for v1.10.0-alpha20240606 release"}},{"before":null,"after":"fc390038f3f9453e4fa0995b5891044ae60d39a0","ref":"refs/heads/TF-10060","pushedAt":"2024-06-06T14:16:05.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"DanielMSchmidt","name":"Daniel Schmidt","path":"/DanielMSchmidt","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1337046?s=80&v=4"},"commit":{"message":"stacks: add tests for and refactor steps when a provider can't be configured (#35294)","shortMessageHtmlLink":"stacks: add tests for and refactor steps when a provider can't be con…"}},{"before":"4faf3830602f2c21d11a8d10c9d7608b92e1c45d","after":"69dd40bae2603249005af23a7a2f58ae2dc45193","ref":"refs/heads/liamcervante/deferred-actions/unknown-import-id","pushedAt":"2024-06-06T11:58:46.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"liamcervante","name":"Liam Cervante","path":"/liamcervante","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/56838463?s=80&v=4"},"commit":{"message":"deferred actinos: add support for unknown ids in import blocks","shortMessageHtmlLink":"deferred actinos: add support for unknown ids in import blocks"}},{"before":"a8d71c22c0798e563f77bf26974cf66848aeb8a6","after":null,"ref":"refs/heads/liamcervante/stacks/unconfigured-provider","pushedAt":"2024-06-06T11:37:20.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"liamcervante","name":"Liam Cervante","path":"/liamcervante","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/56838463?s=80&v=4"}},{"before":"c39233fdda127c200e385fb562470986f1ef8caa","after":"fc390038f3f9453e4fa0995b5891044ae60d39a0","ref":"refs/heads/main","pushedAt":"2024-06-06T11:36:58.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"liamcervante","name":"Liam Cervante","path":"/liamcervante","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/56838463?s=80&v=4"},"commit":{"message":"stacks: add tests for and refactor steps when a provider can't be configured (#35294)","shortMessageHtmlLink":"stacks: add tests for and refactor steps when a provider can't be con…"}},{"before":null,"after":"4faf3830602f2c21d11a8d10c9d7608b92e1c45d","ref":"refs/heads/liamcervante/deferred-actions/unknown-import-id","pushedAt":"2024-06-06T11:27:35.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"liamcervante","name":"Liam Cervante","path":"/liamcervante","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/56838463?s=80&v=4"},"commit":{"message":"deferred actinos: add support for unknown ids in import blocks","shortMessageHtmlLink":"deferred actinos: add support for unknown ids in import blocks"}},{"before":"aa680aad84ecef089b3177e39099ba47816fedbe","after":"c39233fdda127c200e385fb562470986f1ef8caa","ref":"refs/heads/main","pushedAt":"2024-06-06T08:17:19.000Z","pushType":"pr_merge","commitsCount":2,"pusher":{"login":"DanielMSchmidt","name":"Daniel Schmidt","path":"/DanielMSchmidt","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1337046?s=80&v=4"},"commit":{"message":"Merge pull request #35295 from hashicorp/TF-13952","shortMessageHtmlLink":"Merge pull request #35295 from hashicorp/TF-13952"}},{"before":null,"after":"aa680aad84ecef089b3177e39099ba47816fedbe","ref":"refs/heads/TF-13085","pushedAt":"2024-06-06T03:32:00.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"DanielMSchmidt","name":"Daniel Schmidt","path":"/DanielMSchmidt","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1337046?s=80&v=4"},"commit":{"message":"Update CHANGELOG.md","shortMessageHtmlLink":"Update CHANGELOG.md"}},{"before":null,"after":"83bc1bb48549677e2d032852b6d523849a864afc","ref":"refs/heads/f-rpcapi-multipkg","pushedAt":"2024-06-05T22:28:45.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"apparentlymart","name":"Martin Atkins","path":"/apparentlymart","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/20180?s=80&v=4"},"commit":{"message":"rpcapi: Experiment with the API split over multiple protobuf packages\n\nThis was just a trial run to see whether there were any hidden blockers for\nbreaking the \"terraform1\" package up into a number of smaller protobuf\npackages.\n\nIt seems like there are no hard problems here... just a bunch of laborious\nwork to get everything updated.\n\nThe tool we have to generate the \"dynrpcserver\" package is likely to need\nconsiderable work to be able to analyze multiple generated Go packages\ninstead of just one. I didn't attempt that here.","shortMessageHtmlLink":"rpcapi: Experiment with the API split over multiple protobuf packages"}},{"before":"30f552a07e453a1aeeef749966caa9078f11b1d2","after":"9801942f91be33f03974762fe6d3eda42796667d","ref":"refs/heads/f-stacks-state-plan-handles","pushedAt":"2024-06-05T18:07:56.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"apparentlymart","name":"Martin Atkins","path":"/apparentlymart","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/20180?s=80&v=4"},"commit":{"message":"stacks: Track raw stack as separate messages in raw plan\n\nPreviously we had the entire raw prior state serialized as part of the\n\"plan header\" message in the raw plan, which meant that the maximum state\nsize was constrained by the maximum allowed gRPC message size.\n\nInstead now we'll use a separate raw plan element for each raw prior state\nelement, so that we're limited only in the size of individual items rather\nthan size of the state as a whole.\n\nThis deals with the last remaining (non-deprecated) case where our RPC\nprotocol tries to pack an entire raw state or plan into a single protobuf\nmessage, and so we're now standardized on using a streaming approach in\nall cases.","shortMessageHtmlLink":"stacks: Track raw stack as separate messages in raw plan"}},{"before":"ef09817cc14d59dfb1bee25eae043d80fe76f87a","after":"fd2c2cf1c53cf9b584f6dcdd7e50f611947f511f","ref":"refs/heads/v1.9","pushedAt":"2024-06-05T17:20:19.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"jbardin","name":"James Bardin","path":"/jbardin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35067?s=80&v=4"},"commit":{"message":"update CHANGELOG.md","shortMessageHtmlLink":"update CHANGELOG.md"}},{"before":"54b8aa2c5e0eadd3e0642e87cd2505ff09f3c8e4","after":null,"ref":"refs/heads/backport-35261","pushedAt":"2024-06-05T17:17:25.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"jbardin","name":"James Bardin","path":"/jbardin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35067?s=80&v=4"}},{"before":"558575a366dc127f748625fce788aba2fabefdbf","after":"ef09817cc14d59dfb1bee25eae043d80fe76f87a","ref":"refs/heads/v1.9","pushedAt":"2024-06-05T17:17:07.000Z","pushType":"pr_merge","commitsCount":3,"pusher":{"login":"jbardin","name":"James Bardin","path":"/jbardin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35067?s=80&v=4"},"commit":{"message":"Merge pull request #35296 from hashicorp/backport-35261\n\nBackport if #35261","shortMessageHtmlLink":"Merge pull request #35296 from hashicorp/backport-35261"}},{"before":"2aa06cb769101bd39de8c75acaf86accfce6faed","after":"30f552a07e453a1aeeef749966caa9078f11b1d2","ref":"refs/heads/f-stacks-state-plan-handles","pushedAt":"2024-06-05T16:47:51.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"apparentlymart","name":"Martin Atkins","path":"/apparentlymart","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/20180?s=80&v=4"},"commit":{"message":"stacks+rpcapi: Load prior state and plan separately\n\nPreviously we expected clients to provide an inline raw prior state to\nPlanStackChanges and an inline raw plan to ApplyStackChanges, which was\na simpler design but meant that we might end up generating a state or plan\nthat's too large to be submitted in a single gRPC request, which would then\nbe difficult to resolve.\n\nInstead we'll offer separate RPC functions for loading raw state and plan\nusing a gRPC streaming approach, which better mirrors the streaming\napproach we use to _emit_ these artifacts. Although we don't actually need\nthis benefit right now, this makes it possible in principle for a client\nthat's running PlanStackChanges to feed back the raw planned actions\nconcurrently into OpenPlan and thus avoid buffering the whole plan on the\nclient side at all.\n\nThis required resolving the pre-existing FIXME about the inconsistency\nwhere stackeval wants a raw plan for apply but expects the caller to\nhave dealt with loading the prior state for planning. Here it's resolved\nin the direction of the caller (rpcapi) always being responsible for\nloading both artifacts, because that means we can continue supporting the\nold inline approach for a while without that complexity having to infect\nthe lower layers.\n\nIdeally we should remove the legacy approach before this API becomes\nconstrained by compatibility promises, but I've preserved the old API\nfor now to give us some flexibility in when we update the existing\nclients of this API to use the new approach.","shortMessageHtmlLink":"stacks+rpcapi: Load prior state and plan separately"}},{"before":null,"after":"2aa06cb769101bd39de8c75acaf86accfce6faed","ref":"refs/heads/f-stacks-state-plan-handles","pushedAt":"2024-06-05T16:47:25.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"apparentlymart","name":"Martin Atkins","path":"/apparentlymart","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/20180?s=80&v=4"},"commit":{"message":"stacks+rpcapi: Load prior state and plan separately\n\nPreviously we expected clients to provide an inline raw prior state to\nPlanStackChanges and an inline raw plan to ApplyStackChanges, which was\na simpler design but meant that we might end up generating a state or plan\nthat's too large to be submitted in a single gRPC request, which would then\nbe difficult to resolve.\n\nInstead we'll offer separate RPC functions for loading raw state and plan\nusing a gRPC streaming approach, which better mirrors the streaming\napproach we use to _emit_ these artifacts. Although we don't actually need\nthis benefit right now, this makes it possible in principle for a client\nthat's running PlanStackChanges to feed back the raw planned actions\nconcurrently into OpenPlan and thus avoid buffering the whole plan on the\nclient side at all.\n\nThis required resolving the pre-existing FIXME about the inconsistency\nwhere stackeval wants a raw plan for apply but expects the caller to\nhave dealt with loading the prior state for planning. Here it's resolved\nin the direction of the caller (rpcapi) always being responsible for\nloading both artifacts, because that means we can continue supporting the\nold inline approach for a while without that complexity having to infect\nthe lower layers.\n\nIdeally we should remove the legacy approach before this API becomes\nconstrained by compatibility promises, but I've preserved the old API\nfor now to give us some flexibility in when we update the existing\nclients of this API to use the new approach.","shortMessageHtmlLink":"stacks+rpcapi: Load prior state and plan separately"}},{"before":"c823b26eb0b6a95e9ad2c55b1a6aac64d7872382","after":"aa680aad84ecef089b3177e39099ba47816fedbe","ref":"refs/heads/main","pushedAt":"2024-06-05T16:16:14.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"apparentlymart","name":"Martin Atkins","path":"/apparentlymart","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/20180?s=80&v=4"},"commit":{"message":"Update CHANGELOG.md","shortMessageHtmlLink":"Update CHANGELOG.md"}},{"before":"7c928fc10b2f37370d6dbcc1f6e6015fc53e1606","after":"c823b26eb0b6a95e9ad2c55b1a6aac64d7872382","ref":"refs/heads/main","pushedAt":"2024-06-05T16:13:59.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"apparentlymart","name":"Martin Atkins","path":"/apparentlymart","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/20180?s=80&v=4"},"commit":{"message":"Update CHANGELOG.md","shortMessageHtmlLink":"Update CHANGELOG.md"}},{"before":"0ec2d37ff3194f1397a8e545339ddc231d46468c","after":null,"ref":"refs/heads/f-ephemeral-variables","pushedAt":"2024-06-05T16:09:34.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"apparentlymart","name":"Martin Atkins","path":"/apparentlymart","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/20180?s=80&v=4"}},{"before":"0636bf86f597440f0a269c73225edc7c0658ab1d","after":"7c928fc10b2f37370d6dbcc1f6e6015fc53e1606","ref":"refs/heads/main","pushedAt":"2024-06-05T16:09:30.000Z","pushType":"pr_merge","commitsCount":9,"pusher":{"login":"apparentlymart","name":"Martin Atkins","path":"/apparentlymart","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/20180?s=80&v=4"},"commit":{"message":"terraform: terraform.applying returns true during the apply phase\n\nThis new symbol returns an ephemeral boolean flag that is true only during\nthe apply phase and false otherwise. Since this involves an ephemeral\nvalue and those are still experimental, this symbol is also available only\nwhen opted in to the ephemeral_values experiment.\n\nThe intended use for this is to configure a provider with a different (and\nprobably more privileged) role or username during the apply phase when\nTerraform is actually trying to change infrastructure, so that planning\ncan be done with a more limited level of access that might, for example,\nonly allow _reading_ from the remote system.\n\n role_arn = (\n terraform.applying ? local.write_role_arn : local.read_role_arn\n )","shortMessageHtmlLink":"terraform: terraform.applying returns true during the apply phase"}},{"before":"a8e3fab9c747b99b30f302126bacfb0defe25fc7","after":"54b8aa2c5e0eadd3e0642e87cd2505ff09f3c8e4","ref":"refs/heads/backport-35261","pushedAt":"2024-06-05T15:59:55.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"jbardin","name":"James Bardin","path":"/jbardin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35067?s=80&v=4"},"commit":{"message":"Update internal/terraform/node_resource_plan_instance.go\n\nCo-authored-by: kmoe <5575356+kmoe@users.noreply.github.com>","shortMessageHtmlLink":"Update internal/terraform/node_resource_plan_instance.go"}},{"before":null,"after":"a8e3fab9c747b99b30f302126bacfb0defe25fc7","ref":"refs/heads/backport-35261","pushedAt":"2024-06-05T15:57:08.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"jbardin","name":"James Bardin","path":"/jbardin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35067?s=80&v=4"},"commit":{"message":"store CreateBeforeDestroy even when not refreshing\n\nThe ordering for CreateBeforeDestroy is determined by the value stored\nin the resource instance state. If the destroy plan was created with\n`-refresh=false`, _and_ the configuration changed the value of\n`create_before_destroy`, then there was no chance for the state to be\nupdated, and we now have a mismatch between the configuration and the\nstate. This disagreement causes the plan to record the resource\nreplacement as destroy-then-create, but order the apply actions as\ncreate-before-destroy, and since the create is expected to be last, the\ndestroy operation end up showing a noop and is skipped.\n\nThe fix is relatively small, just ensure that we re-write the state when\nthere is no refresh but there was a change in `CreateBeforeDestroy`.\n\nThe replacement ordering optimally should be decided entirely by the\nplan, and then we can rely on the planned changes to determine the\nCreateBeforeDestroy status without re-inspecting the config and state.\nThis would require very careful auditing however, since not all nodes\nare represented exactly in the changes, and the way\n`CreateBeforeDestroy` propagates through the graph is extremely\nimportant for correctness and to prevent cycles.","shortMessageHtmlLink":"store CreateBeforeDestroy even when not refreshing"}},{"before":"c04f023cbfe400415ec9b6a7fa2eec28f434bf29","after":null,"ref":"refs/heads/jbardin/no-refresh-cbd","pushedAt":"2024-06-05T15:53:35.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"jbardin","name":"James Bardin","path":"/jbardin","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35067?s=80&v=4"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEX3kZTgA","startCursor":null,"endCursor":null}},"title":"Activity · hashicorp/terraform"}