Uploaded image for project: 'Bamboo Data Center'
  1. Bamboo Data Center
  2. BAM-3155

Build Configuration | Builder | Test Result Directory not persisted for Bash (Command type)

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Medium Medium
    • 2.2
    • 2.1.2, 2.1.3
    • None

      When specifying an Test Result directory other than */tesr-results/ this directory is not persisted when returning to the edit mask - */tesr-results/ appears again in the field.
      I have found that the value entered is written to the database but not correctly loaded.

            [BAM-3155] Build Configuration | Builder | Test Result Directory not persisted for Bash (Command type)

            Ulrich, please again check if it works. Cheers,
            Lucas

            Lucas Guminski [Atlassian] added a comment - Ulrich, please again check if it works. Cheers, Lucas

            MarkC added a comment -

            setting up a test results dirtectory is a common feature of all builders

            The test results directory itself is common to all builders. However, the code that was pulled up was for custom vs standard locations for the location. This only applies for Maven repositories. Have a look in the UI, only Maven has the second level of selection available.

            I think the root cause has been mis diagnosed. Looking at it briefly, the problem seems to be that:

                public void addDefaultValues(@NotNull BuildConfiguration configuration)
            

            is called when a plan is edited. My theory (needs confirmation) is that the com.atlassian.bamboo.plugin.builder.nant.CustomDotNetCommandBuilder which we now bundle overwrites the property that the CustomCommandBuilder uses. So whenever we edit, the value gets overriden.

            MarkC added a comment - setting up a test results dirtectory is a common feature of all builders The test results directory itself is common to all builders. However, the code that was pulled up was for custom vs standard locations for the location. This only applies for Maven repositories. Have a look in the UI, only Maven has the second level of selection available. I think the root cause has been mis diagnosed. Looking at it briefly, the problem seems to be that: public void addDefaultValues(@NotNull BuildConfiguration configuration) is called when a plan is edited. My theory (needs confirmation) is that the com.atlassian.bamboo.plugin.builder.nant.CustomDotNetCommandBuilder which we now bundle overwrites the property that the CustomCommandBuilder uses. So whenever we edit, the value gets overriden.

            Mark, I have updated all the builders, because setting up a test results dirtectory is a common feature of all builders. So I have extracted it to AbstractBuilder in order to avoid problems that for one builder it works, and for other it does not. But as a result of this approach all builders have been touched. If you want me to apply minimalistic approach, and fix only this builder, I'm ready to do so.

            Lucas Guminski [Atlassian] added a comment - Mark, I have updated all the builders, because setting up a test results dirtectory is a common feature of all builders. So I have extracted it to AbstractBuilder in order to avoid problems that for one builder it works, and for other it does not. But as a result of this approach all builders have been touched. If you want me to apply minimalistic approach, and fix only this builder, I'm ready to do so.

            MarkC added a comment -

            OKay I had a bit of a better look. I think the problem is to do with the interaction of the DotNet Command builder overriding the defaults for the CustomCommandBuilder rather than any general problem with the other builders themselves.

            MarkC added a comment - OKay I had a bit of a better look. I think the problem is to do with the interaction of the DotNet Command builder overriding the defaults for the CustomCommandBuilder rather than any general problem with the other builders themselves.

            MarkC added a comment -

            Guys I'm just checking this on branch (without the fix). This problem only applies to the Custom Command type. Why are we updating all of the builders? I don't think the fix needs to apply to them?

            MarkC added a comment - Guys I'm just checking this on branch (without the fix). This problem only applies to the Custom Command type. Why are we updating all of the builders? I don't think the fix needs to apply to them?

            Ulrich,

            would you be so kind and could you test if it works now? I have committed to trunk a change which should solve this problem, but I need your confirmation before closing the ticket. Cheers,
            Lucas

            Lucas Guminski [Atlassian] added a comment - Ulrich, would you be so kind and could you test if it works now? I have committed to trunk a change which should solve this problem, but I need your confirmation before closing the ticket. Cheers, Lucas

            There is still some problem with this, but unfortunately it has to wait for me till Monday.

            Lucas Guminski [Atlassian] added a comment - There is still some problem with this, but unfortunately it has to wait for me till Monday.

            Actually the problem affected all builders except for Maven. Now it works.

            Lucas Guminski [Atlassian] added a comment - Actually the problem affected all builders except for Maven. Now it works.

              lguminski Lucas Guminski [Atlassian]
              ukuhnhardt Ulrich Kuhnhardt [Atlassian]
              Affected customers:
              0 This affects my team
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: