This pull request addresses the issue https://github.com/woodpecker-ci/woodpecker/issues/3210.
Ideally, the Bitbucket API should include repository permissions when
utilizing the 'get all repositories' endpoint. However, as it currently
does not provide this information, a viable solution is to fetch all
permissions for every repository and then employ a dictionary to
associate each repository with its respective permissions.
Without implementing this fix, logging in becomes problematic for users
with access to a substantial number of repositories (300+), as the
process takes over 2 minutes to complete.
---------
Co-authored-by: Alberto Alcón <albertoalcon@bit2me.com>
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>
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>
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>
In order to test this functionality, we had to expose the `BranchHead()`
through an API endpoint
```
GET /repos/{repo_id}/branches/{branch}/head
```
The response is a string that contains the latest commit hash of the
requested branch.
for now it's not clear defined, what to do on an unsupported event.
e.g. gitea webhook panel shows 500 error and no message.
now we have a successful webhook and a message to show an info
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>