Skip to content

Add possibility to configure own path to "/api-docs/swagger.json" - #207

Draft
vkatsuba wants to merge 16 commits into
inaka:masterfrom
vkatsuba:issues-206
Draft

Add possibility to configure own path to "/api-docs/swagger.json"#207
vkatsuba wants to merge 16 commits into
inaka:masterfrom
vkatsuba:issues-206

Conversation

@vkatsuba

@vkatsuba vkatsuba commented Oct 9, 2024

Copy link
Copy Markdown

@vkatsuba
vkatsuba marked this pull request as draft October 9, 2024 08:11
@vkatsuba
vkatsuba marked this pull request as ready for review October 9, 2024 09:27
@vkatsuba

vkatsuba commented Oct 9, 2024

Copy link
Copy Markdown
Author

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 😃

@elbrujohalcon elbrujohalcon left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread .github/workflows/ci.yml Outdated
strategy:
matrix:
otp_vsn: ['24', '25', '26']
otp_vsn: ['25', '26']

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you mind adding '27' here, @vkatsuba ?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw - it strange that in CI we got this issue... locally I use OTP 24 and it builded as well for me...

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You probably had a cached version of the library.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope. Not that.
Because the libs all have version numbers…

{project_plugins,
[{rebar3_hank, "~> 1.4.0"},
{rebar3_hex, "~> 7.0.7"},
{rebar3_format, "~> 1.3.0"},
{rebar3_lint, "~> 3.1.0"},
{rebar3_ex_doc, "~> 0.2.20"}]}.

No idea what's going on.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Try running rebar3 upgrade --all. Let's see what it tells you.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CI updates as well https://github.com/vkatsuba/cowboy_swagger/actions/runs/11253721613

The rebar3 upgrade show all green

@vkatsuba vkatsuba Oct 9, 2024

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 🤢

Comment thread rebar.config.script Outdated
@@ -0,0 +1,24 @@
%% Reading the contents of the file
case file:read_file("priv/swagger/swagger-initializer.js") of

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was add to gitginore this file.. hope it will fix issue

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a good idea… we do want that file downloaded when people clones the repo.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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)… 🤔

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah… that's not a bad idea. What do you think, @paulo-ferraz-oliveira ?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@elbrujohalcon

elbrujohalcon commented Oct 9, 2024

Copy link
Copy Markdown
Member

Furthermore, @vkatsuba why don't we make the whole url configurable, instead of just the base path?
That way, people will be able to use stuff like…

  • window.location.origin + '/api-docs/swagger.json'; or…
  • https://my.other.server/api-docs/swagger.json'; or…
  • window.location.origin + '/my-other-path/swagger.json'; or…
  • window.location.origin + '/api-docs/my-other.json'

@vkatsuba

vkatsuba commented Oct 9, 2024

Copy link
Copy Markdown
Author

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.

@vkatsuba

vkatsuba commented Oct 9, 2024

Copy link
Copy Markdown
Author

Furthermore, @vkatsuba why don't we make the whole url configurable, instead of just the base path? That way, people will be able to use stuff like…

* `window.location.origin + '/api-docs/swagger.json'`; or…

* `https://my.other.server/api-docs/swagger.json'`; or…

* `window.location.origin + '/my-other-path/swagger.json'`; or…

* `window.location.origin + '/api-docs/my-other.json'`

Well.... I suppose for this case we need use something like
path and url or something like that, because the path value is used in few places where the end of URL can be index.html.... but... we can take a URL and parse it maybe and use specific parts where we want... OK, let's follow second approach, let's make changes for path and then we will back tho this discussion as well.

@elbrujohalcon

elbrujohalcon commented Oct 9, 2024 via email

Copy link
Copy Markdown
Member

@vkatsuba

vkatsuba commented Oct 9, 2024

Copy link
Copy Markdown
Author

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

elbrujohalcon commented Oct 9, 2024

Copy link
Copy Markdown
Member

Please use an escript :)

@vkatsuba

vkatsuba commented Oct 9, 2024

Copy link
Copy Markdown
Author

68747470733a2f2f6d656469612e74656e6f722e636f6d2f556267505f564e35475830414141414d2f6e6f6f6f6f2d737461722d776172732e676966

Please use an escript :)

The dark side clouds everything... but we remain one with the Force. 💫⚔️ May the light guide your way, even in Vader's shadow. Done!

@vkatsuba

vkatsuba commented Oct 9, 2024

Copy link
Copy Markdown
Author

@elbrujohalcon, @paulo-ferraz-oliveira for now we use escript for create priv/swagger/swagger-initializer.js based on new priv/swagger/swagger-initializer.template. The swagger-initializer.js now is not a part of this repo and will be ignored

Comment thread .github/workflows/up_swagger.sh Outdated
Comment thread .gitignore Outdated
Comment thread priv/update_swagger_url Outdated
Comment thread rebar.config Outdated
Comment on lines +39 to +40
SwaggerPath = application:get_env(cowboy_swagger, path, "/api-docs"),
{{true, SwaggerPath ++ "/index.html"}, Req, State}.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll write an inline comment in the proper place…

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes... end to end testing will be need to do...

Comment thread priv/update-swagger-url Outdated
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"),

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@elbrujohalcon

Copy link
Copy Markdown
Member

@vkatsuba we need a very very different approach for this (as I mentioned in my inline comment). We need to…

  1. Keep the template file in the repo.
  2. Update the template file in up_swagger.sh, so that it has the placeholder.
  3. Add a special trail to https://github.com/inaka/cowboy_swagger/blob/master/src/cowboy_swagger_handler.erl so that, when it handles a request for /api-docs/swagger-initializer.js, it reads the template, replaces the placeholder with the proper value and returns that… instead of returning the file directly.

@elbrujohalcon

Copy link
Copy Markdown
Member

But @vkatsuba… please check cowboy_swagger_handler carefully… because, for instance, I had forgotten about the static_files env variable and that thing already allows users to pick up swagger files (jsons, htmls, everything) from a different path (instead of api-docs).

@vkatsuba

vkatsuba commented Oct 9, 2024

Copy link
Copy Markdown
Author

@vkatsuba we need a very very different approach for this (as I mentioned in my inline comment). We need to…

1. Keep the template file in the repo.

2. Update the template file in `up_swagger.sh`, so that it has the placeholder.

3. Add a special trail to https://github.com/inaka/cowboy_swagger/blob/master/src/cowboy_swagger_handler.erl so that, when it handles a request for `/api-docs/swagger-initializer.js`, it reads the template, replaces the placeholder with the proper value and returns that… instead of returning the file directly.

But the points 1 and 2 already done?

@vkatsuba
vkatsuba marked this pull request as draft October 9, 2024 13:41
Comment thread .github/workflows/ci.yml
rebar3_vsn: ['3.22']
steps:
- uses: actions/checkout@v3
- uses: actions/checkout@v4

@paulo-ferraz-oliveira paulo-ferraz-oliveira Oct 12, 2024

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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\'"

@paulo-ferraz-oliveira paulo-ferraz-oliveira Oct 12, 2024

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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',

@paulo-ferraz-oliveira paulo-ferraz-oliveira Oct 12, 2024

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Same comment as before, for the ". Was it required to be changed?

Comment thread README.md
Comment on lines +122 to +123
%% `path`: Path where you can access Swagger-UI. Default: `/api-docs`
{path, "/api-docs-swagger"},

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread README.md
Comment on lines -136 to +139
basePath => "/api-docs"
%% See "path" config section
basePath => "/api-docs-swagger"

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Comment thread priv/update-swagger-url
@@ -0,0 +1,40 @@
#!/usr/bin/env escript
-module('update-swagger-url').

@paulo-ferraz-oliveira paulo-ferraz-oliveira Oct 12, 2024

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 (?)

@paulo-ferraz-oliveira

Copy link
Copy Markdown
Collaborator

@vkatsuba, do you intend to complete this, or is it Ok to close?

@vkatsuba

Copy link
Copy Markdown
Author

@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.

@paulo-ferraz-oliveira

Copy link
Copy Markdown
Collaborator

I can wait, especially if you're still working on it. Your time is appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants