* start using `go:generate packer-sdc struct-markdown`
* Update Makefile
remove @go install ./cmd/struct-markdown
* run go generate for struct-markdown
* use //go:generate packer-sdc mapstructure-to-hcl2
* run go generate for mapstructure-to-hcl2
* remove struct-markdown and mapstructure-to-hcl2
* vendor vendors
This adds the new `required_plugins` block to be nested under the packer block.
Example:
```hcl
packer {
required_plugins {
aws = {
version = ">= 2.7.0"
source = "azr/aws"
}
azure = ">= 2.7.0"
}
}
```
For example on darwin_amd64 Packer will install those under :
* "${PACKER_HOME_DIR}/plugin/github.com/azr/amazon/packer-plugin-amazon_2.7.0_x5.0_darwin_amd64"
* "${PACKER_HOME_DIR}/plugin/github.com/hashicorp/azure/packer-plugin-azure_2.7.0_x5.0_darwin_amd64_x5"
+ docs
+ tests
* move maps of plugins back in core
* go mod vendor
* more fixes
* fix imports
* Update core_test.go
* fix build
* more fixes
* more fixes
* up vendors after fixing sdk
* Update post_processor_mock.hcl2spec.go
* Leave implementatino of MapOf in the sdk for plugi tests
Other wise use the interface
* go mod tidy
* add MapOfDatasource type too
* Update docs on ebs encrypt_boot to clarify that packer will not override global account settings
* Update struct-markdown generator and regenerate partials with new website location. This overwrites some linting that got automatically applied when the files got moved
Modify makefile to call generate code properly, setting project root.
'make generate' now avoids deleting website code generated in the packer plugin sdk.
For now it will be maintainers' responsibility to regenerate this docs code from the
packer plugin sdk every release, and commit it to these folders manually.
remove boot command generator code
* add sshkey.Generate function that returns an sshkey.Pair to be used with openssh.
* add cmd/ssh-keygen/main.go for testing purposes
* add a test calling ssh.ParsePrivateKey & ssh.ParseAuthorizedKey (which is very
similar to what openssh would do to read a keypair)
The wrapping of the keys should be handled by crypto/x509.MarshalPKCS8PrivateKey
& x/crypto/ssh.NewPublicKey which does not work for ed25519 and dsa.
x509.MarshalPKCS8PrivateKey marshals ed25519 keys but the keys did not work with openssh.
x509.MarshalPKCS8PrivateKey does not handle dsa keys.
So I had to 'wrap' those manually by reading the code of the openssh package.
Note that ssh.NewPublicKey works with any keytype. I should probably do a PR to ssh to have a NewPrivateKey & Marshalling funcs
* Update and pin dependencies
* Update NextJS Scripts
* npm run lint
* npm run format
* docs generator: indent docs by two and make spacing better
Co-authored-by: Adrien Delorme <[email protected]>
Adrien Delorme
Sylvia MossandAdrien Delorme
Megan Marsh
Jonathan NealandAdrien Delorme