Issue #13737 resolved
Carl Jira created an issue

To avoid having to duplicate a lot of custom pipeline configurations it would be great to be able to specify parameters that has to be provided when manually triggering a custom build.

A common example would be deployment to different environment where the pipeline script is identical for every environment except for a few variables that change. As it stands I have to create multiple custom pipelines to manage these environments rather than just creating one and specify parameters that are passed to the pipeline.

It should be possible to specify parameter definitions on Team and Repository level, just like environment variables. You then specify in your pipeline which parameters can be set, which are required etc. Default values should be overridable in the pipeline configuration.

Support for at least text and select list parameters should be possible.

For reference, TeamCity has a pretty good way of handling parameters that might serve as inspiration.

Official response

Comments (61)

  1. Matt Ryall

    Thanks for the suggestion. We don't have any immediate plans to do this, but we'll keep this issue open to track votes and customer interest.

  2. Matt Ryall

    Thanks for the interest in Pipelines and this feature request.

    At the moment, we don't have plans to implement parameterised builds exactly as described here, however we are planning future work in two areas related to this ticket which you might want to follow:

    • Issues #12750 and #12751 will deliver multiple, reusable steps that can be parameterised within the YAML file (not via the UI)
    • Issue #12844 covers deployments, including manual steps for deployments to particular environments

    I think the changes we are now starting to plan in these two areas will cover 80% of this request, which is about reducing duplication around deployment configuration. We don't have a specific timeline for these changes at the moment, so I'd suggest watching these issues to stay updated.

    We will still keep this ticket open as parameterised builds are a specific feature (also offered by other tools) and I'm sure some customers will still want them even after we do the above. We'll reevaluate this ticket again at that point.

  3. Matt Ryall

    Reviewed 23 Feb 2018. Leaving issue open.

    This issue is not on our short term roadmap because we're busy with other more highly voted items (including the ones mentioned in my comment above), but given the duplicate requests that keep appearing for this feature, we'll keep it in consideration for later this year.

  4. Florin Iacob

    Guys, any update on this one ?

    just to note that would a VERY VERY VERY important improvement, as in combination with manual triggers it would allow for pipeline branching and multi-fuctional steps, for example: performing a rollback in a post-release step by providing a flag, or a deploy to multiple environments by providing an environment list, and lots of other things one could think of.

  5. Grant Mills

    I could really use this feature also, rather than drive my pipelines scripts via hundreds of environment variables.

  6. Danny Sievers

    This would be extremely useful for our organization as well. Looking forward to updates on the issue!

  7. Marcus Schumann

    Wouldn't this be covered with the upcoming "Tasks" feature? It allows for creating account wide tasks and lets you pass in parameters to the task for configuration.

  8. Adam Long

    We would also like to see this feature, currently we are using some work arounds with git tag conventions but thats far from ideal.

  9. Vili Forsell

    Personally, manual input from bitbucket UI could be really good, since it would allow f.ex. creating a release -pipeline that has its version bump given by the user... after all, it's pretty lame to have to expect a (possibly) manager level person be interested in pulling the repository and running manual scripts for stuff like that, doing manual commits, and only then see the pipeline get up and running.

    I'm not 100% sure about the ideal workflow, but it could be something like pressing one button like "Create Branch" with release -branch name, which triggers release pipeline, and the pipeline requests the version number to truly start/continue (f.ex. during a manual trigger). Of course, even this has too many steps to it and is pretty hard for people not interested in development at all to get intuitively!

    Then, every commit afterwards will also trigger this pipeline and require the version number to change, since each fix on release ought imo increase the fix version (but not the major or minor versions).

    Right now, quite frankly, every inconvenient script I have to write and extra tool I have to use to patch things up to make the CI/CD work, and every convention I have to teach the developers and other users, diminishes the value of the whole CI/CD system, which is my justification for why figuring out a fluent and very trivial way to do version bumping out-of-the-box would be in your interests. ;)

    Oh, and creating loads of extra branches for everything doesn't feel like the ideal course to me, which seems to be the trend with the non-conventional test, staging and production branches that match to test, staging and production pipelines, and test, staging and production remote environments. Those bring a large learning curve to the whole development team just to do their daily job. I don't think developers, managers etc. want to think about or remember any tricks they should do to get the CI/CD work.

  10. Roman Mikhailov

    @viliforsell described a valid case that happens way too often. There's always be the need to manually trigger a pipeline with overwriting parameters.

  11. Sam Zakkour

    bump, this is a requirement for a client I'm currently consulting for. This feature is available in Bamboo, no reason for it to be missing here.

  12. Chandana De Silva

    I see that there are 169 votes for this. How man votes will it take to get this prioritised ?

  13. Nicolas Marchildon

    I have the feeling that this might please many, but looking deeper at the actual use-cases may lead to better solutions that doesn't bloat Bitbucket into an unmanageable mess of "tasks".

    For example, bumping a version number by punching it in sounds great on surface because managers like to control when a release is made, but that manager still lacks a tool to list these versions. Bitbucket could provide such user interface. Arguably, right now, a good user experience may involve building a service that integrates with Bitbucket, and it's already possible to push version bumps through git from such a tool.

  14. Carl Nordenfelt

    I wouldn't use it for something remotely close to a version bump, rather static parameters to easily be able to reuse pipelines for similar but slightly different purposes.

    That said, a long time has passed since I created this ticket and a lot has happened on BitBucket, mainly Deployments has happened. Since their launch, I haven't regarded the lack or build parameters that big of a problem.

  15. Tomas Gutierrez

    Out team has migrated recently to pipelines builds and as developers we do really miss the feature to parametrize the builds from the user interface without adding a crazy amount of YAML tasks. So, we are upvoting this.

  16. Adam Long

    Our team has a use-case for build parameters. We build Docker images for non-prod environments and deploy to Kubernetes via Helm - each code commit/merge to master produces unique Docker image tags based on the code commit. A container image in a UAT environment passing tests is a sign off required for an image to be promoted to runtime (production) - at this point we don't want to run a pipeline to build a new image, we want to promote the exact same image to the container runtime cluster (which we do with Skopeo in Pipelines) and deploy via Helm. The runtime environment has a separate pipeline and acts as a release management for production. This scenario means we have pipelines where code doesn't change but parameter inputs change. For example, promote project Docker image with tag "1.2-68-g1b61bd4" from cluster 1 in namespace A to namespace B in cluster 2 and deploy with chart name. If Pipelines had parameters these builds would be able to handle multi-tenancy, multi-project clusters where you have some input changes (not code changes) and the pipeline is repeatable. Our use-case work around is with Git tags and cutting up the tag via compatible delimiters to simulate parameters. We can keep using delimited tags but build parameters would be more powerful.

  17. Tomas Gutierrez

    @nicolusgrade Hello Nicolas, thank you for your interest. We were using Jenkins for the past years and our development pipeline is still in transition to continuos integration.

    Anyways, I would like to mention some of our use cases:

    • We have Android applications which we compile in release or debug mode with the same code. They also whitelist different domains and slightly change their names and icons when we are targeting different clients, but the code is unified.

    • We have more that 40 microservices in the same repository and most of the time we wish to build a single one.

    • Sometimes we wish to disable the unit tests at build time for development environments. Not the best practice but could save us some time.

    • Sometimes we don't need or want to run database migrations. So it would be nice to be able to disable them too.

    • Our system can run in plain virtualized Java environment but also supports Kubernetes, the code is the same but the builds are slightly different.

    Most of them can be solved by picking a boolean value, but others would require to select something from a list. The problem is when we combine multiple parameters, the amount of YAML tasks grow very quickly. Currently there are 15 tasks for the microservices repository and we are planning to create more in order to build a single service at a time.

  18. Luiz Tavares

    Happy Two years Birthday, My favorite feature request.

    Now seriously, We would love to use some sort of user-provided input: That would allow us to configure/require TOTP 2FA secrets before stuff actually gets pushed to production.

    Are there any know workarounds for this scenario, except for "Skip the MFA verification"? Thanks

  19. Aneita Yang staff

    Hi everyone,

    Thanks for all of your interest on seeing this feature and for your patience.

    I'd love to speak with a few customers to better understand your requirements and what you'd like to see from this feature. If you're interested in providing feedback, please reach out to us at pipelines-feedback@atlassian.com and include which timezone you're in, and we can schedule a quick 30 minute chat.

    Thanks,
    Aneita

  20. Luiz Tavares

    Our primary usage scenario for this feature would be to allow the pipeline users to provide two-factor authentication details.

  21. Fabian Bahle

    We could also make use of this feature, e.g. I think it could be handy to pass the next stable version and the next snapshot version into a release pipeline or if you have a multimodule project you could specify only one module which should be build and deployed for faster deployment. I really hope you're going to implement this feature soon.

    Regards, Fabian

  22. Matthew Bill

    I would like to see this feature added. My use case is that we have multiple teams, each with their own environment. I need to allow anyone/team to be able to deploy a component and point it to the database for their environment. I don't know in advance how many possible environments need to be created, so I need to define the parameter at the point of the manual step (deploy).

    At the moment we have to stick with Jenkins to allow the above. The moment this is in bitbucket pipelines we will switch.

  23. Linh Vu

    This feature will be really useful for us because we aim to support deploying to multiple environments.

  24. Adil El Kanabi

    same here, we deploy to multiple Envs, ce can't consume a step for each env to deploy as we only have 10

  25. Andreas Neumann

    Please add, this could remove a lot of configuration duplication in the bitbucket-pipelines.yml and improve our security by not having to give every developer access to the pipeline project settings to change deplyoment related variables.

  26. Bryce Filho

    My group could use this, as well. We need to run different scripts each build based on what tasks were accomplished in the sprint.

  27. Marcel Arns

    Thanks so much @aneita

    Additionally it could be very useful to specify a drop-down menu with default values.

    pipelines:
      custom:
        custom-deployment:
          - variables:
              - name: showroom
                defaults:
                  - showroom-1
                  - showroom-2
                  - showroom-3
          - step: 
              script:
                - echo "Deploy to $showroom"
    
  28. Mark Studer

    Thanks @aneita . Also, I appreciate the team updating the API documentation, I saw the updated documentation yesterday and implemented the new feature in one of our custom pipes.

  29. Tat Chiu Leung

    I would like to see parameterized build feature in Bitbucket pipelines as well. Although I always opt for fully automated builds without manually entered parameters, but in the case it requires manual input, prompting for parameters on demand would be useful.

  30. Matthew Bill

    Thanks @Steven Vaccarella . I have signed up for the Alpha group, but we haven’t been added to it. I hope it comes through soon.

    Thank you for pointing that out. This is such a game changer for us, we will be able to move off Jenkins now.

    In case anyone is interested in our use case, we plan to do the following:

    • Having builds on default/branches, which does the CI, tests, etc and then packages the code (container, zipped up lambda to s3, etc). We label that code with the commit hash.
    • Custom builds for the different environments i.e. “Deploy to Production”, which we can launch from any commit or branch, as it just pulls out the commit hash of knowing where to get the packaged deployment (container, s3 file, etc). Then when we deploy the code, we will have the user specified parameters at time of build, to determine environment details like which database to point to. It means we will be able to deploy the same code, many different times to different environments and roll back to any version of the code too. Thank you Bitbucket!
  31. Sondre Lefsaker

    @Steven Vaccarella So it seams like the variables can only be configured for manual pipelines, is that correct? What about manual steps?

    Let’s say I have an automatic pipeline that runs on the master branch with two steps: “Build” and “Deploy”, where only the deployment step is manual. This is where it’s beneficial to specify variables, should I choose to deploy an already built package, I would also need to specify things like environments, version numbers, etc.

  32. Log in to comment