hotfix(config) parse headers config option from .kong_env

[hbagdi]

This fixes a bug introduced in 976dd87 (#3300)
where headers config option was being overwritten
as a table. The table is not persisted in the intermediate
config file and hence the config option does not take effect.

This commit also exposes get_running_conf helper function to
read conf from prefix directory in use during the current test.

[hbagdi]

@thibaultcha I missed the serialization part in the previous commit and this fix would take care of it. The approach is similar to what we do with admin_listen and proxy_listen options.

If this looks approach looks good to you, then I'll add test for the generated .kong_env file. I couldn't find any integration test for this file, so I'm assuming that it will be additional work. Let me know if that's not the case. Thanks!

[thibaultcha]

@hbagdi SGTM

[thibaultcha]

This can be made a lot more concise, in the spirit of writing referential code :)

conf.enabled_headers = setmetatable(enabled_headers, {
  __tostring = function() return "" end,
})

[hbagdi]

@thibaultcha I've updated the PR with a regression test.

[thibaultcha]

Note: when providing a fix to a behaviour that was not yet shipped in a release, our style guide instructs us to use the hotfix() scope (instead of fix()).

[thibaultcha]

imho, those tests are too implementation-specific - only the unit tests and a couple of integration tests are aware of the .kong_env file.

Instead, it might be better to write an integration test here, which will both be more resilient to implementation changes, and explicitly states the issue (which is nice for the future selves who will browse this test suite and modify this trying not to break it).

Such a test could be written if we load the headers value from a configuration file (instead of environment variables). We also try to keep track of regression test with a comment explaining their existence, which will make this test's importance clearer to the reader:

      it("can also be configured via configuration file", function()
        -- a regression test added with https://github.com/Kong/kong/pull/3419
        -- to ensure that the `headers` configuration value can be specified
        -- via config file as well as via environment variables (all
        -- other tests in this file only test the latter).
      end)

You may create a new configuration file under spec/fixtures/headers.conf which contains something like:

headers = server_tokens

And start Kong with:

          assert(helpers.kong_exec("restart -c spec/fixtures/headers.conf", {
            database = strategy,
            proxy_listen = "0.0.0.0:9000, 0.0.0.0:9443 ssl", -- a bit ugly but already done in `core_entities_invalidations_spec.lua`
          }))

Another pattern could be to duplicate spec/kong_tests.conf and append a headers = directive.

This approach also has the benefit of not needed to expose get_running_conf(). I am also sceptical on testing the same thing 3 times, since a breaking change in the code will trigger 3 test failures instead of a clearly defined and documented one. This philosophy behind our tests are made our lives easier at times (and harder when it wasn't followed we well...).

[thibaultcha]

Merged, thanks!