All the client functions were in a single file, which was already very
long, and the test file gets even longer as more tests are added. I
split it into separate files representing the API path and started
adding some tests.
Fixes: https://github.com/woodpecker-ci/woodpecker/issues/1079
What do you think about using a consistent `woodpecker` color scheme?
Right now, the `lime` color scheme from windicss is used that does not
really fit the primary color used for the documentation website. I have
used the primary color `#4CAF50` from the docs and created a color
palette with https://palettte.app/:
<details>
<summary>JSON source</summary>
```Json
[
{
"paletteName": "New Palette",
"swatches": [
{
"name": "New Swatch",
"color": "166E30"
},
{
"name": "New Swatch",
"color": "248438"
},
{
"name": "New Swatch",
"color": "369943"
},
{
"name": "New Swatch",
"color": "4CAF50"
},
{
"name": "New Swatch",
"color": "68C464"
},
{
"name": "New Swatch",
"color": "8AD97F"
}
]
}
]
```
</details>
![image](https://github.com/woodpecker-ci/woodpecker/assets/3391958/a254f1e0-ce17-43a9-9e8b-72252296fd6f)
I have added this color scheme to the windicss config and replaced the
use of `lime` in the UI. While `woodpecker-300` would be the primary
color that is used for the docs, I currently use `woodpecke-400` as
primary color for the UI to fix some contrast issues.
![image](https://github.com/woodpecker-ci/woodpecker/assets/3391958/7bf751e1-f2a6-481c-bee7-a27d27cf8adb)
![image](https://github.com/woodpecker-ci/woodpecker/assets/3391958/e5673dc7-81c1-4fd4-bef9-14494bc5aa27)
What do you think? If you would like to stay with the current colors,
that's fine for me, I can just use the custom CSS feature in this case.
---------
Co-authored-by: 6543 <6543@obermui.de>
# Summary
This PR drops the outdated former swagger.yaml/json and introduced
automatic API document generation from Go code.
The generated code is also used to generate documentation/markdown for
the community page,
as well as enable the Woodpecker server to serve a Swagger Web UI for
manual tinkering.
I did opt-in for gin-swagger, a middleware for the Gin framework, to
ease implementation and have a sophisticated output.
This middleware only produces Swagger v2 specs. AFAIK the newer OpenApi
3x tooling is not yet that mature,
so I guess that's fine for now.
## Implemenation notes
- former swagger.json files removed
- former // swagger godocs removed
- introduced new dependency gin-swagger, which uses godoc annotations on
top of Gin Handler functions.
- reworked Makefile to automatically generate Go code for the server
- introduce new dependency go-swagger, to generate Markdown for
documentation purposes
- add a Swagger Web UI, incl. capabilities for manual API exploration
- consider relative root paths in the implementation
- write documentation for all exposed API endpoints
- incl. API docs in the community website (auto-generated)
- provide developer documentation, for the Woodpecker authors
- no other existing logic/code was intentionally changed
---------
close#292
---------
Co-authored-by: qwerty287 <80460567+qwerty287@users.noreply.github.com>
Co-authored-by: 6543 <6543@obermui.de>
- move cli files from `cli/drone` to `cli/`
- move cli main to `cmd/cli/main.go` to match agent and server
- use version from `version/version.go` to match agent and server
- Replace mkdocs with docosaurus (improved menu structure, ...)
- Structure docs into `Usage` and `Server Setup / Administration`
- Update favicon
- Create new pipeline-syntax page with all options and links to more detailed docs if available
- Add ci to publish to `woodpecker-ci.github.io`
- Deploy docs preview to surge for review
- Update start-page
Co-authored-by: 6543 <6543@obermui.de>