Artifact dependency points to non existing build configuration

[Logerfo]

Code

project {
   sequence {
      parallel {
         sequence {
            build(Restore) {
               produces("**/*")
            }
            build(Build) {
               requires(Restore, "**/*")
            }
         }
         sequence {
            //...
         }
      }
   }
}

object Restore : BuildType({
   name = "Restore"
   steps {
      msBuild {
         //...
      }
   }
})

object Build : BuildType({
   name = "Build"
   steps {
      msBuild {
         //...
      }
   }
})

Error

Artifact dependency points to non existing build configuration with external id: _Restore

It actually prints twice in a row, I don't know why.

Solution attemps

I tried changing the build id:

object Restore : BuildType({
   id = "<PROJECT_ID>"
   name = "Restore"
})

But the error changed to:

Artifact dependency points to non existing build configuration with external id: __Restore

[antonarhipov]

@Logerfo do you have a full source of this configuration somewhere? Which TeamCity version do you use? I couldn't reproduce it with this code sample on 2019.1.x

[Logerfo]

I don't, it's a private project. I can try to reproduce it to a minimum configuration... I'm currently using TeamCity Professional 2019.1.2 (build 66342).

[antonarhipov]

OK, good, we are on the same TeamCity version. Please, if you can reproduce the issue with the minimal configuration that would help a lot.

[Logerfo]

Check out https://github.com/Logerfo/pipeline-test

[Logerfo]

I'm not sure if the build is actually supposed to pass successfully, but either way it should not fail so shortly. The following error must not be thrown:

Artifact dependency points to non existing build configuration with external id: PipelineTest_Restore

[antonarhipov]

Looks exactly like the code that I have created for testing: https://github.com/antonarhipov/myproject

Couldn't reproduce with your example neither.

Maybe teamcity-server.log reveals anything?

[Logerfo]

Here's what happened:

• The repository was created with only a readme file.
• The teamcity project was created.
• Versioned settings was enabled.
• Teamcity commited the settings file.
• The settings file was edited in order to retrace the reproduction steps.
• The build was triggered automatically when the changes were pushed.
• The build failed, QED.
• I changed the log to debug, since the current log wasn't helpful.
• I don't know if I needed to restart teamcity in order to change the log verbosity, so I tried without restarting.
• A single push was not enough to trigger the build.
• Running the build manually could not reproduce the error.

I don't think this has anything to do with the log verbosity, but perhaps this is happening in my private project because it's triggered by a github pull request and both base and target branches are NOT master. My master settings has only one build with a lot of steps. What I'm trying to do is make some steps parallel in order to make the build faster. Do you think that would be possible without messing with master?

[antonarhipov]

Ok, I probably understand now why it fails. So you have a master and a branch. And the configuration that fails is the one that you have in branch?

Unfortunately, I think there's no easy way for you to avoid touching the master. The build chain structure is taken from master. So if your master has one build configuration and you want to have two configurations in the branch - it is not going to work. You can read about branch specific settings and the limitations in this blog post: https://blog.jetbrains.com/teamcity/2018/01/branch-specific-settings-in-teamcity/

---

Just to clarify about the configuration that you have created: surrounding sequence with "parallel" block doesn't make the build configurations that are declared in the nested sequence block to run in parallel. See,

project {
  sequence {
    parallel {
       sequence {
           build(A)
           build(B)
       }
    }
  }
}

In this example, parallel block does nothing. The builds A and B are sequential. What actually is produced here is a project with A & B build configurations where B depends on A.

However, this

project {
  sequence {
    parallel {
       sequence {
           build(A)
           build(B)
       }
       sequence {
           build(C)
           build(D)
       }
    }
  }
}

would produce 2 build chins, A->B and C->D.

[Logerfo]

Yes, thanks, I'm aware of that. I have more than 10 steps, but restoring packages and building cannot be parallel. I just used the problematic part to reproduce the error. Alright then, I'll try to do this again when I manage to have the time to stop master commits and dedicate exclusively to this. It's a shame that Teamcity has such limitations... Anyway, thank you very much!