\n\nAnd here is the outcome on BitBucket:\n\u003Cimg width=\"479\" height=\"182\" alt=\"Image\" src=\"https://github.com/user-attachments/assets/11c2a65d-cbf2-4162-9805-3d035bdac04e\" />\n\n\n### Steps to reproduce\n\n1. Run Woodpecker with BitBucket Cloud forge\n2. Create a pipeline that uses a matrix\n3. Let the pipeline finish on Woodpecker\n4. Observe the build statuses on the commit in BitBucket\n\n### Expected behavior\n\nBoth pipelines should show completed.\n\n### System Info\n\n```shell\nWoodpecker version: v3.8.0\n```\n\n### Additional context\n\n_No response_\n\n### Validations\n\n- [x] Read the [docs](https://woodpecker-ci.org/docs/intro).\n- [x] Check that there isn't [already an issue](https://github.com/woodpecker-ci/woodpecker/issues) that reports the same bug to avoid creating a duplicate.\n- [x] Checked that the bug isn't fixed in the `next` version already [https://woodpecker-ci.org/versions]",[3019],{"name":3020,"color":3021},"bug","d73a4a",5338,"woodpecker-ci","woodpecker","open","Build status not completing on matrix pipelines with BitBucket","2025-07-17T18:03:12Z","https://github.com/woodpecker-ci/woodpecker/issues/5338",0.6169588,{"description":3031,"labels":3032,"number":3034,"owner":3023,"repository":3024,"state":3025,"title":3035,"updated_at":3036,"url":3037,"score":3038},"### Component\r\n\r\nserver\r\n\r\n### Describe the bug\r\n\r\nStep with `when.status: [failure]` doesn't run on failed pipeline, instead runs step with `when.status: [success]`.\r\n\r\n### Steps to reproduce\r\n\r\n1. Woodpecker + some Forge\r\n2. Make a pipeline\r\n\r\n```yaml\r\n# build.yaml\r\nskip_clone: true\r\nsteps:\r\n build:\r\n image: alpine\r\n commands:\r\n - echo 'Building the app'\r\n - exit 1 # 0 - success, 1 - fail\r\n```\r\n```yaml\r\n# notifications.yaml\r\nskip_clone: true\r\ndepends_on: [build]\r\nruns_on: [success, failure]\r\nsteps:\r\n fail-notification:\r\n when:\r\n - status: [failure]\r\n image: alpine\r\n commands:\r\n - echo 'Build failed'\r\n success-notification:\r\n when:\r\n - status: [success]\r\n image: alpine\r\n commands:\r\n - echo 'Build succeed'\r\n```\r\n3. Run manually and get wrong step execution\r\n\r\n\r\n### Expected behavior\r\n\r\n1. `fail-notification` step runs\r\n2. `success-notification` skips\r\n\r\n### System Info\r\n\r\n```shell\r\nWP `next-f87e80381b`, `2.7.1`, Gitea, Postgres 16\r\n```\r\n\r\n\r\n### Additional context\r\n\r\nhttps://github.com/woodpecker-ci/woodpecker/issues/4337#issuecomment-2468498847\r\n\r\n### Validations\r\n\r\n- [X] Read the [docs](https://woodpecker-ci.org/docs/intro).\r\n- [X] Check that there isn't [already an issue](https://github.com/woodpecker-ci/woodpecker/issues) that reports the same bug to avoid creating a duplicate.\r\n- [X] Checked that the bug isn't fixed in the `next` version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]",[3033],{"name":3020,"color":3021},4355,"when.status:failure doesn't work across workflows (runs_on:failure)","2024-11-19T10:27:03Z","https://github.com/woodpecker-ci/woodpecker/issues/4355",0.6758662,{"description":3040,"labels":3041,"number":3045,"owner":3023,"repository":3024,"state":3025,"title":3046,"updated_at":3047,"url":3048,"score":3049},"### Component\r\n\r\nserver\r\n\r\n### Describe the bug\r\n\r\nWe've been experience two issues with repositories that have a \"large\" number of workflows: I have a repository with 41 workflows and another with 61. They're certainly outliers... but they exist.\r\n\r\n1. [Secondary rate limits](https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#about-secondary-rate-limits). They will show up as this on the server as:\r\n\r\n```\r\n{\"level\":\"error\",\"error\":\"POST https://api.github.com/repos/\u003Corg>/\u003Crepo>/statuses/\u003Chash>: 403 You have exceeded a secondary rate limit. Please wait a few minutes before you try again. If you reach out to GitHub Support for help, please include the request ID \u003Cid>.\",\"time\":\"2024-08-21T13:31:15Z\",\"message\":\"error setting commit status for \u003Corg>/\u003Crepo>/11082\"}\r\n```\r\n\r\nThere's also a variation `could not get folder from forge`.\r\n\r\nIf this is resolved in a timely manner (in less than 10 seconds) then the server replies with a 400 and a \"failure to parse hook\" message. We have observed that this is a relatively common occurrence, repositories with 20 or so workflows will receive \"a few\" of those daily.\r\n\r\n2. A more general issue is timeouts. [GitHub has a 10 second timeout on webhooks](https://docs.github.com/en/webhooks/testing-and-troubleshooting-webhooks/troubleshooting-webhooks#timed-out). If the server takes too long to request all the workflows (wether or not it is rate limited) and doesn't reply within 10 second then the webhook will show as a \"504\".\r\n\r\nFrom what I've seem both issues are often correlated. A secondary rate limit will likely cause the webhook to timeout. That said _it seems_ that a timeout alone is possible and itself not destructive. If a webhook timeout happens but the Woodpecker server does manage to parse all workflows (even if it takes more than 10 seconds) and process them, the job is created, picked up by an agent and even updates the github UI.\r\n\r\nHowever when secondary rate limits happens, its worse. The server code doesn't handle rate limits. If it's `could not get folder from forge` error, then the pipeline job is not created. From the user's perspective this is a silent error. They make a push but no pipeline is started, so it can be very hard to debug without access to the server logs. There's also `error setting commit status`; in this case it seems to be implied (didn't get to track one down) that the success/failure/running status wouldn't be updated on the commit which could cause issues with pull request validation.\r\n\r\nFWIW I'm testing this internally https://github.com/quintoandar/woodpecker/pull/20 which uses a github secondary rate limit library to try and fix the first issue. Looks promising.\r\n\r\nFixing timeouts seems more complex. Arguably it might just be a hard limit on Woodpecker, maybe it makes no sense to support 40+ workflows. Or it'd need to process them asynchronously through an internal queue (but then there's the scenario where Woodpecker replies 200 to GitHub and later asynchronously finds ou some of the workflows are invalid).\r\n\r\n### Steps to reproduce\r\n\r\n1. Install woodpecker and configure GitHub as the forge\r\n2. To force the secondary rate limit and/or timeout create a test repository with 100+ workflows (doesn't matter what they do)\r\n\r\n\r\n\r\n### Expected behavior\r\n\r\n_No response_\r\n\r\n### System Info\r\n\r\n```shell\r\nWoodpecker 2.7.0, installed on Kubernetes, GitHub forge\r\n```\r\n\r\n\r\n### Additional context\r\n\r\n_No response_\r\n\r\n### Validations\r\n\r\n- [X] Read the [docs](https://woodpecker-ci.org/docs/intro).\r\n- [X] Check that there isn't [already an issue](https://github.com/woodpecker-ci/woodpecker/issues) that reports the same bug to avoid creating a duplicate.\r\n- [X] Checked that the bug isn't fixed in the `next` version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]",[3042],{"name":3043,"color":3044},"enhancement","7E1FE4",4052,"Errors with large number of multiple workflows on GitHub (rate limits and timeouts)","2024-09-07T07:08:15Z","https://github.com/woodpecker-ci/woodpecker/issues/4052",0.68582475,{"description":3051,"labels":3052,"number":3054,"owner":3023,"repository":3024,"state":3025,"title":3055,"updated_at":3056,"url":3057,"score":3058},"### Component\n\nagent, web-ui\n\n### Describe the bug\n\nOn all my pipelines only the first few log lines appear in the webui. Then everything else is cut out. I can certainly see the log output when I kubectl logs wp-1234.... the step/pipeline, bit it doesn't seem to get sent to the server from the agent.\r\n\r\nI also see a lot of \r\n`{\"level\":\"error\",\"repo\":\"renovatebot/renovate\",\"pipeline\":\"2064\",\"workflow_id\":\"6848\",\"image\":\"docker.io/woodpeckerci/plugin-git:2.5.1\",\"workflow_id\":\"6848\",\"error\":\"io: read/write on closed pipe\",\"time\":\"2024-11-17T13:04:52Z\",\"message\":\"copy limited logStream part\"}`\r\n\r\non the agent and \r\n\r\n`{\"level\":\"error\",\"repo_id\":\"29\",\"pipeline_id\":\"4660\",\"workflow_id\":\"6871\",\"error\":\"stream: not found\",\"time\":\"2024-11-18T12:55:30Z\",\"message\":\"done: cannot close log stream for step 21827\"}` and `{\"level\":\"error\",\"repo_id\":\"29\",\"pipeline_id\":\"4660\",\"workflow_id\":\"6871\",\"error\":\"sql: no rows in result set\",\"time\":\"2024-11-18T12:55:30Z\",\"message\":\"queue.Done: cannot ack workflow\"}`\r\n\r\non the server.\r\n\r\nIt has to be mentioned, that before a month ago (I upgrade woodpecker almost immediately after release) the logs worked almost flawlessly for more than a year, since I switched from drone to woodpecker.\r\n\r\nCurrently I don't know where to start debugging, to get to the bottom of this. Do you have any pointers?\n\n### Steps to reproduce\n\ninstall woodpecker using the helm chart version 1.6.2 on a kubernetes cluster v1.31 only setting WOODPECKER_BACKEND_K8S_STORAGE_RWX: false beside the setup with a forge using https://woodpecker-ci.org/docs/next/administration/forges/forgejo\n\n### Expected behavior\n\nI expect to always get all the logs, when I click on a step/workflow. \n\n### System Info\n\n```shell\n{\"source\":\"https://github.com/woodpecker-ci/woodpecker\",\"version\":\"2.7.3\"}\n```\n\n\n### Additional context\n\n_No response_\n\n### Validations\n\n- [X] Read the [docs](https://woodpecker-ci.org/docs/intro).\n- [X] Check that there isn't [already an issue](https://github.com/woodpecker-ci/woodpecker/issues) that reports the same bug to avoid creating a duplicate.\n- [X] Checked that the bug isn't fixed in the `next` version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]",[3053],{"name":3020,"color":3021},4409,"Logs only showing the first few lines of each step","2024-11-19T10:25:07Z","https://github.com/woodpecker-ci/woodpecker/issues/4409",0.70685226,{"description":3060,"labels":3061,"number":3066,"owner":3023,"repository":3024,"state":3025,"title":3067,"updated_at":3068,"url":3069,"score":3070},"### Component\r\n\r\nweb-ui\r\n\r\n### Describe the bug\r\n\r\nRunning pipeline with a service, it doesn't change its status and logs are empty unless page are reloaded.\r\n\r\nPipeline:\r\n```yaml\r\nservices:\r\n database:\r\n image: mysql\r\n environment:\r\n - MYSQL_DATABASE=test\r\n - MYSQL_ROOT_PASSWORD=example\r\n ports:\r\n - 3306\r\nsteps:\r\n get-version:\r\n image: ubuntu\r\n commands:\r\n - ( apt update && apt dist-upgrade -y && apt install -y mysql-client 2>&1 )> /dev/null\r\n - sleep 60s # need to wait for mysql-server init\r\n - echo 'SHOW VARIABLES LIKE \"version\"' | mysql -uroot -hdatabase test -pexample\r\n```\r\n\r\nStart pipeline and click on the service step - logs exist:\r\n\r\n\r\nThen switch to the general step and wait to complete - there are logs, status changes to completed, execution timer stops:\r\n\r\n\r\nSwitch back to the service - now there are no logs, step is executing forever:\r\n\r\n\r\nAfter page reloading, all displays as expected - logs, status and execution timer:\r\n\r\n\r\nThe later should be without refreshing page.\r\n\r\n\r\n### System Info\r\n\r\n```shell\r\n2.0.0-rc.0, Kubernetes\r\n```\r\n\r\n\r\n### Additional context\r\n\r\n_No response_\r\n\r\n### Validations\r\n\r\n- [X] Read the [Contributing Guidelines](https://github.com/woodpecker-ci/woodpecker/blob/main/CONTRIBUTING.md).\r\n- [X] Read the [docs](https://woodpecker-ci.org/docs/intro).\r\n- [X] Check that there isn't [already an issue](https://github.com/woodpecker-ci/woodpecker/issues) that reports the same bug to avoid creating a duplicate.\r\n- [X] Checked that the bug isn't fixed in the `next` version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]\r\n- [X] Check that this is a concrete bug. For Q&A join our [Discord Chat Server](https://discord.gg/fcMQqSMXJy) or the [Matrix room](https://matrix.to/#/#woodpecker:matrix.org).",[3062,3063],{"name":3020,"color":3021},{"name":3064,"color":3065},"ui","46DEA2",2831,"Service step doesn't change its status","2024-01-09T21:30:54Z","https://github.com/woodpecker-ci/woodpecker/issues/2831",0.71190286,{"description":3072,"labels":3073,"number":3075,"owner":3023,"repository":3024,"state":3025,"title":3076,"updated_at":3077,"url":3078,"score":3079},"### Component\n\nserver\n\n### Describe the bug\n\nWe changed the Bitbucket build status key to use the same common method as other forges when reporting back the build status to the forge. It works as expected for Woodpecker instances that have not been running for a long time, but it starts failing on those that already have a lot of workflow runs.\n\nThe problem is the template we use to generate the key: \n\nhttps://github.com/woodpecker-ci/woodpecker/blob/1f23da379ef4ca103138c066baafcd65260b4005/cmd/server/flags.go#L279\n\nTemplate: \"{{ .context }}/{{ .event }}/{{ .workflow }}{{if not (eq .axis_id 0)}}/{{.axis_id}}{{end}}\"\n\nBitbucket has a maximum key length of 40 characters. It works as expected if axis_id is not added. The generated key without the axis_id has ~30 characters:\n- ci/woodpecker/branch/woodpecker (31)\n- ci/woodpecker/pr/woodpecker (27)\n\nBefore proposing a fix, I want to understand the purpose of the axis_id. I could not figure it out. What is the axis_id used for?\n\n### Steps to reproduce\n\n1. Woodpecker instance with axis_id > 100000000\n2. Trigger a Woodpecker workflow\n\n### Expected behavior\n\n1. The key should always be less than 40 characters for the Bitbucket forge\n\n### System Info\n\n```shell\n{\"source\":\"https://github.com/woodpecker-ci/woodpecker\",\"version\":\"next-aac914cfae\"}\n```\n\n### Additional context\n\n_No response_\n\n### Validations\n\n- [x] Read the [docs](https://woodpecker-ci.org/docs/intro).\n- [x] Check that there isn't [already an issue](https://github.com/woodpecker-ci/woodpecker/issues) that reports the same bug to avoid creating a duplicate.\n- [x] Checked that the bug isn't fixed in the `next` version already [https://woodpecker-ci.org/versions]",[3074],{"name":3020,"color":3021},5176,"BitBucket build status key is too long","2025-05-14T07:35:49Z","https://github.com/woodpecker-ci/woodpecker/issues/5176",0.71968436,{"description":3081,"labels":3082,"number":3087,"owner":3023,"repository":3024,"state":3088,"title":3089,"updated_at":3090,"url":3091,"score":3092},"### Component\n\nserver\n\n### Describe the bug\n\nWhen build finishes(either successfully or with failure) the status doesn't get updated, even though the commit status of the last commit on the PR is updated just fine.\n\nI was able to trace back this bug to this PR: https://github.com/woodpecker-ci/woodpecker/pull/4724\n\nNow I see the need for the `Ref` to be set when updating the build status but it turns out that `pipeline.Ref` doesn't have a correct value. In my case it would set only the ref as follows: `refs/pull-requests/\u003CpullRequestID>/from`. I was able to find that `Ref` gets set [here](https://github.com/woodpecker-ci/woodpecker/blob/main/server/forge/bitbucketdatacenter/convert.go#L122) and I believe this is wrong, it's not a \"valid\" git ref and if ref is set to an invalid value BitBucket will not set the build status for that PR(https://community.atlassian.com/forums/Bitbucket-questions/Re-Builds-not-appearing-in-pull-requests/qaq-p/1805991/comment-id/65864#M65864).\n\nI suggest that we change the code from above to:\n```go\nRef: fmt.Sprintf(\"refs/heads/%s\", ev.PullRequest.Source.DisplayID),\n```\nI believe this would fix the issue, and I would like to work on it if possible.\n\nAdding: @Levy-Tal as he worked on PR mentioned above and @langecode because he is the main contributor behind the BitBucket Datacenter forge integration.\n\n\n### Steps to reproduce\n\n1. Open a PR with woodpecker pipelines on BitBucket Datacenter\n2. Trigger a build on the last commit of that PR\n3. Wait for the build to finish\n4. Observe that there is no status on the PR itself\n\n### Expected behavior\n\nThere should be a build status on the PR.\n\n### System Info\n\n```shell\nWoodpecker version: v3.5.2\nHelm chart version: 3.1.0\n```\n\n### Additional context\n\n_No response_\n\n### Validations\n\n- [x] Read the [docs](https://woodpecker-ci.org/docs/intro).\n- [x] Check that there isn't [already an issue](https://github.com/woodpecker-ci/woodpecker/issues) that reports the same bug to avoid creating a duplicate.\n- [x] Checked that the bug isn't fixed in the `next` version already [https://woodpecker-ci.org/versions]",[3083,3084],{"name":3020,"color":3021},{"name":3085,"color":3086},"forge/bitbucket","E96280",5158,"closed","PR build status does not get updated on BitBucket Datacenter","2025-05-13T15:29:01Z","https://github.com/woodpecker-ci/woodpecker/issues/5158",0.6405972,{"description":3094,"labels":3095,"number":3099,"owner":3023,"repository":3024,"state":3088,"title":3100,"updated_at":3101,"url":3102,"score":3103},"Gitlab seems to have an issue which results in single Woodpecker pipelines being shown as multiple pipelines in Gitlab.\r\n\r\n expected:\r\n\r\n\r\ncurrently (two pipelines with a single job):\r\n\r\n\r\nGitlab issue: https://gitlab.com/gitlab-org/gitlab/-/issues/13134",[3096,3097],{"name":3020,"color":3021},{"name":3098,"color":3086},"forge/gitlab",618,"Gitlab status / pipelines are separated","2022-08-12T15:49:41Z","https://github.com/woodpecker-ci/woodpecker/issues/618",0.66497225,{"description":3105,"labels":3106,"number":3109,"owner":3023,"repository":3024,"state":3088,"title":3110,"updated_at":3111,"url":3112,"score":3113},"### Component\r\n\r\nserver, agent, web-ui\r\n\r\n### Describe the bug\r\n\r\nWhen using \".woodpecker/\" directory with a workflow file (myworkflow.yml) inside, the error message: `[generic]pipeline definition not found in company/my-repo` appears (manual run).\r\n\r\nWhen using the same file (myworkflow.yml) in the root directory of the project with name \".woodpecker.yml\", the workflow is found and executed.\r\n\r\nThe documentation states that BitBucket Cloud supports multiple workflows. See [https://woodpecker-ci.org/docs/next/administration/forges/overview](https://woodpecker-ci.org/docs/next/administration/forges/overview)\r\n\r\n### System Info\r\n\r\n```shell\r\nversion\t\"next-d0e63375fa\"\r\n```\r\n\r\n\r\n### Additional context\r\n\r\n```\r\nwoodpecker-server-1 | {\"level\":\"debug\",\"time\":\"2024-04-09T07:06:55Z\",\"caller\":\"/woodpecker/src/github.com/woodpecker-ci/woodpecker/server/router/middleware/session/repo.go:150\",\"message\":\"myuser granted &{UserID:1 RepoID:1 Repo:\u003Cnil> Pull:true Push:true Admin:true Synced:1712646369 Created:1712589724 Updated:1712646369} permission to company/my-repo\"}\r\nwoodpecker-server-1 | {\"level\":\"error\",\"error\":\"Resource not found\",\"repo\":\"company/my-repo\",\"user\":\"myuser\",\"time\":\"2024-04-09T07:06:56Z\",\"caller\":\"/woodpecker/src/github.com/woodpecker-ci/woodpecker/server/services/config/forge.go:152\",\"message\":\"could not get folder from forge\"}\r\nwoodpecker-server-1 | {\"level\":\"error\",\"error\":\"Resource not found\",\"repo\":\"company/my-repo\",\"user\":\"myuser\",\"time\":\"2024-04-09T07:06:57Z\",\"caller\":\"/woodpecker/src/github.com/woodpecker-ci/woodpecker/server/services/config/forge.go:152\",\"message\":\"could not get folder from forge\"}\r\nwoodpecker-server-1 | {\"level\":\"error\",\"error\":\"Resource not found\",\"repo\":\"company/my-repo\",\"user\":\"myuser\",\"time\":\"2024-04-09T07:06:57Z\",\"caller\":\"/woodpecker/src/github.com/woodpecker-ci/woodpecker/server/services/config/forge.go:152\",\"message\":\"could not get folder from forge\"}\r\nwoodpecker-server-1 | {\"level\":\"debug\",\"repo\":\"company/my-repo\",\"error\":\"configFetcher: fallback did not find config: Resource not found\\nNo such file or directory: .woodpecker.yaml\\nNo such file or directory: .woodpecker.yml\",\"time\":\"2024-04-09T07:06:58Z\",\"caller\":\"/woodpecker/src/github.com/woodpecker-ci/woodpecker/server/pipeline/create.go:82\",\"message\":\"error while fetching config '' in 'ci/woodpecker' with user: 'myuser'\"}\r\n```\r\n\r\nWoodpecker-UI: Pipeline Path -> empty (default)\r\n\r\n### Validations\r\n\r\n- [X] Read the [docs](https://woodpecker-ci.org/docs/intro).\r\n- [X] Check that there isn't [already an issue](https://github.com/woodpecker-ci/woodpecker/issues) that reports the same bug to avoid creating a duplicate.\r\n- [X] Checked that the bug isn't fixed in the `next` version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]",[3107,3108],{"name":3020,"color":3021},{"name":3085,"color":3086},3600,"BitBucket Cloud - Pipeline definition not found (when using multiple workflows, manual run)","2024-05-06T07:08:30Z","https://github.com/woodpecker-ci/woodpecker/issues/3600",0.6707594,{"description":3115,"labels":3116,"number":3118,"owner":3023,"repository":3024,"state":3088,"title":3119,"updated_at":3120,"url":3121,"score":3122},"### Component\n\nweb-ui\n\n### Describe the bug\n\nThe pipeline status image (on Woodpecker - returned by API: /api/badges/25/status.svg ) shows ERROR, even that last build is OK:\r\n\r\n\n\n### System Info\n\n```shell\nversion 2.4.1 running on Docker\n```\n\n\n### Additional context\n\n_No response_\n\n### Validations\n\n- [X] Read the [docs](https://woodpecker-ci.org/docs/intro).\n- [X] Check that there isn't [already an issue](https://github.com/woodpecker-ci/woodpecker/issues) that reports the same bug to avoid creating a duplicate.\n- [X] Checked that the bug isn't fixed in the `next` version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]",[3117],{"name":3020,"color":3021},3561,"Pipeline status is error, but last job is OK","2024-04-15T10:15:05Z","https://github.com/woodpecker-ci/woodpecker/issues/3561",0.6724564,["Reactive",3124],{},["Set"],["ShallowReactive",3127],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$fqPpp2Lj6BzTKkQUfqxvRW93R7bWBV0DDIEuC5sSth6A":-1},"/woodpecker-ci/woodpecker/5177"]