Add scopes needed when creating Github application.
Removed "repo:status" scope, because it is included in already requested
"repo" scope.
Fixes: #1081
CRI-O currently requires some additional config for pipelines to run.
This adds some basic documentation to the kubernetes section explaining
the issue.
See #2510
I had experienced some issues running Woodpecker behind a reverse-proxy,
resulting from not defining the `WOODPECKER_ROOT_PATH` environment
variable in #2477.
As suggested by @qwerty287, specifying `WOODPECKER_ROOT_PATH=/foo`
*mostly* solved the issue of running the woodpecker server at an url
like `https://example.org/foo`.
However, the webhook urls and badge urls were generated excluding the
configured `WOODPECKER_ROOT_PATH`.
This PR (mostly) fixes issues related to non-empty
`WOODPECKER_ROOT_PATH`.
---------
Co-authored-by: qwerty287 <80460567+qwerty287@users.noreply.github.com>
- Slimify
- Add required permissions (missing so far)
- More detailed instructions on app settings
- Align env var options to style used in k8s section (UL instead of
headers)
---------
Co-authored-by: Lauris BH <lauris@nix.lv>
The `runs_on` section is missing from the syntax docs. So I added a
section for it, and linked to an example.
It's good enough. But I think it might be a good idea for someone (with
more knowledge than me) to add more info in this section. How to use it,
when to use it, etc. The example is useful but not very informative.
The current documentation mentions that when one uses woodpecker on the
same host as Gitlab, you might need to set the `Allow requests to the
local network from webhooks and integrations` option on the gitlab
server.
This option not only needs to be set when running on the same host, but
also needs to be set when setting up woodpecker with Gitlab on any
RFC1918 net and on any non standard TLD like `.local` or `.internal`.
official spec linked at top of page is inaccessible for most readers
(it's too dry and academic)
so added famous cheatsheet (heavily promoted on StackOverflow)
As suggested in
https://github.com/woodpecker-ci/woodpecker/discussions/2160.
- Simplified wording
- Referenced helm chart
- Removed "experimental" banner as the k8s backend is quite stable I'd
say (after using it for months now)
- Add example for `resources` definition`
---------
Co-authored-by: Anbraten <anton@ju60.de>
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.
Related-to: https://github.com/woodpecker-ci/woodpecker/pull/2078
Remaining CVEs:
```
❯ trivy fs --exit-code 1 --skip-dirs node_modules/,plugins/woodpecker-plugins/node_modules/ docs/
2023-08-01T10:02:36.911+0200 INFO Vulnerability scanning is enabled
2023-08-01T10:02:36.911+0200 INFO Secret scanning is enabled
2023-08-01T10:02:36.911+0200 INFO If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2023-08-01T10:02:36.911+0200 INFO Please see also https://aquasecurity.github.io/trivy/v0.43/docs/scanner/secret/#recommendation for faster secret detection
2023-08-01T10:02:36.963+0200 INFO Number of language-specific files: 1
2023-08-01T10:02:36.963+0200 INFO Detecting pnpm vulnerabilities...
pnpm-lock.yaml (pnpm)
Total: 2 (UNKNOWN: 0, LOW: 0, MEDIUM: 1, HIGH: 1, CRITICAL: 0)
┌─────────┬────────────────┬──────────┬───────────────────┬────────────────┬──────────────────────────────────────────────────────────────┐
│ Library │ Vulnerability │ Severity │ Installed Version │ Fixed Version │ Title │
├─────────┼────────────────┼──────────┼───────────────────┼────────────────┼──────────────────────────────────────────────────────────────┤
│ got │ CVE-2022-33987 │ MEDIUM │ 9.6.0 │ 11.8.5, 12.1.0 │ missing verification of requested URLs allows redirects to │
│ │ │ │ │ │ UNIX sockets │
│ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2022-33987 │
├─────────┼────────────────┼──────────┼───────────────────┼────────────────┼──────────────────────────────────────────────────────────────┤
│ trim │ CVE-2020-7753 │ HIGH │ 0.0.1 │ 0.0.3 │ nodejs-trim: Regular Expression Denial of Service (ReDoS) in │
│ │ │ │ │ │ trim function │
│ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2020-7753 │
└─────────┴────────────────┴──────────┴───────────────────┴────────────────┴──────────────────────────────────────────────────────────────┘
```
- `trim` is pulled in by `@docusaurus/theme-classic` and can be ignored
due to
https://github.com/facebook/docusaurus/issues/7275#issuecomment-1113997259
- `got` can be ignored as well, see `trim`
Various ways to factor out common data in a pipeline file - having them
in one place rather than spread out over many pages, will help newbies
like me.
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.
Add Kubernetes Deployments and StatefulSet update and Dockle Scan Plugins.
For Kubernetes plugin, I based on the Drone unmaintened Kubernetes
plugin and took the statefulset management evolutions. I added sync/wait
and force redeploy capabilities + updates dependencies
For Dockle plugin, I took example on Trivy plugin.
Add plugin [Nextcloud Upload](https://github.com/Ellpeck/WoodpeckerPlugins/tree/main/nextcloud-upload) to the official plugin list.
there's already an official plugin that allows uploading
files using WebDAV, but my plugin has two Nextcloud-specific additions
that aren't part of the regular WebDAV spec:
- The ability to chunk uploads, which is necessary for larger files if
Nextcloud is hosted behind Cloudflare (which restricts uploads to a
maximum of 100MB)
- The ability to apply Nextcloud tags, which allows automatically
categorizing items and using Nextcloud's Retention plugin to easily
auto-remove older artifacts.
This add a simple implementation of requests/limits for individual
steps. There is no validation of what the resource actually is beyond
checking that it can successfully be converted to a Quantity, so it can
be used for things other than just memory/CPU.
close#1809
# 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>
it did make sense to have it still supported within v0.15.0,
but as we move future away and with the release of v1.0.0
we should not give the appearance of still support the original drone
v0.8 config
Gogs support is broken (and we won't fix it because we don't care about
it...) because it does not support OAuth, at least after we introduced
the new Vue UI.
See:
77d830d5b5/server/forge/gogs/gogs.go (L84)
This route is not present in the new UI.
closes#1636closes#1429
supersedes #1586
Uses a different approach: just take the index.html compiled by vite and
replace the paths to js and other files using regex. This is not
compatible with the dev proxy which is also the reason why we can't use
go templates for this.
# Changes
- Adds an admin view to see the whole work-queue of the server.
- The admin can also pause / resume the queue.
- The view is reloading data every 5 seconds automatically.
- The task model from queue got removed in favor of the one from models.
Coding support is likely broken and nobody will ever fix it. Also it
looks like nobody wants to use it, otherwise we would have get some bug
reports.
---------
Co-authored-by: 6543 <6543@obermui.de>
