Migrated Docker based integration tests to TestContainers #494
Conversation
|
I use TextContainers elsewhere, works like champ! |
| public static int HTTP_PORT = 80; | ||
|
|
||
| public static GenericContainer<?> httpBin() { | ||
| return new GenericContainer<>(DockerImageName.parse("kennethreitz/httpbin:latest")) |
There was a problem hiding this comment.
I don't know what the philosophy is in this project but as a rule of thumb I would avoid using latest - an upstream change could occur and break the build here with no code changes having occurred in this repo. Wouldn't it be better to use a specific version of this container instead?
There was a problem hiding this comment.
@massdosage The intention is to test our latest code with the latest images of stable branches. I suppose httpd:2.4 and nginx:1.22 represent exactly that. HttpBin is a bit of a special beast as it changes very infrequently if ever and when it does I actually would like to know about it immediately. What versions would you see as more reasonable?
There was a problem hiding this comment.
I agree with @ok2c . While we're not focused on validating upstream changes, using latest for HttpBin makes sense due to its stability and infrequent updates.
There was a problem hiding this comment.
OK, if if it's stable and updated infrequently then I suppose this is fine. I've just been bitten many times when a build starts failing with no code changes in the repo due to a "latest" version changing in a backwards-incompatible way. This will never happen if you lock to a specific version. Sounds like this is a calculated risk that you're willing to take and maybe it's even intentional to test against the latest upstream versions and you'd like to know if this breaks the code here in any way.
There was a problem hiding this comment.
There are also security implications of this, you're basically trusting all future versions of the upstream project. I work for a cybersecurity company so maybe I'm just being paranoid but having an opening like this in the "supply chain" for a project is also risky for other reasons.
There was a problem hiding this comment.
@massdosage The image is question is just a locally deployed version of http://httpbin.org/. What image version would you suggest? I will happily follow your recommendation.
There was a problem hiding this comment.
I would go with whatever the most recent fixed version is at this point in time, however now that I look into it, this kennethreitz container doesn't have any fixed versions, only latest and test (https://hub.docker.com/r/kennethreitz/httpbin/tags) :( So you don't have any other options for this specific container. The version provided by kong does have proper versions (https://hub.docker.com/r/kong/httpbin/tags) with 0.2.0 being the most recent but that's from a fork of httpbin which does look like it's being more actively maintained.
There was a problem hiding this comment.
@massdosage I think it used latest in the first because there was no better option.
There was a problem hiding this comment.
Fair enough, doesn't look there are any better options here, so latest it is!
|
If there are no further comments I will merge this PR as there is a few others that depend on it. |
TextContainers for sure... :-D |
@arturobernalg All right. I added an explicit |
Folks
I just recently discovered TestContainers and it this framework is an absolute marvel!
I took it as an opportunity to revise and improve our existing Docker based integration tests and now I am very happy that they will be automatically executed with each build in those environments that have Docker support enabled.
We should now be able to build more integration tests with an relative ease.
I also discovered in the process that there is now incompatibility with Apache HTTPD HTTP2 push support, which we need to address. You may notice that one of the Apache HTTPD test cases is disabled. It, however, works fine with Nginx.
@arturobernalg Please review