* outsourced linting tests into its own file
* trigger rebuild
* added SCRIPT variable to setup.sh
* trigger rebuild again
* major test rewrite
* outsourced `hadolint` too
* rewrote some parts of the linting logic due to a logic bug
* adjusted TravisCI
* corrected .bats test line
* corrected logging in linting tests
* updated `hadolint`
* added option to use non-default network-interface (#1227)
* minor (stylistic) changes
* properly working with Bash arrays for CONTAINER_NETWORKS
* cleanup to trigger rebuild
* added CODE_OF_CONDUCT to trigger rebuild
- outsourced badges-links in `README.md` to clean this section up
- refactored `.travis.yml` with Prettier and added **shellcheck capabilities**
- refactored Makefile to make it verbose where it should be and added a **shellcheck target**
- refactored all scripts in `target/` (except `start-mailserver.sh`)
- added **coding style guidelines** to `CONTRIBUTING.md` so everyone can and must adhere to consistent guidelines
- `start-mailserver.sh` had to be touched due to renaming of functions
- added a table of contents to Markdown documents
* major refactoring for setup.sh (#1590)
* `set -u` stopped dkim generation from defaulting
* changed to bash and implemented simple error logging
* fixed $VOLUME not being set and refactored README as well due to markdownlint showing (valid) complaints
* setup.sh more consistent with braces, return codes, un-setting of variables and error reports and (importantly) test
Previously, only postfix-relaymap.cf and postfix-accounts.cf would be
used to populate the relayhost_map file.
Now, also use postfix-virtual.cf when present. To me, there is nothing
absurd about sending mail "From:" a virtual account (or more
specifically its domain) so it makes sense that when a $RELAY_HOST is
defined it should be used for virtual accounts as well.
check-for-changes.sh did not have a special case to handle lines in
postfix-relaymap.cf consisting of only a domain (indicating that said
domain should never be relayed). This case is handled by
start-mailserver.sh so when such a line existed, things would work well
until a config file update was detected by check-for-changes.sh. After
that, the generated relayhost_map file would be corrupted.
Fixed by factoring a 'populate_relayhost_map' function out of
start-mailserver.sh and into helper_functions.sh and reusing it in
check-for-changes.sh.
Note: There are certainly quite a few more pieces of code that could be
refactored in a similar fashion.
Note2: check-for-changes.sh would previously never update the
relayhost_map file when $ENABLE_LDAP was set to 1. I don't think this
was intended —there is after all no such condition in
start-mailserver.sh— and so this condition no longer applies.
If a change to one of the tracked files happened soon after (<1 second?)
a previously detected change, it could end up going undetected. In
particular, this could cause integration tests to fail (see next
commits).
Fixed by computing the new checksum file _before_ checking for changes.
