## Summary
Fixes#5590Fixes#5713
This PR fixes an issue where webhook handling fails with "failure to parse hook" error when the user's OAuth access token has expired. The root cause is that the Bitbucket and GitHub forge implementations make API calls during webhook processing without first refreshing the OAuth token.
## Problem
When a webhook arrives from Bitbucket or GitHub, the `Hook()` function (and its helper functions) make API calls to fetch additional data (changed files, repo info, etc.). These API calls use the stored OAuth access token, which may have expired.
**Before this fix:**
1. Webhook arrives
2. `Hook()` makes API calls with potentially expired token
3. API call fails with "OAuth2 access token expired"
4. Error bubbles up as HTTP 400 "failure to parse hook"
5. `forge.Refresh()` is called later in `PostHook()` - but it's too late
**Example error from logs:**
`failure to parse hook error="OAuth2 access token expired. Use your refresh token to obtain a new access token."`
## Solution
Add `forge.Refresh()` calls before making API calls in the webhook handling code paths. This follows the same pattern already used by:
- Bitbucket Data Center forge (`server/forge/bitbucketdatacenter/bitbucketdatacenter.go`)
- Other code paths like `pipeline.Create()`, `cron.go`, etc.
### Changes
**Bitbucket** (`server/forge/bitbucket/bitbucket.go`):
- Added `forge.Refresh()` in `Hook()` before API calls
**GitHub** (`server/forge/github/github.go`):
- Added `forge.Refresh()` in `loadChangedFilesFromPullRequest()`
- Added `forge.Refresh()` in `getTagCommitSHA()`
- Added `forge.Refresh()` in `loadChangedFilesFromCommits()`
## Testing
- All existing Bitbucket and GitHub forge tests pass
- Tested in production environment with Bitbucket (waited for token expiry, webhook succeeded after fix)
## Description
This is the first fix for: https://github.com/woodpecker-ci/woodpecker/issues/3932
Change the Pull Request hook parser to return the source commit, branch, and ref instead of the destination. Right now, the workflow pulls the destination configuration and code. It should pull the source configuration and code to verify that the configuration and code work as expected before merging the changes.
In case of the close event, the hook parser returns the destination branch, ref and merge commit. Usually, the contributor automatically deletes the source branch after merging the changes to the destination branch. Using the source values will cause the workflow to fail.
After the changes, Woodpecker will correctly download the workflow from the source branch (Pull Request commit), but it will fail to clone the repository. This issue is related to the commit format returned by the Bitbucket webhook. This inconsistency has already been reported: https://jira.atlassian.com/browse/BCLOUD-21201. The webhook returns a short SHA. The problem is that the `git fetch` command requires the full SHA.
A workaround for this issue is to use the ref to fetch the code:
```yaml
clone:
git:
image: woodpeckerci/plugin-git
settings:
ref: ${CI_COMMIT_REF}
```
This is not ideal, because the Pull Request head won't always match the workflow commit, but it solves 80% of the event use cases (e.g. trigger a pull request workflow on change). This workaround won't work when re-running a previous workflow pointing to another commit, it will pull the last commit, not the previous one.
## Solutions
The solution proposed by the community is to retrieve the full SHA from the Bitbucket API using the short one. This solution has drawbacks:
- The Bitbucket API rate limit is 1000 req/h. This solution will reduce the maximum number of workflow runs per hour.
- It requires a braking change in the forges interface because the ´Hook(...)´ method does not have an instance of the HTTP Client.
We propose to allow the git plugin to fetch the source code from a URL. The Bitbucket returns a link pointing to the commit.
This proposal only requires a small change to the git plugin:
- Add a new optional parameter (e.g. CommitLink)
- Add a clause to the following conditional: 7ac9615f40/plugin.go (L79C1-L88C3)
```go
if p.Pipeline.CommitLink != "" {...}
```
Git commands:
```shell
$ git fetch --no-tags --depth=1 --filter=tree:0 https://bitbucket.org/workspace/repo/commits/692972aabfec
$ git reset --hard -q 692972aabfec # It works with the short SHA
```
Woodpecker will set CommitLink to a blank string for the other forges, but Bitbuckket will use the one returned by the webhook.
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>
