Hi I created a small docs draft adding install instructions for NixOS
since I initially wrote the woodpecker NixOS module which is now in
stable for ~6 months and multiple people my self included actively use
it. cc @ambroisie since we co-maintain it and he did a lot of
improvement work on the module.
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.
