\n\nThis id number isn't helpful for viewing, as people don't have the IDs of all their CI runners memorized. It'd be much better to use the agent name (or alias / whatever you tagged it as) instead, and possibly default to the ID if no name is present.\n\n### Suggested solution\n\nUse the agent name / alias instead of an id number for the queue badge.\n\n### Alternative\n\n_No response_\n\n### Additional context\n\n_No response_\n\n### Validations\n\n- [x] Checked that the feature isn't part of the `next` version already [https://woodpecker-ci.org/versions]\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 request the same feature to avoid creating a duplicate.",[3156],{"name":3157,"color":3158},"feature","180DBE",5469,"In the queue list, use the agent name rather than the agent id for the badge.","2025-08-29T18:27:54Z","https://github.com/woodpecker-ci/woodpecker/issues/5469",0.75504,{"description":3165,"labels":3166,"number":3168,"owner":3146,"repository":3147,"state":3148,"title":3169,"updated_at":3170,"url":3171,"score":3172},"### Component\n\nweb-ui\n\n### Describe the bug\n\nWhen there is an error in one of the workflows , the UI does not show which file is causing the error:\r\n\r\nIn this project I have `build.yml` and `release.yml` and the UI gives me that:\r\n\r\n\r\n\r\nThe error was in workflow `release.yml` (which was not triggerd), but not in build.yml.\r\n\r\n\n\n### Steps to reproduce\n\nSchould be obvious\n\n### Expected behavior\n\nIch would like to see, which file / workflow is causing the error.\n\n### System Info\n\n```shell\nWoodpecker 2.7.3 (docker image)\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]",[3167],{"name":3143,"color":3144},4376,"error message in UI does not point to workflow / yaml file","2024-11-14T14:27:25Z","https://github.com/woodpecker-ci/woodpecker/issues/4376",0.7585342,{"description":3174,"labels":3175,"number":3177,"owner":3146,"repository":3147,"state":3148,"title":3178,"updated_at":3179,"url":3180,"score":3181},"### 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]",[3176],{"name":3143,"color":3144},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.7625281,{"description":3183,"labels":3184,"number":3189,"owner":3146,"repository":3147,"state":3148,"title":3190,"updated_at":3191,"url":3192,"score":3193},"### Clear and concise description of the problem\n\nToday (upon the reporting) the owasp NVD data site was down all day, so all our builds stall... and end up with a pipeline timeout at last.\n\n### Suggested solution\n\nFor a step, it would be useful to be able to configure a timeout option, to avoid the pipeline (and jobs in queue) to be blocked (until the entire pipeline timeout is triggered).\nThe status might need to be updated with a \"stepTimeout\" value, or it should be able to configure if the step timeout should trigger/lead to status success or failure.\n\n### Alternative\n\n_No response_\n\n### Additional context\n\n_No response_\n\n### Validations\n\n- [X] Checked that the feature isn't part of the `next` version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]\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 request the same feature to avoid creating a duplicate.",[3185,3186],{"name":3143,"color":3144},{"name":3187,"color":3188},"pipeline-config","1BE540",3557,"Idea: Option for timeout configuration per step","2025-06-02T06:04:23Z","https://github.com/woodpecker-ci/woodpecker/issues/3557",0.76601094,{"description":3195,"labels":3196,"number":3201,"owner":3146,"repository":3147,"state":3148,"title":3202,"updated_at":3203,"url":3204,"score":3205},"add an Admin panel to:\n * [x] see all registered agents #252 \n * [x] see all registered users (add / remove admins) #1634\n * [x] https://github.com/drone/drone-ui/pull/334 -> #1632\n * [x] `/queue/info`\n * [x] pause / resume queue\n * [ ] clear / reset queue and kill all pipelines\n * [ ] `/pipelines`\n * [ ] see resource usage per ... user/repo/org\n * [ ] report pipeline status pushed that failed ... -> user permissions changed etc...\n * [x] orgs list #2307 \n * [x] see all activated repos #2347 \n * [ ] pipeline stats https://github.com/woodpecker-ci/woodpecker/issues/345#issuecomment-1400542018\n * [x] show updates https://github.com/woodpecker-ci/woodpecker/issues/616\n * [ ] search https://github.com/woodpecker-ci/woodpecker/issues/3015\n * [ ] #4807 ",[3197,3198],{"name":3157,"color":3158},{"name":3199,"color":3200},"summary","C3DC73",345,"[Feature] Admin Panel","2025-02-08T07:40:04Z","https://github.com/woodpecker-ci/woodpecker/issues/345",0.76758766,{"description":3207,"labels":3208,"number":3213,"owner":3146,"repository":3147,"state":3214,"title":3215,"updated_at":3216,"url":3217,"score":3218},"Add a button to skip a workflow that is currently waiting for e.g. `depends_on` or agent capacities.",[3209,3210],{"name":3157,"color":3158},{"name":3211,"color":3212},"wontfix","c2e0c6",1354,"closed","Allow to manually skip (waiting) workflows","2023-08-02T11:05:55Z","https://github.com/woodpecker-ci/woodpecker/issues/1354",0.7366904,{"description":3220,"labels":3221,"number":3226,"owner":3146,"repository":3147,"state":3214,"title":3227,"updated_at":3228,"url":3229,"score":3230},"### Clear and concise description of the problem\n\nCurrently there is no way to limit where to limit agents where pipelines without any filter labels specified to run on.\n\n### Suggested solution\n\nAdd configuration option for woodpecker server to set default label filters that would be set for pipelines that has no filter set.\r\n\r\nThis could also be used as alternative to fix #2634\n\n### Alternative\n\nAs workaround this possible be also implemented in external configuration service but that seems not so straightforward and could be harder to implement\n\n### Additional context\n\nGitlab CI implements similar approach to allow for agents to set option that they are allowed to run \"untagged pipelines\"\n\n### Validations\n\n- [X] Checked that the feature isn't part of the `next` version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]\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 request the same feature to avoid creating a duplicate.",[3222,3225],{"name":3223,"color":3224},"server","5D7A92",{"name":3143,"color":3144},4324,"Allow configuration option to specify default filter labels","2024-11-14T21:23:44Z","https://github.com/woodpecker-ci/woodpecker/issues/4324",0.74535847,{"description":3232,"labels":3233,"number":3236,"owner":3146,"repository":3147,"state":3214,"title":3237,"updated_at":3238,"url":3239,"score":3240},"### Clear and concise description of the problem\n\nThe endpoint to fetch pipelines queues currently returns all pipelines regardless of their labels.\r\nThis is problematic for #999 because I would like to be able to create different auto-scaled agent pools.\r\n\n\n### Suggested solution\n\nAdd filters in queues list endpoint by label set so I get a view of only the pipelines my agent pools can handle.\n\n### Alternative\n\nOptional / Nice-to-have: Add an option to label prometheus time series about queues with the same labels.\n\n### Additional context\n\n### Use cases\r\n\r\n#### Different autoscaler agent pool\r\n\r\n*Additional Information*: #999 \r\n\r\nA simple use-case is that I would like to have a pool of Instances (Virtual Machines) for `Docker` backend runners that use a pre-built docker image and just start the agent with the good parameters, the first start would be a *cold boot* because the volume would need to be initiated etc but the instance would be powered-off and re-spinned when needed with the same volume (*hot boot*).\r\n\r\nAnother pool for the `Local` backend runners would recreate (*cold boot*) a complete VM at each runs for cases where containers are not fitting and we want to run directly inside a VM.\r\n\r\nFinally, I would use Cloud Providers' managed Kubernetes for the `Kubernetes` backend and fine-tunes the settings for Woodpecker.\r\nIf I take @scaleway as an example, we have [Kapsule](https://www.scaleway.com/en/kubernetes-kapsule/) and it would be really easy to auto-scale the cluster horizontally by adding nodes as the number of container / the average per node CPU / memory starts to saturate.\r\n\r\nBut to make that work well I need to be able to get queues status per label `backend` so it auto-scales based on the right metrics (the queue length of the respective backends)\n\n### Validations\n\n- [X] Checked that the feature isn't part of the `next` version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]\n- [X] Read the [Contributing Guidelines](https://github.com/woodpecker-ci/woodpecker/blob/main/CONTRIBUTING.md).\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 request the same feature to avoid creating a duplicate.",[3234,3235],{"name":3223,"color":3224},{"name":3143,"color":3144},2803,"Per-labelset queues","2024-06-24T21:59:20Z","https://github.com/woodpecker-ci/woodpecker/issues/2803",0.75044423,{"description":3242,"labels":3243,"number":3245,"owner":3146,"repository":3147,"state":3214,"title":3246,"updated_at":3247,"url":3248,"score":3249},"workaround could be done with set a \"custom\" platform, but since #690 it's autodetected ...\r\n\r\nthe idea is to use the \"agent labels\" as filter but they do not work?\r\n\r\nhttps://github.com/woodpecker-ci/woodpecker/blob/2f91bdd4a0f5167ef304c220865141c15f2dd563/cmd/agent/agent.go#L39-L44 ...",[3244],{"name":3157,"color":3158},740,"Pin a pipeline to an specific agent","2022-06-16T12:14:06Z","https://github.com/woodpecker-ci/woodpecker/issues/740",0.7539896,["Reactive",3251],{},["Set"],["ShallowReactive",3254],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$fIigynLCrfij7YAkqP_qwaeLrPyxgHNxXamHNxzOwivM":-1},"/woodpecker-ci/woodpecker/4392"]