Backport of Datasource logic cleanup into release/1.9.x #12645
Merged
Conversation
This file contains 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
On HCP, multiproject support was GA'd recently, but Packer does not support the feature yet. To avoid clients being surprised if they encounter an error with this feature enabled, we add an advisory related to this feature not being supported for now, but planned for later.
With HCP supporting multi-projects now, Packer needs to take it into account when picking a project from an organisation. This commit adds two cases: 1. multiple projects are defined, none is supplied through HCP_PROJECT_ID: in this case we will default to the oldest project defined for the organisation. 2. we supply HCP_PROJECT_ID: in this case, we pick the project with the corresponding ID, and use it for publishing metadata.
* docs: add a paragraph on fingerprint generation Since version 1.9.0+ changed the way Packer generates fingerprints for HCP Packer, we add a small paragraph to explain how it used to be generated before, and how it changed in this version. * Apply suggestions from code review --------- Co-authored-by: Wilken Rivera <[email protected]>
Remove the check-legacy-links-format.yml workflow. These checks are now included as part of our content conformance checks that run on PRs with documentation content changes.
Packer will try to discover installed plugins in all of the directories defined by packer.KnowPluginFolders. In a previous release logic was added to scan nested directories in order to load plugins installed by `packer plugins install`. This change resulted in a nested directory scan for each folder within the KnownPluginFolders slice. This change reduces the nested directory scan to only the directories where plugins would have been installed using `packer plugins install`
* PACKER_PLUGIN_PATH takes precedence over all
#12476) * Update external plugin documentation source The Parallels plugin for Packer is now maintained by the Parallels team, under their respective GitHub org. This changes updates the source address for the external plugin that should be used for pulling new plugin documentation. * Removed packer-plugin-parallels for list of vendored plugins
Packer checks a number of directories for plugins upon initialization, with the introduction of multi-component plugins and underlying changes to the Packer SDK the ordering changed slightly. These changes update the related documentation to reflect the new ordering, and adds a plugin loading ordering section to the docs to help users discover how plugin loading works. Include in this change are updates to the PACKER_CONFIG_DIR environment variables to reflect the XDG base directory specification used as the default Packer configuration directory layout. * Update website/content/docs/configure.mdx
When the config file header was reworked, an erroneous link was included and placed so close to the header that it was rendered verbatim in the final documentation page. By adding an extra empty line in between the anchor link and the header, this renders correctly.
In HCL2, if a template contains a `required_plugins' block, but the required plugins are not installed, we print a warning. Prior to this commit, this was reported as an error once per missing plugin, which was redundant. This commit changes that by gathering all the missing plugins once, and printing them as a bullet list, so the message isn't redundant anymore.
Since the `discoverExternalComponents' function was defined but not called anywhere, it is dead code, and can be safely removed from the codebase.
Since bundled plugins will be removed in an upcoming version of Packer, this commit adds a new warning message whenever a template uses one such plugin. This warning has been implemented on build, validate, console and the inspect subcommands. In addition to warning about the upcoming change and potential issue this will cause, this warning message proposes solutions to the user so they know what they'll have to do in order not to rely on those bundled plugins later.
When a legacy JSON template references built-in plugins, we add them to the resulting template as a `required_plugins' block in HCL2.
The Makefile would check for executable files inside the Packer repository, and produce errors if one was detected and not explicitely whitelisted through the `EXECUTABLE_FILES' Makefile variable. This check was introduced a while back to avoid having executable files in the repository, but this check can be problematic sometimes because of how it is written, namely when building the website, which causes a lot of JS executable files to appear in the hierarchy, and in turn this causes the shell expansion to fail because of the large number of arguments. Since this test is not necessary for Packer to build or test, and since it implies that we have to maintain the whitelist regex, we remove it from the Makefile.
Co-authored-by: Lucas Bajolet <[email protected]>
Co-authored-by: hashicorp-tsccr[bot] <hashicorp-tsccr[bot]@users.noreply.github.com>
The flags -v and --version are handled by the CLI runner, which outputs the raw version string. This change shortcuts the handling of the flags to force Packer to run the version subcommand. Closes: #12565
Local variables can't have a validation block in their definition, so this step in not useful and should be removed. Besides, since the validation was done on the local variables before evaluation, it did nothing at all, as the PackerConfig.LocalVariables collection gets populated during evaluation, so this is essentially a no-op, and can be safely removed.
The active plugins that resided in a HashiCorp repository have been migrated to the integrations framework and no longer need to be listed within the plugins-manifest file.
Signed-off-by: guoguangwu <[email protected]>
Signed-off-by: guoguangwu <[email protected]>
When users call `packer init' on a template that does not specify a `required_plugin' block, the command succeeds but does nothing, which is not helpful for users that may expect their plugins to install. To remedy that problem, we now output a message like what `packer plugins required' does on templates without such a block, so that users have an idea of what to change in order to get the command to work.
This change updates the Ubuntu image being from 16.04 to something more recent.
Not sure why this was defined and returned, but the value was set, but never used, as such this is not useful to keep in the code, so let's simplify this now.
Since datasources are recursively evaluated depending on their dependencies, we don't need to pre-execute those that depend on nothing, as the recursive traversal of the datasources will take care of that for us.
When a datasource fails to be evaluated because a cycle has been detected, we point out one of the links of the chain now so that users have a better idea of what to look at.
Datasources use their attribute's expressions to determine whether or not they depend on another datasource, in order to get the list of dependencies and execute them before executing a datasource. This code may be useful later on for figuring out the dependencies for any block, so we move this code to the utils.go file, and use this for datasources.
hc-github-team-packer
requested review from
dekimsey and
jeanneryan
and removed request for
a team
hc-github-team-packer
force-pushed
the
backport/datasource_logic_cleanup/visually-master-asp
branch
from
b3c9d5e
to
3e144b8
Compare
lbajolet-hashicorp
deleted the
backport/datasource_logic_cleanup/visually-master-asp
branch
hc-github-team-packer
force-pushed
the
backport/datasource_logic_cleanup/visually-master-asp
branch
from
a29c83b
to
08af008
Compare
|
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Backport
This PR is auto-generated from #12608 to be assessed for backporting due to the inclusion of the label backport/1.9.x.
The below text is copied from the body of the original PR.
This PR is linked to #12607 as it is part of the ongoing refactoring efforts regarding the HCL parsing/execution logic.
This focuses on datasources, and simplifies the code a bit by not invoking the datasources that have no dependency prior to invoking the recursive execution function.
The code to extract the variables from the expressions in the block is moved away from the datasource evaluation as it will be reusable for other block types, but needs to be improved as it only works on the top-level block here, which makes dependency evaluation for datasources dependent on their presence as an attribute in a non-nested block.
Cycle detection now also returns the location of the conflict, this way it is easier for users to troubleshoot their configs if such a situation occurs.
Overview of commits