catch up#1
Merged
Merged
Conversation
We can't fully detect why a module source or version might be unknown, so instead use a simpler error that covers all possible reasons. If we do find a way to get more specific in the future, we can extent it then, but the current errors were trying to be specific when they couldn't.
We can't detect why a provider function is missing is all cases, so get rid of the extra logic trying to do that. We also admit here that we need to allow a provider function within a variable validation condition, because that is not the only way these could fail during init, and it's otherwise valid during the next phase.
…ring-init Fixed various "unknown provider function" errors that occur during init
…r download in `init` (#38502) * test: Add pre-release to available providers. Existing tests don't use it because the configuration doesn't specify the prerelease as the version constraint. This was the gap in my understanding - prerelease providers are handled differently in the installer logic. I believe it boils down to this: https://github.com/apparentlymart/go-versions/blob/29863fd2ba61c1fbf5b5529907e1463dd4e197de/versions/set_released.go#L5-L7 * test: Add failing tests that show expected behaviour when a pre-release of a provider is used * fix: Ensure that any relevant version constraints from the config are available to use when installing providers present in the state * test: Add test defining pre-release download behaviour that was present before v1.15 * test: Update test to reflect that 2 step init is no longer experimental or specific to the PSS project
…rmat when the -json flag is present (#38469)
…arguments package for parsing arguments and flags (#38430) * refactor: Move method `ValidWorkspaceName` and related const into arguments package, update references This function is primarily used to validate arguments, but it's used once (in (m *Meta) Workspace) in a different context, so I've left the original function signature in the command package. * feat: Add `workspace new`-related code to arguments package * refactor: Update `workspace new` to use the arguments package when parsing arguments Note that this changes the format of errors returned when arg parsing fails - this is now wrapped in a diagnostic so now starts with `\nError: ` and has an extra trailing newline. * feat: Add `workspace select`-related code to arguments package * refactor: Update `workspace select` to use the arguments package when parsing arguments Note that this changes the format of errors returned when arg parsing fails - this is now wrapped in a diagnostic so now starts with `\nError: ` and has an extra trailing newline.
… updates (#38505) Bumps the github-actions-backward-compatible group with 2 updates: [actions/upload-artifact](https://github.com/actions/upload-artifact) and [actions/cache](https://github.com/actions/cache). Updates `actions/upload-artifact` from 7.0.0 to 7.0.1 - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](actions/upload-artifact@bbbca2d...043fb46) Updates `actions/cache` from 5.0.4 to 5.0.5 - [Release notes](https://github.com/actions/cache/releases) - [Changelog](https://github.com/actions/cache/blob/main/RELEASES.md) - [Commits](actions/cache@6682284...27d5ce7) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-version: 7.0.1 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: github-actions-backward-compatible - dependency-name: actions/cache dependency-version: 5.0.5 dependency-type: direct:production update-type: version-update:semver-patch dependency-group: github-actions-backward-compatible ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
…y with 2 updates (#38504) Bumps the github-actions-breaking group with 2 updates in the / directory: [actions/github-script](https://github.com/actions/github-script) and [miniscruff/changie-action](https://github.com/miniscruff/changie-action). Updates `actions/github-script` from 8.0.0 to 9.0.0 - [Release notes](https://github.com/actions/github-script/releases) - [Commits](actions/github-script@ed59741...3a2844b) Updates `miniscruff/changie-action` from 2.1.0 to 3.0.0 - [Release notes](https://github.com/miniscruff/changie-action/releases) - [Changelog](https://github.com/miniscruff/changie-action/blob/main/CHANGELOG.md) - [Commits](miniscruff/changie-action@5036dff...11bcad3) --- updated-dependencies: - dependency-name: actions/github-script dependency-version: 9.0.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions-breaking - dependency-name: miniscruff/changie-action dependency-version: 3.0.0 dependency-type: direct:production update-type: version-update:semver-major dependency-group: github-actions-breaking ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
* command/output: Ignore warnings in JSON mode * add changelog entry
…nstances in deeply nested modules (#38528) * stackmigrate: fix recursive provider config resolution for resource instances in deeply nested modules * added additional test for implict provider configs in deeply nested modules * add changelog * move changelog to 1.15
Co-authored-by: Jared Baker <jar-b@users.noreply.github.com>
…n initialising a state store for the first time (#38395) * refactor: Replace use of prepareInstallerEvents method. This will allow finer control of callbacks when implementing security related features * feat: Users are prompted to approve a provider used for PSS on first use, and only if downloaded via HTTP. Prompts include signer details and key ID data. * test: Users see "Authentication: unauthenticated" in prompt if network mirror doesn't include hashes They'll see authentication data in all other prompt scenarios. There's no auth when using an fs mirror, but when those are in use we trust the providers already and no prompts are raised. * refactor: Simplify how we prepare installation event callbacks by defining reused callbacks * refactor: Remove unused parameters from `getProvidersFromState`
…is configured. (#38772) Added tests showing that init detects changes in how PSS is used and raises errors referring users to the new `state migrate` command. This includes detection of provider version changes, which can only happen if changes happen out of band but we still need to protect against it.
…utate the state are complete (#38775)
…related to watchStop (#38747)
Co-authored-by: hc-github-team-tf-core <github-team-tf-core@hashicorp.com>
… into new readLockedDependenciesFromPath method. The reusable logic includes managing locks annotation, which could be missed if a command implementation used `depsfile.LoadLocksFromFile` directly. Also, refactor to remove an instance of constant string for `".terraform.lock.hcl"`. Instead reference a const from `depsfile` instead, which should be the authoritative place this filename comes from.
…ing the dependency lock file post-migration. This change updates `state migrate` to be able to download providers and, depending on the situation, update the dependency lock file. If a state migration involves 1 or more state stores then the provider implementing those stores may need to be downloaded. There are situations where 0, 1, or 2 providers may need to be downloaded: - 0 : The 1 or 2 providers used for source and destination state stores are in the dep lock file already. - 1 : Either the provider used for both source and destination isn't downloaded (or there's no dep lock file), or one of the source or destination providers isn't present. - 2 : Neither of the source and destination state stores' providers are present in the dependency lock file. The provider used for the destination state store **must** be in the dep lock file after a successful migration. If the migration fails then the lock file will be untouched, but if it succeeds then the destination provider will either be added to or upgraded in the dependency lock file. Note: upgrade is not yet implemented, and will be a separate PR. The process of updating the dependency lock file will never remove a provider. If the provider used for the source state store is present in the lock file but isn't present in the configuration (i.e. it was removed from required_providers when the config was changed to describe the new location for storing state) then its removal from the lock file will happen in a subsequent init command. This is because the `state migrate` command does not load the full configuration, only the root module, so it doesn't know about the configuration's full provider requirements. And that's not considering the state's provider requirements. Basically, `state migrate` does not manage the complete dependency lock file, but instead manages a single entry inside it.
…ck file and is used in both the source and destination
…rent providers This includes scenarios where different providers are already in the lock file or not. Regardless of the starting conditions the command will download and use the necessary providers. The lock file will have the destination provider added or updated, but otherwise the file will be unchanged.
The `DIR` positional arguments have all been removed from the codebase in favour of the -chdir flag. Anyone attempting to use `DIR` will get an error reporting an unexpected positional argument and guidance to use -chdir instead.
Co-authored-by: hc-github-team-tf-core <github-team-tf-core@hashicorp.com>
Update go-cty@v1.18.1
…sources and data sources (#38781) * Update the policy callback for `getresources` to return a partial response if any matching resource types are deferred * Update `getdatasource` callback to returned deferred indicator from the `ReadDataSource` call to the provider. * remove provider meta from `ReadDataSource` call in policy callback server
This change adds provider policy evaluation to the stacks runtime, which is evaluated immediately following a provider being configured (equivalent to when the module runtime evaluates provider policy). Additional test cases have been added for embedded stacks, which can also configure providers.
…m Policy is mutually exclusive with the PSS feature.
… first use of policy feature happens.
…38797) This change removes the restrictions in PlanStackChanges and ApplyStackChanges preventing policy evaluation during refresh and destroy (which originally was omitting the policy client). Now, when a policy client is given to stacks, it will always be passed to the module runtime + used to evaluate provider policy if configured.
…od, for transparency. This change pulls a lot of lock merging events out of methods and into the init command's Run method. Previously the `getProviders` and `saveDependencyLockFile` methods performed some lock merging internally, but this should be the concern of the init command and not these methods. This makes it easier to reason about what happens in init when reading through the command (well, at least it's flatter/more transparent when reading though). This change highlights that the init command only blocks the upgrade of the provider used for PSS through the final merging of locks before `saveDependencyLockFile` is invoked. The merge ensures that the provider version used for initialising the state store enters the lockfile instead of the lock for that provider returned from `getProviders`, which may have upgraded that provider.
…s returned from `getProvidersFromPSSConfig`
…hing provider versions.
Change `pssLocks` => `pssLock` to indicate only one lock is ever present if `getProvidersFromPSSConfig` is invoked. Change `reqs` to `req` in `getProvidersFromPSSConfig`, to support the fact only one requirement is passed to the installer logic later in the method. Change `configLocks` => `lock`, to show that a single lock it returned. Also, the old name configLocks is a hangover from when we had split download of providers in the config and the state.
…e a sufficient lock file.
…r positional arguments (#38799) main.go has an if block with the expression `arg == "-v" || arg == "-version" || arg == "--version"`. This change updates a test to assert all 3 are accepted. The new test defining how the command handles unexpected flags and positional arguments are intended to help with future refactoring, e.g. to make the command use the arguments and views packages in future.
…r provider versions are available, if the -upgrade flag is set to false. This scenario is implicitly tested elsewhere, but this test makes it explicit.
Co-authored-by: Radek Simko <radeksimko@users.noreply.github.com>
Co-authored-by: hc-github-team-tf-core <github-team-tf-core@hashicorp.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
15 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
whoa