Currently translated at 99.6% (316 of 317 strings)
Translated using Weblate (German)
Currently translated at 99.6% (316 of 317 strings)
Co-authored-by: Jan Marx <jcm@jcm.re>
Co-authored-by: qwerty287 <ndev@web.de>
Translate-URL: http://translate.woodpecker-ci.org/projects/woodpecker-ci/ui/de/
Translation: Woodpecker CI/UI
1. new translation docs
2. lazy-load TimeAgo locales (used for "x min ago" messages). This 1.
reduces size and 2. provides all languages without adding them manually.
3. Remove DayJS locales, they're unused.
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>
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.
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>
closes#1743
fixes: setting secrets for own user namespace
- create org in database
- use orgID for org related APIs
Co-authored-by: 6543 <6543@obermui.de>
This PR introduces two new server configuration options, for providing a
custom .JS and .CSS file.
These can be used to show custom banner messages, add
environment-dependent signals, or simply a corporate logo.
### Motivation (what problem I try to solve)
I'm operating Woodpecker in multiple k8s clusters for different
environments.
When having multiple browser tabs open, I prefer strong indicators for
each environment.
E.g. a red "PROD" banner, or just a blue "QA" banner.
Also, we sometimes need to have the chance for maintenance, and instead
of broadcasting emails,
I prefer a banner message, stating something like: "Heads-up: there's a
planned downtime, next Friday, blabla...".
Also, I like to have the firm's logo visible, which makes Woodpecker
look more like an integral part of our platform.
### Implementation notes
* Two new config options are introduced ```WOODPECKER_CUSTOM_CSS_FILE```
and ```WOODPECKER_CUSTOM_JS_FILE```
* I've piggy-bagged the existing handler for assets, as it seemed to me
a minimally invasive approach
* the option along with an example is documented
* a simple unit test for the Gin-handler ensures some regression safety
* no extra dependencies are introduced
### Visual example
The documented example will look like this.
### Areas of uncertainty
This is my first contribution to Woodpecker and I tried my best to align
with your conventions.
That said, I found myself uncertain about these things and would be glad
about getting feedback.
* The handler tests are somewhat different than the other ones because I
wanted to keep them simple - I hope that still matches your coding
guidelines
* caching the page sometimes will let the browser not recognize changes
and a user must reload. I'm not fully into the details of how caching is
implemented and neither can judge if it's a real problem. Another pair
of eyes would be good.
Using a simple `pnpm update` didn't fix any of the issues in #1900 but
it fixes some vulnerabilities shown with `pnpm audit`. I didn't try to
force-update `semver` to fix the security vulnerability there.
---------
Co-authored-by: 6543 <6543@obermui.de>
closes#1801closes#1815closes#1144
closes #983
closes #557closes#1827
regression of #1791
# TODO
- [x] adjust log model
- [x] add migration for logs
- [x] send log line via grpc using step-id
- [x] save log-line to db
- [x] stream log-lines to UI
- [x] use less structs for log-data
- [x] make web UI work
- [x] display logs loaded from db
- [x] display streaming logs
- [ ] ~~make migration work~~ -> dedicated pull (#1828)
# TESTED
- [x] new logs are stored in database
- [x] log retrieval via cli (of new logs) works
- [x] log streaming works (tested via curl & webui)
- [x] log retrieval via web (of new logs) works
---------
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>
