Separate this change from
https://github.com/woodpecker-ci/woodpecker/pull/3506
I would like to get at least this change into v2.5.0 if possible.
---------
Co-authored-by: qwerty287 <80460567+qwerty287@users.noreply.github.com>
This is the first step towards support for multiple forges (#138). It
inserts a forge using the currently existing env varaibles into db and
uses this forge from db later on in all places of the code.
closes#621
addresses #138
# TODO
- [x] add forges table
- [x] add id of forge to repo
- [x] use forge of repo
- [x] add forge from env vars to db if not exists
- [x] migrate repo.ForgeID to the newly generated forge
- [x] support cache with forge from repo
- [x] maybe add forge loading cache? (use LRU cache for forges, I expect
users to have less than 10 forges normally)
---------
Co-authored-by: qwerty287 <80460567+qwerty287@users.noreply.github.com>
…but if they're enabled, allow for all events. Also add warning that you
should only enable it if you trust the users with push access.
closes#3559
---------
Co-authored-by: Robert Kaussow <xoxys@rknet.org>
fixes#3389
Set variable to let server detect if it's deployed within a container
image.
Set the default database connection based on this.
---------
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Anbraten <6918444+anbraten@users.noreply.github.com>
This pull-requests re-introduces the Bitbucket Server support with a
more or less complete rewrite of the forge implementation. We have a lot
of on-premises git repositories hosted in Bitbucket Server and need a CI
solution for running that and Woodpecker looks promising.
The implementation is based on external Bitbucket Server REST client
library which we are maintaining and have created in another context.
Besides the original support for Bitbucket the re-implementation also
adds support for handling Bitbucket pull-request events.
Closes https://github.com/woodpecker-ci/woodpecker/discussions/2174
- return bad habit error if no event filter is set
- If this is applied, it's useless to allow `exclude`s on events.
Therefore, deprecate it together with `include`s which should be
replaced by `base.StringOrSlice` later.
Mostly those that did not require much work.
From #2960
---------
Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
As of #2520
Support to load new forges and agent backends at runtime using go's
plugin system. (https://pkg.go.dev/plugin)
I also added a simple example addon (a new forge which just prints log
statements), it should be removed later of course, but you can see an
example.
---------
Co-authored-by: Michalis Zampetakis <mzampetakis@gmail.com>
Co-authored-by: Anbraten <anton@ju60.de>
https://go.dev/doc/modules/release-workflow#breaking
Fixes https://github.com/woodpecker-ci/woodpecker/issues/2913 fixes
#2654
```
runephilosof@fedora:~/code/platform-woodpecker/woodpecker-repo-configurator (master)$ go get go.woodpecker-ci.org/woodpecker@v2.0.0
go: go.woodpecker-ci.org/woodpecker@v2.0.0: invalid version: module contains a go.mod file, so module path must match major version ("go.woodpecker-ci.org/woodpecker/v2")
```
---------
Co-authored-by: qwerty287 <80460567+qwerty287@users.noreply.github.com>
implement this fix but with an additional field on workflows to not
change the workflow name
closes#1840closes#713
---------
Co-authored-by: 6543 <6543@obermui.de>
- refactor pipeline parsing
- do not parse the pipeline multiple times to perform filter checks, do
this once and perform checks on the result directly
- code deduplication
- refactor forge token refreshing
- move refreshing to a helper func to reduce code
---------
Co-authored-by: Anbraten <anton@ju60.de>
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>
close#2079
as we sett the global vars **after** migrations we did never had a
chance to propagate a **true** in WOODPECKER_MIGRATIONS_ALLOW_LONG to
the migrations ...
---------
Co-authored-by: qwerty287 <80460567+qwerty287@users.noreply.github.com>
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.
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>
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.
Do not sync repos with forge if the repo is not necessary in DB.
In the DB, only repos that were active once or repos that are currently
active are stored. When trying to enable new repos, the repos list is
fetched from the forge instead and displayed directly. In addition to
this, the forge func `Perm` was removed and is now merged with `Repo`.
Solves a TODO on RepoBatch.
---------
Co-authored-by: Anbraten <anton@ju60.de>
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>
