In T343967#9151215, @dancy wrote:

@jeena Ping to publish a new scap release.

I think this needs to be backported since the branch commit for wmf.25 already happened before merge

Hi @xSavitar, this feature exists already. I'll be adding an integration test for it soon.

We plan to make a new scap release and deploy the changes that address this on June 15

No, I think it should skip the sync step instead of fail if the branch is not staged.

Just tested this and as it works currently, It will continue to merge and deploy as directed by the user, but will fail with an error if the branch is not staged.

It appears that the issue has been resolved.

In T329770#8746098, @dancy wrote:

The master branch still exists at the moment which is confusing. I think we should delete it so that when people git pull to update theirs, they will find out about it not being there anymore (rather than thinking that there are no new changes).

In T329770#8743492, @thcipriani wrote:

(Internal Release-Engineering-Team) update train-dev environment checkouts

^ is this still lingering?

I opened this related task: T330194

Renaming branch in another task.

Fixes were deployed in scap 4.37.0

I will add some extra output to clarify what is happening (checking for dependencies of the dependency).

MR above modifies the depends_on check to request dependecies for a change_id in a specific project & branch to avoid the multiple changes error. This functionality existed previously but was removed in a refactor (oops), so I added a comment to make sure it doesn't happen again, but maybe best to add a test for this.

In T323277#8597192, @Urbanecm wrote:

In T323277#8596212, @Tgr wrote:

Or maybe just leave it to the user to backport the dependencies with separate scap backport calls, and ask for manual confirmation that that happened (or check via git but that seems more fragile).

AFAIK, once a change has a dependency with a backport, scap backport fails even with a single change specified. I had to fetch said change manually and do a scap sync-world instead.

Is this resolved now?

I did some more investigation and I think the deployment couldn't continue since it was searching for a commit with "Change-Id: I39ab54ca6e9f9a6a58b59cdd6feea07638fc908f", but the commit for the patch in question had "Change-ID: I39ab54ca6e9f9a6a58b59cdd6feea07638fc908f". I thought the Change-Id line was case sensitive, but it seems not since the patch was accepted into gerrit, so I'll change the search to reflect that.

So far I haven't reproduced this issue in our test environment. If it happens again please update with a copy of the output up until it breaks if you can.

This was done, but disabled due to poor performance. A summary of results is in this commit message: https://gitlab.wikimedia.org/repos/releng/kokkuri/-/commit/1dfd3a0d6582fc284200c4db34661de06e5a5c78