\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]",[3047],{"name":3037,"color":3038},5338,"Build status not completing on matrix pipelines with BitBucket","2025-07-17T18:03:12Z","https://github.com/woodpecker-ci/woodpecker/issues/5338",0.75700116,{"description":3054,"labels":3055,"number":3059,"owner":3026,"repository":3027,"state":3028,"title":3060,"updated_at":3061,"url":3062,"score":3063},"### Clear and concise description of the problem\n\nIt would be nice if we could define all our pipelines in a single .woodpecker.yaml file, instead of resorting to holding multiple pipelines in individual files in a dedicated folder. YAML syntax allows for multiple documents to be contained in a single stream by separating them with '---' (triple hyphens). Woodpecker currently doesn't utilized this feature when loading pipelines, since it's the file URI that is passed to - for example - 'genItemForWorkflow' that produces a single item from a single file, even if that file contains multiple documents.\n\n### Suggested solution\n\nAllow for including multiple YAML documents within a single file.\n\nThis would require a change in some interfaces that currently take a file URI and pass it down to be processed by specialized functions first and extracting a list of YAML documents.\n\n### Alternative\n\n_No response_\n\n### Additional context\n\nHere are two relevant links to YAML official specification\n[2.2 Structures](https://yaml.org/spec/1.0/#id2489959)\n[4.3.1 Document](https://yaml.org/spec/1.0/#id2561718)\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.",[3056],{"name":3057,"color":3058},"feature","180DBE",4821,"Allow loading multiple yaml documents from a single file","2025-02-08T00:04:37Z","https://github.com/woodpecker-ci/woodpecker/issues/4821",0.76722455,{"description":3065,"labels":3066,"number":3071,"owner":3026,"repository":3027,"state":3028,"title":3072,"updated_at":3073,"url":3074,"score":3075},"### 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.",[3067,3068],{"name":3023,"color":3024},{"name":3069,"color":3070},"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.76872694,{"description":3077,"labels":3078,"number":3082,"owner":3026,"repository":3027,"state":3028,"title":3083,"updated_at":3084,"url":3085,"score":3086},"1. yaml deserialized of matrix values\r\n2. matrix mutation\r\n3. envvar replacement (metadata env of workflow + matrix env if exist)\r\n4. yaml deserializion of workflow conf\r\n5. workflow filter check\r\n6. ...\r\n\r\nX. Backend workflow is passed to the agent\r\nX. Backend parse backend specific configs\r\nX. Workflow is executed by specific backend engine",[3079],{"name":3080,"color":3081},"documentation","7D625D",3365,"Document how the workflow is parsed","2024-02-10T08:28:37Z","https://github.com/woodpecker-ci/woodpecker/issues/3365",0.7709086,{"description":3088,"labels":3089,"number":3091,"owner":3026,"repository":3027,"state":3092,"title":3093,"updated_at":3094,"url":3095,"score":3096},"### Clear and concise description of the problem\n\nAs a user of Woodpecker I want to be able to have one place in my repository where my list of supported compiler versions is written down, and have a woodpecker workflow to generate a matrix of jobs based on it. \r\n\r\nI developed the [get-tested](https://github.com/Kleidukos/get-tested) tool for the Haskell ecosystem because we have a way to declare the tested versions of the compiler as metadata of the package file. \r\n\r\n\u003Cdetails>\r\n\u003Csummary>See\u003C/summary>\r\n\r\nhttps://flora.pm/packages/@haskell/text\r\n\r\n\r\n\u003C/details>\r\n\r\nThis enables us to keep this list of tested compiler versions in one place, thus avoiding de-synchronisation problems between what we declare as tested and what is actually tested.\n\n### Suggested solution\n\nMuch like how GitHub does it, a well-defined JSON object format could be generated by one job on which another depends and reads from. This JSON object would mimick the YAML format:\r\n\r\n```\r\nmatrix={\"include\":[{\"ghc\":\"9.10.1\",\"os\":\"ubuntu-latest\"}]}\r\n```\r\n\r\nWith ideally the addition of an `exclude` property that would prevent a combination of values from being run.\r\n\r\nMain inspiration is https://docs.github.com/en/actions/using-jobs/using-a-matrix-for-your-jobs\n\n### Alternative\n\nMaintaining multiple lists of supported compiler versions (one for package metadata, one for CI), which is prone to error and de-synchronisation. \n\n### Additional context\n\nThe link of the first checkbox (https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use) returns a 404.\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.",[3090],{"name":3057,"color":3058},3873,"closed","Dynamically-defined matrix workflows","2024-07-06T08:14:14Z","https://github.com/woodpecker-ci/woodpecker/issues/3873",0.67463034,{"description":3098,"labels":3099,"number":3101,"owner":3026,"repository":3027,"state":3092,"title":3102,"updated_at":3103,"url":3104,"score":3105},"### Component\n\nserver\n\n### Describe the bug\n\nOne cannot use a filtered step in the depends_on clause. If you try it, the linter rejects the configuration\r\n\r\n\r\nThis prohibits the combination of parallel steps and optional steps in the same pipeline.\r\n\r\nMinimal reproducer:\r\n```\r\nsteps:\r\n - name: filtered\r\n image: alpine\r\n commands:\r\n - echo \"step 1\"\r\n when:\r\n branch:\r\n - xyz\r\n\r\n - name: unconditional\r\n image: alpine\r\n commands:\r\n - echo \"step 2\"\r\n depends_on:\r\n - filtered\r\n```\n\n### System Info\n\n```shell\nVersion 2.2.2\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]",[3100],{"name":3037,"color":3038},3278,"Filtered steps and depends_on (step)","2024-01-25T17:22:40Z","https://github.com/woodpecker-ci/woodpecker/issues/3278",0.7440327,{"description":3107,"labels":3108,"number":3113,"owner":3026,"repository":3027,"state":3092,"title":3114,"updated_at":3115,"url":3116,"score":3117},"### Component\n\nserver\n\n### Describe the bug\n\nConsider following `.woodpecker.yml`:\r\n```yaml\r\nvariables:\r\n - &my_testing_var1 'first value'\r\n\r\nmatrix:\r\n MY_MATRIX_ENV:\r\n - aaa\r\n - bbb\r\n\r\nsteps:\r\n - name: test-env\r\n image: busybox\r\n environment:\r\n MY_TESTING_VAR1: *my_testing_var1\r\n MY_TESTING_VAR2: \"second value\"\r\n commands:\r\n - |\r\n echo \"$${MY_MATRIX_ENV:?}\"\r\n echo \"$${MY_TESTING_VAR1:?}\"\r\n echo \"$${MY_TESTING_VAR2:?}\"\r\n```\r\n\r\nExpected output (e.g. with `MY_MATRIX_ENV=aaa`):\r\n```\r\naaa\r\nfirst value\r\nsecond value\r\n```\r\n\r\nActual output (e.g. with `MY_MATRIX_ENV=aaa`):\r\n```\r\naaa\r\nsh: MY_TESTING_VAR1: parameter not set or null\r\n```\r\n\r\nHowever, I've detected that it sets provided variables in following manner:\r\n```sh\r\nPLUGIN_MY_TESTING_VAR1=\"first value\"\r\nPLUGIN_MY_TESTING_VAR2=\"second value\"\r\n```\n\n### System Info\n\n```shell\ndocker.io/woodpeckerci/woodpecker-server:next-5b0430ab4a\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]",[3109,3110],{"name":3037,"color":3038},{"name":3111,"color":3112},"regression","7E192B",3436,"matrix workflows set up environment in wrong way","2024-02-25T09:12:41Z","https://github.com/woodpecker-ci/woodpecker/issues/3436",0.75558853,{"description":3119,"labels":3120,"number":3124,"owner":3026,"repository":3027,"state":3092,"title":3125,"updated_at":3126,"url":3127,"score":3128},"### Clear and concise description of the problem\n\nMany projects use some .env (or .dev.env, .prod.env, etc) files for managing variables.\r\nIt would be nice if woodpecker would support importing these variables directly into steps.\n\n### Suggested solution\n\nProposed syntax (same as docker compose)\r\n```yaml\r\n\r\npipeline:\r\n some_step:\r\n image: some-image\r\n commands:\r\n - do something\r\n env_file: .env\r\n\r\n some_plugin_step:\r\n image: my-build-plugin\r\n settings:\r\n foo: bar\r\n env_file:\r\n - .build.env\r\n - .env\r\n```\n\n### Alternative\n\n_No response_\n\n### Additional context\n\n_No response_\n\n### Validations\n\n- [X] Read the [Contributing Guidelines](https://github.com/woodpecker-ci/woodpecker/blob/master/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.",[3121],{"name":3122,"color":3123},"feedback","4B7070",1348,"Add support to import env file in pipeline steps","2022-10-27T13:26:05Z","https://github.com/woodpecker-ci/woodpecker/issues/1348",0.7592149,["Reactive",3130],{},["Set"],["ShallowReactive",3133],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$frDBfhkMOgQnA9IDVmpTzqMRZw9Pzb_I656kbc3ZR4fc":-1},"/woodpecker-ci/woodpecker/3992"]