Add possibility to configure own path to "/api-docs/swagger.json" - #207
Add possibility to configure own path to "/api-docs/swagger.json"#207vkatsuba wants to merge 16 commits into
Conversation
|
Hey @elbrujohalcon, @paulo-ferraz-oliveira! Please, review this PR when you will has a time for it. The CI was passed except OTP 24 - it looks like some plugin require OTP 25 minimum versions, but this is another issue which was opened for this project. In any case, I will going back to end to end testing after some time, if you will keep in mind better approaches or have any opinions - please, share 😃 |
| strategy: | ||
| matrix: | ||
| otp_vsn: ['24', '25', '26'] | ||
| otp_vsn: ['25', '26'] |
There was a problem hiding this comment.
btw - it strange that in CI we got this issue... locally I use OTP 24 and it builded as well for me...
There was a problem hiding this comment.
You probably had a cached version of the library.
There was a problem hiding this comment.
Nope. Not that.
Because the libs all have version numbers…
Lines 24 to 29 in 24334d8
No idea what's going on.
There was a problem hiding this comment.
Try running rebar3 upgrade --all. Let's see what it tells you.
There was a problem hiding this comment.
CI updates as well https://github.com/vkatsuba/cowboy_swagger/actions/runs/11253721613
The rebar3 upgrade show all green
There was a problem hiding this comment.
Well... rebar3 test show me that error locally.
===> Performing cover analysis...
|-----------------------------------|------------|
| module | coverage |
|-----------------------------------|------------|
| cowboy_swagger | 83% |
| cowboy_swagger_handler | 73% |
| cowboy_swagger_json_handler | 100% |
| cowboy_swagger_redirect_handler | 100% |
|-----------------------------------|------------|
| total | 83% |
|-----------------------------------|------------|
coverage calculated from:
/home/vk/work/OpenSource/git-repo/cowboy_swagger/_build/test/cover/ct.coverdata
cover summary written to: /home/vk/work/OpenSource/git-repo/cowboy_swagger/_build/test/cover/index.html
===> Comparing 83 to pass rate 0
===> Expanded command sequence to be run: [app_discovery,install_deps,lock,ex_doc]
===> Running provider: app_discovery
===> Found top-level apps: [cowboy_swagger]
using config: [{src_dirs,["src"]},{lib_dirs,["apps/*","lib/*","."]}]
===> 24.3.3 satisfies the requirement for minimum OTP version 23
===> Running provider: install_deps
===> Verifying dependencies...
===> Linking _build/default/lib/cowboy to _build/docs/lib/cowboy
===> Linking _build/default/lib/jsx to _build/docs/lib/jsx
===> Linking _build/default/lib/ranch to _build/docs/lib/ranch
===> Linking _build/default/lib/trails to _build/docs/lib/trails
===> 24.3.3 satisfies the requirement for minimum OTP version 23
===> Linking _build/default/lib/cowlib to _build/docs/lib/cowlib
===> Running provider: lock
===> Running provider: ex_doc
===> You are using Erlang/OTP '24', but this plugin requires at least Erlang/OTP 25.It looks like the warning related more to https://github.com/elixir-lang/ex_doc/blob/main/CHANGELOG.md... Elixir project 🤢
| @@ -0,0 +1,24 @@ | |||
| %% Reading the contents of the file | |||
| case file:read_file("priv/swagger/swagger-initializer.js") of | |||
There was a problem hiding this comment.
I'm hesitant about implementing this as a rebar.config.script. To me it should be a pre-compile hook.
I wonder if I run rebar3 test on this project… and it changes the swagger-initializer.js… wouldn't it be included in the subsequent commit and thus pushed to Github without the placeholder?
How do we avoid that?
There was a problem hiding this comment.
I was add to gitginore this file.. hope it will fix issue
There was a problem hiding this comment.
Not a good idea… we do want that file downloaded when people clones the repo.
There was a problem hiding this comment.
NO NO, this file is added as well and it is a part of repo. But the changes in this file should be ignored - something like that.
There was a problem hiding this comment.
What if we need to make changes to this file (like the automatic updater does)?
In that case, it will need to git add -f priv/swagger/swagger-initializer.js.
I don't think that's a good idea.
But then again, I don't know how to avoid changing the file in development mode (i.e. when working on this app) but do change it when this project is a dependency of another… 🤔
A pre-compile hook will work for making the change, but it will need to be aware of the environment. I'm not sure if that's possible with rebar3. Maybe rebar3 has an environment variable, like REBAR3_PROJECT and the script can check if it's cowboy_swagger or not… or it check if its current path includes _build (in which case, it can assume it's on another project)… 🤔
There was a problem hiding this comment.
Well... I have idea but not sure... if this will looks ok. So, we can use swagger-initializer.template in repo and ignore swagger-initializer.js - during run project it will be translated from template to js and just copy all data inputs from this file before make changes.
There was a problem hiding this comment.
Yeah… that's not a bad idea. What do you think, @paulo-ferraz-oliveira ?
There was a problem hiding this comment.
We'll need to adjust the github action to write swagger-initializer.template based on the swagger-initializer.js file that it downloads from the swagger repo.
There was a problem hiding this comment.
I'm Ok with the current implementation, but maybe if I have time, just before we decide to merge I'd like to test it out locally. I don't see documentation updated or have a really easy to understand example of how the new changes would be used.
|
Furthermore, @vkatsuba why don't we make the whole url configurable, instead of just the base path?
|
Yes, the initial approach was intended for the pre-hook, but for some reason, I wasn't able to implement it. I haven’t worked with pre-hooks before, so I might have taken the wrong approach. Let me check it again and see if I can fix it. |
Well.... I suppose for this case we need use something like |
|
My idea was to use something like…
{pre_hooks, [{compile, "priv/update-swagger-url"}]}.
Then, write a bash script or an escript (at priv/update-swagger-url) that
would basically do what you did on the rebar.config.script.
…On Wed, 9 Oct 2024 at 13:41, Viacheslav Katsuba ***@***.***> wrote:
As I said in the inline comment: I don't think this should be a
rebar.config.script. I think it will be better off as a rebar3
pre-compile hook.
Yes, the initial approach was intended for the pre-hook, but for some
reason, I wasn't able to implement it. I haven’t worked with pre-hooks
before, so I might have taken the wrong approach. Let me check it again and
see if I can fix it.
So, @elbrujohalcon <https://github.com/elbrujohalcon> I do not work with
hooks before and ... when I check documentation the hooks mostly used for
bash or C and I do not has any good example how hook can be added - do you
has any ideas?
—
Reply to this email directly, view it on GitHub
<#207 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAW3WMUFB6PY2MJR5LAPCTZ2UJAJAVCNFSM6AAAAABPT42LX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBSGA4DMOBXHE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
<https://about.me/elbrujohalcon?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api&utm_content=thumb>
Brujo Benavides
about.me/elbrujohalcon
<https://about.me/elbrujohalcon?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api&utm_content=thumb>
|
Oh... wow... I was use more ugly approach 😄 {pre_hooks, [
{compile, "erlc src/cowboy_swagger_hook.erl"},
{compile, "erl -eval 'cowboy_swagger_hook:init()' -s init stop"}
]}. |
|
@elbrujohalcon, @paulo-ferraz-oliveira for now we use escript for create |
| SwaggerPath = application:get_env(cowboy_swagger, path, "/api-docs"), | ||
| {{true, SwaggerPath ++ "/index.html"}, Req, State}. |
There was a problem hiding this comment.
Ooooooh! So this is alredy generating issues in our production systems… nobody relized that because everybody just clicked a link that arleady contained the index.html part… HA! 🤦🏻
Now I see why you wanted to use path instead of the full url.
I don't think those 2 things should be necessarily related, @vkatsuba …
I would allow the user to configure the swagger base path (which I would call base_path or root_path, instead of path) on a parameter, and the swagger.json location (which I would call swagger_json_url or swagger_url) with another parameter.
There was a problem hiding this comment.
Yes... make sense... So, now I suppose the code should be prepared as well for use at least path config. The application:get_env/3 should be able to get config from top project where it used. Still need to do end to end tests but we mostly there... So, we can prepare different variables now for use them in URL.
There was a problem hiding this comment.
Ooooh… right… that's an issue. Have you tested your changes on another project using this one as a dependency?
I'm pretty sure it won't work as we expect… because the configuration for the cowboy_swagger app can be in whatever path… and thus it may not be visible to your new script.
There was a problem hiding this comment.
I'll write an inline comment in the proper place…
There was a problem hiding this comment.
Yes... end to end testing will be need to do...
| case file:read_file(TemplateFilePath) of | ||
| {ok, Content} -> | ||
| %% Get the configuration for the path from the application environment | ||
| Path = application:get_env(cowboy_swagger, path, "/api-docs"), |
There was a problem hiding this comment.
This won't work. This script will run at compile-time in an erlang VM where cowboy_swagger is not yet compiled, and thus… not yet loaded. Therefore, no matter what the users of this library put on path in their sys.config files, it will be invisible to this script and therefore we'll end up with "/api-docs" everywhere. We need a different approach, one that acts at runtime instead of compile-time.
|
@vkatsuba we need a very very different approach for this (as I mentioned in my inline comment). We need to…
|
|
But @vkatsuba… please check |
But the points 1 and 2 already done? |
| rebar3_vsn: ['3.22'] | ||
| steps: | ||
| - uses: actions/checkout@v3 | ||
| - uses: actions/checkout@v4 |
There was a problem hiding this comment.
nit: This is Ok but shouldn't be required for this PR in particular, right?
| FIND="\"https://petstore.swagger.io/v2/swagger.json\"" | ||
| REPLACE="window.location.origin + \"/api-docs/swagger.json\"" | ||
| sed -i -e "s|${FIND}|${REPLACE}|g" priv/swagger/swagger-initializer.js | ||
| REPLACE="window.location.origin + __SWAGGER_PATH__ + \'/swagger.json\'" |
There was a problem hiding this comment.
nit: Are the \" a problem here, that they had to be replaced with \'. If not, the change could be reverted?
| // the following lines will be replaced by docker/configurator, when it runs in a docker-container | ||
| window.ui = SwaggerUIBundle({ | ||
| url: window.location.origin + "/api-docs/swagger.json", | ||
| url: window.location.origin + __SWAGGER_PATH__ + '/swagger.json', |
There was a problem hiding this comment.
nit: Same comment as before, for the ". Was it required to be changed?
| %% `path`: Path where you can access Swagger-UI. Default: `/api-docs` | ||
| {path, "/api-docs-swagger"}, |
There was a problem hiding this comment.
It says the default is /api-docs but we seem to be changing that. Do we need to change the default? I'm missing something, as I don't understand this particular change.
| basePath => "/api-docs" | ||
| %% See "path" config section | ||
| basePath => "/api-docs-swagger" |
There was a problem hiding this comment.
Same here, I don't see why the base path (which is api-docs for all the projects I use this with) would be different from what it was. Can we restore it?
| @@ -0,0 +1,40 @@ | |||
| #!/usr/bin/env escript | |||
| -module('update-swagger-url'). | |||
There was a problem hiding this comment.
nit: I don't know about good practices for naming escripts, but I usually do it by replacing .erl with .escript, so this'd be update_swagger_url.escript, and then we could drop the enclosing quotes here (?)
|
@vkatsuba, do you intend to complete this, or is it Ok to close? |
@paulo-ferraz-oliveira, many thanks for reminding me about this PR. Yes, we definitely need to finish this implementation. I have quite a lot on my plate at the moment, but I’m hoping to get back to this PR within the next two weeks. If you’re okay with that, I’d appreciate it if you could wait for an update. If not, feel free to close this PR, and I’ll prepare a new one with a reference to the original. Thanks again for the reminder - I had completely forgotten about it. |
|
I can wait, especially if you're still working on it. Your time is appreciated. |

🎫 #206
🔗 Initial PR #204
🏗️ CI results https://github.com/vkatsuba/cowboy_swagger/actions/workflows/ci.yml