• Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      One of the only reasons I am still using TravisCI in several of my projects is that I can encode the build configuration in the project (config as code).

      If bamboo supported a .bamboo.yaml (or json, xml, whatever). I would have no reason to use any other product.

          Form Name

            [BAM-15087] .travis.yml style build configuration

            Seems like this lost priority in Atlassian as there are important features (available in UI) missing making this YAML implementation useless or at least primitive. Additionally branching was expected to work, but still not there.

            All of these have low level prio and handful of votes, whereas this ticket had 150 votes.
            ======================
            BAM-19747 Add Final Task to Bamboo YAML Specs – otherwise test result parsing is not working without hacks around exit values
            BAM-19858 Define Triggers/Variables using YAML Specs
            BAM-19756 Using YAML Specs to create a manual stage
            BAM-19723 Schedule trigger in yaml spec – duplicate of BAM-19747
            BAM-19714 Bamboo YAML Specs should be evaluated prior to the build (when using older sha for build, yaml is not re-evaluated)
            BAM-19686 Allow stage name and job name to be configured in YAML specs
            No option like a "Clean working directory after each build" breaks build by keeping all artifacts, etc.

            Can someone share whether we can expect something this year in this?

            Eduard Babayan added a comment - Seems like this lost priority in Atlassian as there are important features (available in UI) missing making this YAML implementation useless or at least primitive. Additionally branching was expected to work, but still not there. All of these have low level prio and handful of votes, whereas this ticket had 150 votes. ====================== BAM-19747 Add Final Task to Bamboo YAML Specs – otherwise test result parsing is not working without hacks around exit values BAM-19858 Define Triggers/Variables using YAML Specs BAM-19756 Using YAML Specs to create a manual stage BAM-19723 Schedule trigger in yaml spec – duplicate of BAM-19747 BAM-19714 Bamboo YAML Specs should be evaluated prior to the build (when using older sha for build, yaml is not re-evaluated) BAM-19686 Allow stage name and job name to be configured in YAML specs No option like a "Clean working directory after each build" breaks build by keeping all artifacts, etc. Can someone share whether we can expect something this year in this?

            @Ben indeed, and this is why we developed a Bamboo custom task plugin able to run jobs using Docker on its own, based on a yaml file included in the project repo. Like Travis and co. We're obviously interested in what Atlassian does because maintaining our own solution is costly.

            Philippe Elsass added a comment - @Ben indeed, and this is why we developed a Bamboo custom task plugin able to run jobs using Docker on its own, based on a yaml file included in the project repo. Like Travis and co. We're obviously interested in what Atlassian does because maintaining our own solution is costly.

            Ben Crouse added a comment -

            @Philippe we experienced a similar prob, if I understand you correctly. I'll summarize as "the build isn't what you have defined in your YML file at any given commit/branch. The YML file is simply an additional way to create plans in bamboo".

            The ticket opened for this is https://jira.atlassian.com/browse/BAM-19620 but I'm not sure that fully expresses what I'm interested in.

            Ben Crouse added a comment - @Philippe we experienced a similar prob, if I understand you correctly. I'll summarize as "the build isn't what you have defined in your YML file at any given commit/branch. The YML file is simply an additional way to create plans in bamboo". The ticket opened for this is https://jira.atlassian.com/browse/BAM-19620  but I'm not sure that fully expresses what I'm interested in.

            It seems to be the same limitation as the usual Bamboo plans - I haven't really tried to use them so from what I see it's a way to generate the plans in a way that can be better tracked and rolled-back if needed.

             

            Philippe Elsass added a comment - It seems to be the same limitation as the usual Bamboo plans - I haven't really tried to use them so from what I see it's a way to generate the plans in a way that can be better tracked and rolled-back if needed.  

            @Philippe, We haven't started yet, so I am trying to understand all possible shortcomings. Can you please explain more how is this problem different from usual Bamboo plans (they still change right?). 

            Eduard Babayan added a comment - @Philippe, We haven't started yet, so I am trying to understand all possible shortcomings. Can you please explain more how is this problem different from usual Bamboo plans (they still change right?). 

            Our biggest problem with Bamboo and Specs is that plan configuration and project code are disconnected - I can't rebuild a project from 6 months ago with the job configuration from 6 months ago. Only solution seem to keep and clone plans so it we change the jobs we can still rebuild previous versions of the software.

            Philippe Elsass added a comment - Our biggest problem with Bamboo and Specs is that plan configuration and project code are disconnected - I can't rebuild a project from 6 months ago with the job configuration from 6 months ago. Only solution seem to keep and clone plans so it we change the jobs we can still rebuild previous versions of the software.

            @mmiara, Thank you for your work and documentation. Indeed I used both the "reference" and confluence docs including tutorial) and problems listed already.  

            To add to that, this is a type of features making customer look elsewhere (see the name of this issue ). Its is not clear also whtehr pipelines are coming to server. So Atlassian (or doc writers, or POs) needs to be clear on what exactly is different/missing from normal GUI (including unnamed stages, lack of variables, immutable defaults, injecting vars, etc.). Even better to have a public at least general plan on how this is going to be resolved. This is important and lack of this makes it very uncertain whether to use YAML or not. We have ~1000 plans written in at least 10 different ways using all possible bamboo features, plugins, etc. It is really hard using this docs to get the idea on what exactly will be possible to convert to YAML. And no one will really want to jump in just to find out later (the hard way) that this will not work as we want.

             

            Eduard Babayan added a comment - @ mmiara , Thank you for your work and documentation. Indeed I used both the "reference" and confluence docs including tutorial) and problems listed already.   To add to that, this is a type of features making customer look elsewhere (see the name of this issue ). Its is not clear also whtehr pipelines are coming to server. So Atlassian (or doc writers, or POs) needs to be clear on what exactly is different/missing from normal GUI (including unnamed stages, lack of variables, immutable defaults, injecting vars, etc.). Even better to have a public at least general plan on how this is going to be resolved. This is important and lack of this makes it very uncertain whether to use YAML or not. We have ~1000 plans written in at least 10 different ways using all possible bamboo features, plugins, etc. It is really hard using this docs to get the idea on what exactly will be possible to convert to YAML. And no one will really want to jump in just to find out later (the hard way) that this will not work as we want.  

            Thanks @Mateusz, the 2 docs seem to cover different aspects of the feature but essentially focus on describing the yaml format. This is a good thing and both docs should be more easily discoverable and/or combined.

            Still, major aspects like "you need to allow your repository to scan for Bamboo Specs" or "Linked repository needs to have permissions to create plans within given project in order to process YAML definition and create a plan." are evacuated in one phrase while in itself would be worth much more information, and some screenshots.

            Philippe Elsass added a comment - Thanks @Mateusz, the 2 docs seem to cover different aspects of the feature but essentially focus on describing the yaml format. This is a good thing and both docs should be more easily discoverable and/or combined. Still, major aspects like "you need to allow your repository to scan for Bamboo Specs" or " Linked repository needs to have permissions to create plans within given project in order to process YAML definition and create a plan." are evacuated in one phrase while in itself would be worth much more information, and some screenshots.

            Hi @Mateusz Miara, first of all thank you for your work. Regarding the Confluence documentation you talk about i see that several configuration parameters are set as default with no possibility to change them (such as artifact sharing). Will this be the final behaviour or are we going to be able to change them?

             

            On another note, will we be able to use YAML specs on plugin defined tasks? If this is affirmative, how can we know what are the different parameters to all of the tasks?

             

            Please excuse my poor english, and again thanks for your time!

            Marcos Cela López added a comment - Hi @Mateusz Miara, first of all thank you for your work. Regarding the Confluence documentation you talk about i see that several configuration parameters are set as default with no possibility to change them (such as artifact sharing). Will this be the final behaviour or are we going to be able to change them?   On another note, will we be able to use YAML specs on plugin defined tasks? If this is affirmative, how can we know what are the different parameters to all of the tasks?   Please excuse my poor english, and again thanks for your time!

            philippe.elsass1160489443 eduardbabayan Thank you for your feedback regarding Bamboo Specs and documentation. I'm a technical writer behind the Bamboo docs and I'm looking into ways to make sure that you're getting full documentation support (right content in the right place). We're investigating different ways of improving part of the documentation related to Bamboo Specs right now. 

            Based on your comments I can see that you've been referring to our Bamboo Specs Reference documentation here:  https://docs.atlassian.com/bamboo-specs-docs/6.3.0/specs-yaml.html#introduction

            May I ask you, have you also tried using documentation from confluence.atlassian.com/bamboo?

            Regards,

            Mateusz

             

            Mateusz Miara (Inactive) added a comment - philippe.elsass1160489443 eduardbabayan Thank you for your feedback regarding Bamboo Specs and documentation. I'm a technical writer behind the Bamboo docs and I'm looking into ways to make sure that you're getting full documentation support (right content in the right place). We're investigating different ways of improving part of the documentation related to Bamboo Specs right now.  Based on your comments I can see that you've been referring to our Bamboo Specs Reference documentation here:   https://docs.atlassian.com/bamboo-specs-docs/6.3.0/specs-yaml.html#introduction May I ask you, have you also tried using documentation from confluence.atlassian.com/bamboo ? Regards, Mateusz  

              Unassigned Unassigned
              a815feccb5e3 Steve Skrla
              Votes:
              155 Vote for this issue
              Watchers:
              142 Start watching this issue

                Created:
                Updated:
                Resolved: