For launchpad, add apiversion middleware

[aodhom]

Follow on from https://github.com/Teamwork/launchpad/pull/231
@ready4god2513 as suggested moved the apiversion header to teamwork/middleware.

I'll update the other one if this is ok.

[codecov]

Codecov Report

Merging #7 into master will increase coverage by 45.63%.
The diff coverage is n/a.

@@             Coverage Diff             @@
##           master       #7       +/-   ##
===========================================
+ Coverage   32.66%   78.29%   +45.63%     
===========================================
  Files           9        4        -5     
  Lines         398      129      -269     
===========================================
- Hits          130      101       -29     
+ Misses        258       24      -234     
+ Partials       10        4        -6

Impacted Files	Coverage Δ
contenttypeMiddleware/contentType.go	93.33% <0%> (-0.79%)	⬇️
staticMiddleware/static.go
ratelimitMiddleware/ratelimiter.go
auditMiddleware/audit.go
corsMiddleware/cors.go
logMiddleware/reqlog.go
securityMiddleware/security.go
httperrMiddleware/error.go	87.23% <0%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6891cd4...2a49865. Read the comment docs.

[arp242]

It's really not a good idea to use viper in libraries; otherwise it is very difficult to see what gets referenced where in even fairly small apps. You should add options for it so it gets passed from the application (e.g. like here).

Would also be better to use http.Handler instead of http.HandlerFunc as argument & return value, as that can be used with echo.WrapMiddleware and some other tools (see same link for example).

And finally, it's a very good idea to add at least a basic tests for libraries like this; otherwise it's very difficult to work on, and very easy to make a simple mistake. I know this is very simple function, but still ... it would be especially useful for changing it later (otherwise you'd have to copy this code to an app first, and then copy it back, and then maybe fix and copy and copy and copy...).

Adding a test is very easy; here's an example..

[aodhom]

Thanks 👍 I'll get to it. As usual I wish I hadn't touched this issue at all now :P

[arp242]

haha, they're small things, and I don't necessarily mind looking at it myself :-)

[aodhom]

Ha nah I meant the end-to-end change in launchpad etc.
I'll have a crack sure good practice.

[ready4god2513]

@aodhom I can jump on this to close off this and https://github.com/Teamwork/launchpad/pull/231 for you today if you'd like

[flimzy]

BUILD_TARGET usually implies compile-time configuration. This is more runtime configuration.

RUNTIME_ENVIRONMENT might make the most sense, in terms of being technically correct. But it's also extra long.

In desk we use:

var version = "devel"

in main.go, then re-define that variable after building, before deployment. Which technically makes it a build-time configuration, but we're pretending it's run-time configuration.

I'm not saying this is ideal; just offering another data point.

[ready4god2513]

I think SERVER_ENV makes sense?

[arp242]

version in Desk is the git commit, that doesn't tell us if it's production, beta, etc. We use SENTRY_ENVIRONMENT for that (mostly for historic reasons).

Launchpad actually does the same.

[aodhom]

SERVER_ENV is good with me 👍

[ready4god2513]

Additionally, k8 exposes the server name, so once we are all on k8 we should use that as it not only tells the environment, but which instance.