1. NO_DEPENDENCY_CHECKS=true doesn't do what you want.
Yes, as the name suggests that keyword is only for CQ to skip the check of if there are any open dependencies. But apply_issue IIRC will still apply all dependencies when running tryjobs. CQ would have only landed the change in the CL and not the dependencies so it is not as dangerous as you described.

2. git config branch.$BRANCHNAME.skip-deps-uploads True seems to have no effect.
That should have worked. It is possible that recent changes broke it in depot_tools.

Since we are moving to Gerrit soon it makes sense to not fix this on Rietveld and just wait for Gerrit. IMO Gerrit has a much better structure for handling dependencies.

What Rmistry@ said. 

Thanks for replies.

#1 number 1: I'm not clear on what NO_DEPENDENCY_CHECKS is for then. It seems (from your statement above) that this will correctly land the downstream CL if the upstream CL passes all checks (including having LGTMs), but it will refuse to land downstream if upstream isn't ready to land. Which sort of defeats the purpose (if upstream is ready to land, why not just land it first? The entire point of this, I thought, is if your downstream CL gets approved first, you can land it first if it doesn't actually require the upstream).

Number 2: Oh oh .... I just remembered something from the back of my memory about this which is extremely unintuitive: you have to put skip-deps-uploads on the PARENT branch, not the CHILD branch. I just tried it: it works on the parent but not the child.

That's really confusing and not documented. It also leads to some impossible-to-get-right situations: if you have parent branch A, with child branches B and C, let's say B doesn't really depend on A (you just had to set it up that way for some other reason), but C hard-depends on A. Under this regime, you need to set A.skip-deps-uploads = True, which removes both the A-B and the A-C dependency. You can't just remove the A-B dependency but not the A-C.

Anyway I agree it isn't worth fixing in Reitveld but hopefully both of these problems are resolved in Gerrit (or otherwise there is a convenient way to manage whether your git branches imply actual dependencies or not). Essentially I just want a way to opt-in to landing a git branch that is a child branch, before its parent, if I know what I'm doing. Cheers! (In the mean time, I will make some suggestions on that documentation for clarity.)

Also on NO_DEPENDENCY_CHECKS... if it works as you describe then it's dangerous for another reason, which is it isn't testing the code that actually lands.

Say we have branch A which has a child branch B, and B has NO_DEPENDENCY_CHECKS=true. Let's say the two CLs have no textual conflicts, but B soft-depends on A (i.e., it is broken in a subtle way without A, or maybe it fails tests without A). And both CLs have LGTMs.

If I check the commit box on CL B, it will apply patch A, then patch B, then run the try jobs on the combined patch, and the tests will pass. Then it does a presubmit check on both A and B and sees approvals. Then it will land *just* patch B, which will apply cleanly (textually) but introduce a bug because A has not landed. If it fails tests, those failures will only first appear on the waterfall.

Am I understanding it right? I can't think of a situation where NO_DEPENDENCY_CHECKS is both useful and safe.

"Am I understanding it right? I can't think of a situation where NO_DEPENDENCY_CHECKS is both useful and safe."

It was added because of feedback from people who said they had dependent branches created but wanted an easy way to land their change regardless of the open dependency. Sometimes it was because the dependency was accidentally created and sometimes because they did not care about the dependency anymore. What you described could in theory happen but I have not heard of a single instance of that happening in the roughly 1.5 years that this has been live.

I will go through your doc changes soon (thanks for those!). Also reiterating that this will all be obsolete soon.

> people who said they had dependent branches created but wanted an easy way to
> land their change regardless of the open dependency. Sometimes it was because
> the dependency was accidentally created and sometimes because they did not care
> about the dependency anymore.

That's exactly what we want it for, but it seems it doesn't work because you need LGTMs on the parent branch (which if you "don't care about anymore", you are unlikely to have), so I'm not sure how this is useful. Maybe it used to work.

Anyway, I'll stop taking up your time with this because of the fact that it will be obsolete soon, no point discussing :)

Yes you are right about the problem with OWNERS checks. I did hear complains about that occasionally but there was unfortunately no easy way to handle that. I think devs did not run into it that often because IIRC OWNERS checks are skipped during dry runs (so it has to be a real commit attempt), and the parent has to be touching files that require approval from different owners (which is probably not that common as well).

Closing in bulk due to Rietveld’s deprecation in favor of Gerrit. If you feel this bug should not have been closed, please feel free to re-open.