AZEN-SGG/Kavita
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
Kavita/CONTRIBUTING.md
Joe Milazzo 089658e469
UX Alignment and bugfixes (#1663) 
* Refactored the design of reading list page to follow more in line with list view. Added release date on the reading list items, if it's set in underlying chapter.

Fixed a bug where reordering the list items could sometimes not update correctly with drag and drop.

* Removed a bug marker that I just fixed

* When generating library covers, make them much smaller as they are only ever icons.

* Fixed library settings not showing the correct image.

* Fixed a bug where duplicate collection tags could be created.

Fixed a bug where collection tag normalized title was being set to uppercase.

Redesigned the edit collection tag modal to align with new library settings and provide inline name checks.

* Updated edit reading list modal to align with new library settings modal pattern. Refactored the backend to ensure it flows correctly without allowing duplicate names.

Don't show Continue point on series detail if the whole series is read.

* Added some more unit tests around continue point

* Fixed a bug on series detail when bulk selecting between volume and chapters, the code which determines which chapters are selected didn't take into account mixed layout for Storyline tab.

* Refactored to generate an OpenAPI spec at root of Kavita. This will be loaded by a new API site for easy hosting.

Deprecated EnableSwaggerUi preference as after validation new system works, this will be removed and instances can use our hosting to hit their server (or run a debug build).

* Test GA

* Reverted GA and instead do it in the build step. This will just force developers to commit it in.

* GA please work

* Removed redundant steps from test since build already does it.

* Try another GA

* Moved all test actions into initial build step, which should drastically cut down on time. Only run sonar if the secret is present (so not for forks). Updated build requirements for develop and stable docker pushes.

* Fixed env variable

* Okay not possible to do secrets in if statement

* Fixed the build step to output the openapi.json where it's expected.
2022-11-20 12:32:21 -08:00

3.2 KiB
Raw Blame History

How to Contribute

We're always looking for people to help make Kavita even better, there are a number of ways to contribute.

Documentation

Setup guides, FAQ, the more information we have on the wiki the better.

Development

Tools required

Getting started

  1. Fork Kavita
  2. Clone the repository into your development machine. info
  3. Install the required Node Packages
    • cd Kavita/UI/Web
    • npm install
    • npm install -g @angular/cli
  4. Start angular server ng serve
  5. Build the project in Visual Studio/Rider, Setting startup project to API
  6. Debug the project in Visual Studio/Rider
  7. Open http://localhost:4200
  8. (Deployment only) Run build.sh and pass the Runtime Identifier for your OS or just build.sh for all supported RIDs.

Contributing Code

  • If you're adding a new, already requested feature, please comment on Github Issues so work is not duplicated (If you want to add something not already on there, please talk to us first)
  • Rebase from Kavita's develop branch, don't merge
  • Make meaningful commits, or squash them
  • Feel free to make a pull request before work is complete, this will let us see where its at and make comments/suggest improvements
  • Reach out to us on the discord if you have any questions
  • Add tests (unit/integration)
  • Commit with *nix line endings for consistency (We checkout Windows and commit *nix)
  • One feature/bug fix per pull request to keep things clean and easy to understand
  • Use 4 spaces instead of tabs, this is the default for VS 2019 and WebStorm (to my knowledge)
    • Use 2 spaces for UI files

Pull Requesting

  • Only make pull requests to develop, never main, if you make a PR to main we'll comment on it and close it
  • You're probably going to get some comments or questions from us, they will be to ensure consistency and maintainability
  • We'll try to respond to pull requests as soon as possible, if its been a day or two, please reach out to us, we may have missed it
  • Each PR should come from its own feature branch not develop in your fork, it should have a meaningful branch name (what is being added/fixed)
    • new-feature (Bad)
    • fix-bug (Bad)
    • patch (Bad)
    • develop (Bad)
    • feature/parser-enhancements (Great)
    • bugfix/book-issues (Great)

Swagger API

If you just want to play with Swagger, you can just

If you have any questions about any of this, please let us know.