No way to have an *optional* dependency chain?

I have 2 jobs:

1. DockerBuild
    - VCS Trigger: +:Dockerfile.build
2. Build
    - VCS Triggger: all
    - Snapshot Dependency on DockerBuild

Why is DockerBuild triggered when the commit does not change Dockerfile.build?
I get that the builds form a chain, but why can we not “enter” in the middle of the chain?

There's just no need to run a long (and no-op) build every time a change is made just to do (effectively) nothing.
It doesn't seem like Artifact Dependencies act any different – plus I'm not sending a dependency within TeamCity (it's a docker image upload).

There also seems no (obvious) way to skip a build step based on VCS data without manually writing it in a shell script.
Even if I could, it's still consuming an agent just to do an `if false {…}` which is wasteful.

If you could have optional build steps I could consolidate them in a single build but still…

Is just a missing feature?
I can't imagine this is by design or that I'm the only one who has this issue

0
3 comments
Hi,

Let me explain the setup with an example:
1. You have a main build configuration (Build) with dependencies on build configurations AppA and AppB.
2. AppA requires sources only from appA directory to build, AppB - only from the appB directory.
3. Your commits can have changes only to appA, appB, or to both directories.
4. You want to build only AppA if there are changes only to appA, and only AppB if there are changes only to appB and both if there are changes to both.

Setup:
1. VCS trigger on Build that monitors all changes.
2. Snapshot dependencies on both AppA and AppB.
3. AppA and AppB don't have VCS triggers.
4. AppA has a checkout rule (https://www.jetbrains.com/help/teamcity/2024.07/vcs-checkout-rules.html) to checkout only appA directory.
5. AppB has a checkout rule to checkout only appB directory.

Result example:
1. The Build is triggered with changes only to appA.
2. Both AppA and AppB are triggered.
3. AppA checkouts appA directory only and calculates changes.
4. Since there are no relevant to the checkout rule changes, it will look for the last relevant changes.
5. If suitable for reusing (https://www.jetbrains.com/help/teamcity/2024.07/snapshot-dependencies.html#Suitable+Builds) AppA build on the last relevant changes can be found, this build will be reused, and AppA build won't run. Of course, if there is no such build, the AppA build will run.
6. AppB build will run with new changes.

And, you shouldn't use VCS triggers on dependent builds. All it does is additional triggering of it, it's not a "filter".

And additionally, in November we'll introduce the following feature, which allows for even more fine-grained control over what dependencies to run: https://youtrack.jetbrains.com/issue/TW-65341.

Best regards,
Anton
0

This is a wild workaround… there's the whole concept of “triggers” and we're relying on “checkout rules”?

Regardless:
 

4. AppA has a checkout rule

 

just results in the following:
 

Updating sources: auto checkout (on server)
21:58:01   Will use server side checkout: Checkout rules are not supported for vcs root ‘******’. Details: Unsupported rules for agent-side checkout: +:docker => .
21:58:01   Building and caching clean patch for VCS root: https://********
21:58:01   Transferring cached clean patch for VCS root: https://*********

 

and looking into that it seems like git doesn't even support checkout rules?
So essentially, when using git, there is no way to have optional dependent builds?

0
Hi,

The VCS trigger may only trigger the build, the dependencies are then triggered by the build that depends on them, so it's a different concept.
In your initial setup, the Build is triggered by any change and then triggers the DockerBuild because of the snapshot dependency. In addition, any change to Dockerfile.build will trigger DockerBuild and Build separately (the latter will trigger DockerBuild again as a dependency, but this build should be "optimized" automatically, so you won't see it as a separate one). It is useful in many scenarios but can't be used to determine which dependencies to run.

Checkout rules are supported for Git, the setup I gave in my previous comment was tested with Git. TeamCity uses `git sparse-checkout` (https://git-scm.com/docs/git-sparse-checkout#_sparse_checkout), which imposes some restrictions on the checkout rules. The error you are getting means that `git sparse-checkout` does not support the checkout rules you are using. Please see this page for the details: https://www.jetbrains.com/help/teamcity/git.html#Limitations.
Please try `+:docker` or `+:docker=>docker` checkout rules instead.

Best regards,
Anton
0

Please sign in to leave a comment.