Summary: | git ignore swagger.min.json | ||
---|---|---|---|
Product: | Koha | Reporter: | Benjamin Rokseth <benjamin.rokseth> |
Component: | Web services | Assignee: | Bugs List <koha-bugs> |
Status: | CLOSED FIXED | QA Contact: | Testopia <testopia> |
Severity: | enhancement | ||
Priority: | P5 - low | CC: | jonathan.druart, katrin.fischer, magnus, ztajoli |
Version: | Main | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: | ||
Attachments: | Bug 17243 - git ignore swagger.min.json |
Description
Benjamin Rokseth
2016-09-02 21:39:57 UTC
Created attachment 55145 [details] [review] Bug 17243 - git ignore swagger.min.json This patch adds *.min.json to .gitignore in swagger dir. To remove tracking of swagger.min.json run git update-index --assume-unchanged swagger.min.json Or just ignore uncommitted changes Could we deal with it similarly as with the OPAC CSS files? (https://wiki.koha-community.org/wiki/Working_with_Bootstrap_OPAC_LESS_files) I am not sure how this change would affect RM and packaging manager or the end users. Who will generate the minified file and when? Well, good question, many possible answers. Lari proposed in Bug 17102 an alternative to use inotify and a running daemon to pick up changes. I think, by now, plack should be on by default? At least it is necessary if using the api. Then it would perhaps make sense to build/update the swagger definitions on plack start/restart? It should be an easy patch, since the api has its own builder in plack.psgi. Thinking more of it, I would recommend the plack build solution. Something in the line of adding a sub to plack.psgi: sub minifySwagger { use Swagger2; my $swagger = Swagger2->new('/usr/share/koha/api/v1/swagger/swagger.json'); $swagger = $swagger->expand; #Fetch all JSON-Schema references my $data = $swagger->api_spec->data; delete($data->{id}); # delete non-valid "/id" open(SWOUT, ">:encoding(UTF-8)", '/usr/share/koha/api/v1/swagger/swagger.min.json') print SWOUT $swagger->to_string(); close(SWOUT); } and calling it inside the build method of the api. Obviously with some error-handling and relative paths. Thoughts? Looks like the patch submitter is recommending a different solution than the one in the patch? Setting to "In discussion". Actually, bug 17102 discusses the alternatives. This patch simply removes the minified swagger from source control, which I think is important. Setting back to need signoff and urge the discussion to move forward in 17102 ;) I've added this bug to the next dev meeting's agenda. We could imagine an "environment" pref (or in the config) with 2 values "dev" or "prod" (default "prod"). If "prod", the minified files are used (otherwise the non-minified). This could work for the css and swaggger min files. The RM(aints) will have to regenerated the min fils before each releases (automatically), but nothing to do for devs (no need to regenerated them) nor for testers (no conflict). Hi Jonathan, if that works, I am all for it! (In reply to Jonathan Druart from comment #8) > We could imagine an "environment" pref (or in the config) with 2 values > "dev" or "prod" (default "prod"). > If "prod", the minified files are used (otherwise the non-minified). > This could work for the css and swaggger min files. > The RM(aints) will have to regenerated the min fils before each releases > (automatically), but nothing to do for devs (no need to regenerated them) > nor for testers (no conflict). That is a very sensible suggestion! Also since it is a general solution that can be used any other place where compilation/minifying/regeneration would be neccessary in the future. Especially in the javascript world and the coming of ES6 this would make sense, as it would cover the need of browser shims and transpilation to code that works across browsers. No longer neccessary, due to Bug 17432. |