* Adding "db-name" parameter, and renaming "database" to "db-type" (#65)
This is done in part to match Buffalo's parameter naming.
* Cache parameters (#67)
* Writing Template and parameters to disk
* Opportunistically skipping template cache
* allowing for skipping the deployment phase
* Automatically generate random dbAdmin password
* WIP populating from file
* More WIP
* Fixes#66
* Fixing CI reported issues
* Polishing defaults
* Fixing seg-fault
* Adding missing DB-Admin default setting
Adding site-name parameter
Adding deployment User Agent
Updating random name to not include uppercase letters
Reversing ownership of name between resource-group & site
* `builder` laid out to add file_contents.go entries
* Generating static templates.
* formatting
* Fixing linter errors.
* tinkering with CI impacts
* Formatting
* More CI tweaks
* adding builder test
* stashing changes
* Stashing progress using AST tools.
* Adding template of subscriber file
* Formatting.
* Adding more Mock HTTP implementation.
* Formatting
* Fixing broken closure, as caught by `go vet`.
* Adding "-race" flag to CI tests.
Now that eventgrid processes batches in parallel, it makes sense to
sanity check our implementation for race conditions.
* Fixing `golint` violations.
* Removing SubscriptionValidation default binding.
Before this change, `TypeDispatchSubscriber.Receive` would forward the `buffalo.Context`
directly. This gave the `ReceiveSubscriptionValidationRequest` function the ability to
respond to the request with some special sauce. Now that we discard anything written to
the context by wrapping it with our own type, that response will no longer get logged.
Inorder to fix this, I've removed the automatic binding of the
SubscriptionValidationResponse, and instead expose it as Middleware.
* Refactoring SubscriptionValidation into Middleware
* fixing up some comments
Because the time string is provided by the event publisher, we
can't have nice things. They can choose whatever format they want,
it may not even be valid.
Before this project was going to be a buffalo plugin, it was going to be
our own rapid-devlopment code generator. At that point, it made sense to
generate code in support of many different HTTP frameworks. That
doesn't make any sense anymore, so I'm removing the code artifacts that
suggest that strategy.