Composite for sync checker4/11/2023 ![]() Instead, I want B to collect changes at the time it gets out of the queue and starts running, not when it gets queued an hour or two before actual execution. Part of build chain behavior that I'm trying to avoid is this one: "When the builds are added to the queue, TeamCity starts checking for changes in the entire build chain and synchronizes them - all builds have to start with the same sources snapshot." It's exactly the synchronization I'd like to avoid. when the whole chain is triggered by A, B runs first and then A runs. To demonstrate my situation with simplified example, let's say there's B -> A build chain, i.e. It looks like Disabling Revisions Synchronization Between Chain Parts feature covers slightly different use case than mine: " is useful when you need to run a dependent build without synchronizing its code revision with its dependencies (preceding builds in a chain)." I probably should have explained my goal a bit better for it seems to be not too common one and, perhaps, violates some core assumptions of build chains' use cases. So my question is if there's any way to disable revision synchronization for dependencies? Or maybe I could approach the whole problem in some completely different way without using snapshot dependencies? Ideally, I would like to be able to run the builds against the latest sources. This means that because of p.2 (non-negligible max time spent in build queue) some builds end up running against a little bit dated sources. The only thing I cannot seem to be able to work around is the fact that VCS roots in the dependencies collect changes when the build chain is added to the build queue. ![]() It works perfectly, except for one thing. So I set up single composite build with proper builds from p.1 as snapshot dependencies, "Pull Requests" and "Commit status publisher" build features. Given above requirements, I experimented with Composite Build Configuration ( ) as it seemed perfect fit for the job. Ideally, pipeline should be triggered by a feature branch change (refs/pull-requests/123/from in Bitbucket lingo), but checkout merges of the feature branch into target branch (refs/pull-requests/123/merge in Bitbucket lingo).if there are, say, 3 individual builds from p.1 with two passing and one failing then Bitbucket should receive single "failed" build status. The result of the testing should be reported to Bitbucket as a single aggregate value.There's much less build agents available for the task, so it's not impossible for a particular build to spend quite some time (up to 1-2 hours) in a build queue.The tests are already partitioned as separate TeamCity build configurations, each having good enough execution time. One way or the other tests should run in parallel to achieve reasonable execution time. ![]() Repository is git repo hosted with Bitbucket server and TeamCity is Enterprise 2019.1.5 (build 66605). I'm trying to setup a pipeline for running all kinds of tests against pull requests into my repository.
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |