Put load_module directives before the stream block

[choroba]

Fixes #69.

[choroba]

This is just a wild guess. Feel free to correct me if it's wrong or too hacky.

[agentzh]

Maybe it's more readable to say $main_config = (join " ", @modules) . " " . $main_config?

[agentzh]

Better add a space between these two things to make the resulting nginx.conf look a bit better?

[agentzh]

Oh, never mind, a space is already used as a delimiter in the join() call :)

[thibaultcha]

This produces the following output:

load_module foo; load_module bar; stream {

    server {
        listen 1985;
        ...
    }
}

I would be in favor of having the following output, which makes debugging easier when inspecting the generated nginx.conf:

load_module foo;
load_module bar;
stream {

    server {
        listen 1985;
        ...
    }
}

This simple change is my suggestion:

Suggested change

	$main_config = join " ", @modules, $main_config;
	$main_config = join "\n", @modules, $main_config;

[agentzh]

@thibaultcha Will you have a look at this. If it looks good to you, then feel free to merge this :) Thanks!

[agentzh]

One concern is the 1 offset in the line numbers for the subsequent lines. This may break existing tests.

[thibaultcha]

@agentzh Tests usually refer to the Lua snippet within the *_by_block directive though, don't they? Are there other tests that rely on the nginx.conf line numbers themselves? This might be unlikely, otherwise the insertion of the env directives would constantly offset the generated config from different systems running them, wouldn't they?

[agentzh]

@thibaultcha Some tests may reference nginx.conf line numbers printed in the error log messages, like this:

runtime error: access_by_lua(nginx.conf:37):2: bad bad bad

[thibaultcha]

@agentzh Indeed, I have found the following cases of tests such as you described:

./stream-lua-nginx-module/t/132-lua-blocks.t:qr/\[emerg\] .*? Lua code block missing the closing long bracket "]]" in .*?\bnginx\.conf:22/
./stream-lua-nginx-module/t/132-lua-blocks.t:qr/\[emerg\] .*? Lua code block missing the closing long bracket "]==]" in .*?\nginx\.conf:22/
./stream-lua-nginx-module/t/132-lua-blocks.t:qr/\[emerg\] .*? Lua code block missing the closing long bracket "]]" in .*?\bnginx\.conf:22/
./stream-lua-nginx-module/t/132-lua-blocks.t:qr/\[emerg\] .*? Lua code block missing the closing long bracket "]=]" in .*?\bnginx\.conf:22/
./lua-nginx-module/t/158-global-var.t:rewrite_by_lua\(nginx\.conf:48\):3: in main chunk, \n\z/, "old foo: 1\n"]
./lua-nginx-module/t/158-global-var.t:access_by_lua\(nginx\.conf:48\):3: in main chunk, \n\z/, "old foo: 1\n"]
./lua-nginx-module/t/158-global-var.t:content_by_lua\(nginx\.conf:48\):3: in main chunk, \n\z/, "old foo: 1\n"]
./lua-nginx-module/t/158-global-var.t:log_by_lua\(nginx\.conf:50\):3: in main chunk\n\z/, "old foo: 1\n"]
./lua-nginx-module/t/158-global-var.t:content_by_lua\(nginx\.conf:56\):4: in\n\z/, "old foo: 1\n"]
./lua-nginx-module/t/132-lua-blocks.t:qr/\[emerg\] .*? Lua code block missing the closing long bracket "]]" in .*?\bnginx\.conf:41/
./lua-nginx-module/t/132-lua-blocks.t:qr/\[emerg\] .*? Lua code block missing the closing long bracket "]==]" in .*?\bnginx\.conf:41/
./lua-nginx-module/t/132-lua-blocks.t:qr/\[emerg\] .*? Lua code block missing the closing long bracket "]]" in .*?\bnginx\.conf:41/
./lua-nginx-module/t/132-lua-blocks.t:qr/\[emerg\] .*? Lua code block missing the closing long bracket "]=]" in .*?\bnginx\.conf:41/
./lua-nginx-module/t/142-ssl-session-store.t:qr/\[emerg\] .*? "ssl_session_store_by_lua_block" directive is not allowed here .*?\bnginx\.conf:28/

If you don't mind, I would like to update them to use nginx\.conf:\d+ instead, since imho, relying on the nginx.conf line number is unsafe and should be subject to changes (what if we'd like to introduce a new directive, such as a new env variable in the future?). Third-party test suites (external to the OpenResty organization) should probably not assume that the internal nginx.conf is not subject to changes either...

Once updated, we can safely apply my suggestion and merge this. What do you think?

[agentzh]

@thibaultcha Actually some tests really want to check the nginx.conf line numbers. That's part of the things we want to check accurately.

[spacewander]

I think it is fine since we don't use load_module in our tests.