Add multiple extra config option

[slamont]

Add bash traceback if an error occured

Also fix some unbound variables

[kylemanna]

Looks good and tests pass. I like the use of mktemp and cleaning up on the error and exit signals. Also didn't know about bash tracebacks until, now. 😎

Have one request: could you write a simple unit test to ensure that the fragments are appended to the openvpn config file? Would be nice to verify that the mktemp files are clean-up too, but kind of hard to test from the outside.

With the config unit test this looks good to merge.

[kylemanna]

Have one request: could you write a simple unit test to ensure that the fragments are appended to the openvpn config file? Would be nice to verify that the mktemp files are clean-up too, but kind of hard to test from the outside.

[slamont]

I'll try to figure out how to do that and update the PR

[kylemanna]

Take a look at the conf_options test. I'd guess it's a matter of making some config files and grepping them for expected contents.

Could either append that test or add another one using conf_options for reference.

You can run the test locally with test/run.sh "$image" where image is the name of your local docker build -t $image.

[slamont]

I figured out how to add the tests following your instructions. I've added 2 more extra config and validated that they got appended to the config.

I wanted to see if there could be a better way to do those tests, as there is a lot of similar lines. I was wondering if Bats (https://github.com/sstephenson/bats) could be a good replacement or if generating a function that use bash arrays or something could help.

I did not push this idea further though as I don't want to disrupt this too much :)

[kylemanna]

Thanks for updating this. The new test looks good. My main motivation for unit tests is to make sure that other's contributions don't break as has happened in the past and in some extreme cases never worked to begin with. By this measure, we're doing better then the majority of software projects.

As far as what it could be, you're right. The current unit test "framework" is hijacked from the upstream docker people as they use it at a massive scale. However, it seems to be quite limiting and repetitive.

For now, I think this is good. When something easy to maintain comes along we'll move along to that.