Codecov Report

Merging #329 (cc50af7) into main (6ede1a8) will increase coverage by 0.14%.
The diff coverage is 4.76%.

@@            Coverage Diff             @@
##             main     #329      +/-   ##
==========================================
+ Coverage   52.58%   52.72%   +0.14%     
==========================================
  Files          60       60              
  Lines        4874     4874              
==========================================
+ Hits         2563     2570       +7     
+ Misses       2013     2002      -11     
- Partials      298      302       +4     

Flags with carried forward coverage won't be shown. Click here to find out more.

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 6ede1a8...cc50af7. Read the comment docs.

The access to the version of kong shall be moved to the go-kong but there is a need for the client to be aware of the use of a workspace. There could also be a service to expose every versioned capabilities of kong like tags for credentials in deck or mtls authentication in kubernetes ingress controller. This way the semver dependency would only be required in go-kong

Unfortunately we don't have automated regression tests capturing that, but we need to ensure that we haven't broken anything in those scenarios before merging.

@mflendrich Did you mean to imply that we should add that in here before merging in?
I think adding integration tests like these requires more thought and should probably be out of scope from this PR.

Following my suggestion from last week I created a PR on go-kong. So that the kongVersion() is hold by the client. The version is a string and has the format of the versions of the kic so it has more informations than what deck is actually showing. Also the test on the version to know if it's greater than 1.4.0 is in the response so deck don't need to do it and so don't need to have semver as a direct dependency.

It doesn't mean that this pr shouln'd be merged but if the go-Kong's one is accepted then a part of this will be replaced in the next version of go-kong.

@mmorel-35, with the Kong/go-kong#65 PR moving the API machinery into go-kong, which parts of this PR are still relevant? Should we close it and follow up on Kong/go-kong#65 by using that API when that PR gets merged in?

On integration testing: we're tracking the direction for integration testing in deck in #63. I'll post this PR there as prior work, but I don't think we're ready to merge the test yet.

That being said, I think the best way forward would be to close this PR and follow up with:

• (when the go-kong PR with the information service gets merged and released) using the go-kong information service for version retrieval
• (when we make up our mind about integration testing) implement the integration test using this PR as reference

I agree, this PR can be closed ! I don't think there is much left to keep with what's coming in go-kong.