{"push_id":2894278025,"size":9,"distinct_size":2,"ref":"refs/heads/f-hcl2-providertypes","head":"b71590d76c6fe9f93f59563db8e89a62cd1e1567","before":"923d648cfca98e8d62cbdc2324822b3b682bd2f9","commits":[{"sha":"d28d03695425d818f25280ede1084a637619d05d","author":{"name":"James Bardin","email":"62973226c85cb5a1996aaed2ce372ac02dcad8b7@gmail.com"},"message":"make NodePlannableResource eval-able\n\nEval a NodePlannableResource before expanding it, to ensure that it can\nbe referenced even if the count is 0.","distinct":false,"url":"https://api.github.com/repos/hashicorp/terraform/commits/d28d03695425d818f25280ede1084a637619d05d"},{"sha":"bc31dc3d36a8f8e153fcab5f135785b7f7287bdb","author":{"name":"James Bardin","email":"62973226c85cb5a1996aaed2ce372ac02dcad8b7@gmail.com"},"message":"add a nested map test to hcl2shim","distinct":false,"url":"https://api.github.com/repos/hashicorp/terraform/commits/bc31dc3d36a8f8e153fcab5f135785b7f7287bdb"},{"sha":"95ad735684833cdeb516a8b087a480117eae184e","author":{"name":"James Bardin","email":"62973226c85cb5a1996aaed2ce372ac02dcad8b7@gmail.com"},"message":"complete the context plan test conversions","distinct":false,"url":"https://api.github.com/repos/hashicorp/terraform/commits/95ad735684833cdeb516a8b087a480117eae184e"},{"sha":"133b9b5af012b365b150d64c679500864f97d531","author":{"name":"Martin Atkins","email":"a1bdfbfb01322b54f9edf8cea8f328c9384b211a@degeneration.co.uk"},"message":"core: Only skip _create-time_ provisioners when not creating new object\n\nWe need to run destroy-time provisioners even when we're not creating a\nnew object.","distinct":false,"url":"https://api.github.com/repos/hashicorp/terraform/commits/133b9b5af012b365b150d64c679500864f97d531"},{"sha":"3da35cab988c0d116d60798f5d73bc75b2be5ff7","author":{"name":"Martin Atkins","email":"a1bdfbfb01322b54f9edf8cea8f328c9384b211a@degeneration.co.uk"},"message":"core: in testApplyFn, force attribute \"id\" to match ID field\n\nThese two being distinct is an old-world concept, but we need to ensure\nthat they match properly here to ensure that we don't leave dangling\nincorrect values for \"id\".","distinct":false,"url":"https://api.github.com/repos/hashicorp/terraform/commits/3da35cab988c0d116d60798f5d73bc75b2be5ff7"},{"sha":"776266c93499d55a548b8c3caf647d8e91efe0cc","author":{"name":"Martin Atkins","email":"a1bdfbfb01322b54f9edf8cea8f328c9384b211a@degeneration.co.uk"},"message":"core: Additional TRACE logging for EvalDeposeState\n\nThis is useful to get a read on which DeposedKey was generated to\ncorrelate with other logs later in the output.","distinct":false,"url":"https://api.github.com/repos/hashicorp/terraform/commits/776266c93499d55a548b8c3caf647d8e91efe0cc"},{"sha":"1541ffe6834839148865f8306556890d1e6ddbdb","author":{"name":"Martin Atkins","email":"a1bdfbfb01322b54f9edf8cea8f328c9384b211a@degeneration.co.uk"},"message":"core: Use values from plan only if object marked as planned\n\nThis inverts the previous logic so that it's the status of an object in\nthe state that decides whether we'll use its value from the plan. This\nfixes the problem that otherwise after we've actually applied the change\nthe partial planned object will continue to shadow the final object in\nstate.","distinct":false,"url":"https://api.github.com/repos/hashicorp/terraform/commits/1541ffe6834839148865f8306556890d1e6ddbdb"},{"sha":"5ff78107fe8cae9bb67da5081287d3fac328b2e7","author":{"name":"Martin Atkins","email":"a1bdfbfb01322b54f9edf8cea8f328c9384b211a@degeneration.co.uk"},"message":"core: TestContext2Apply_multiDepose_createBeforeDestroy incorrect logic\n\nThis test was re-using the same context to run three consecutive\nplan/apply operations, which is not safe because we will accumulate more\nplanned changes with each change, creating duplicate entries in the diff.\n\nInstead, to properly simulate a sequence of consecutive runs of Terraform\nwe must start with a fresh context each time, though still pass forward\nthe previous state which would in the real world be persisted via a state\nmanager between these runs.","distinct":true,"url":"https://api.github.com/repos/hashicorp/terraform/commits/5ff78107fe8cae9bb67da5081287d3fac328b2e7"},{"sha":"b71590d76c6fe9f93f59563db8e89a62cd1e1567","author":{"name":"Martin Atkins","email":"a1bdfbfb01322b54f9edf8cea8f328c9384b211a@degeneration.co.uk"},"message":"core: Be more explicit in how we handle create_before_destroy\n\nPreviously our handling of create_before_destroy -- and of deposed objects\nin particular -- was rather \"implicit\" and spread over various different\nsubsystems. We'd quietly just destroy every deposed object during a\ndestroy operation, without any user-visible plan to do so.\n\nHere we make things more explicit by tracking each deposed object\nindividually by its pseudorandomly-allocated key. There are two different\nmechanisms at play here, building on the same concepts:\n\n- During a replace operation with create_before_destroy, we *pre-allocate*\n  a DeposedKey to use for the prior object in the \"apply\" node and then\n  pass that exact id to the destroy node, ensuring that we only destroy\n  the single object we planned to destroy. In the happy path here the\n  user never actually sees the allocated deposed key because we use it and\n  then immediately destroy it within the same operation. However, that\n  destroy may fail, which brings us to the second mechanism:\n\n- If any deposed objects are already present in state during _plan_, we\n  insert a destroy change for them into the plan so that it's explicit to\n  the user that we are going to destroy these additional objects, and then\n  create an individual graph node for each one in DiffTransformer.\n\nThe main motivation here is to be more careful in how we handle these\ndestroys so that from a user's standpoint we never destroy something\nwithout the user knowing about it ahead of time.\n\nHowever, this new organization also hopefully makes the code itself a\nlittle easier to follow because the connection between the create and\ndestroy steps of a Replace is reprseented in a single place (in\nDiffTransformer) and deposed instances each have their own explicit graph\nnode rather than being secretly handled as part of the main instance-level\ngraph node.","distinct":true,"url":"https://api.github.com/repos/hashicorp/terraform/commits/b71590d76c6fe9f93f59563db8e89a62cd1e1567"}]}
{"actor":{"display_login":"apparentlymart"}}