This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

+sergiyb@ have you by any chance fixed this already?

to nodir@ for retriage.

I have done it for V8 only, but I have not modified buildbucket module since I am not sure which other users it has. See https://chromium.googlesource.com/chromium/tools/build/+/5a8964ed1cabc9fed6966bf256137f52d4143014/scripts/slave/recipe_modules/v8/api.py#1244. If we want buildbucket module to be doing exactly same as trigger module, I'd be happy to move the logic into buildbucket module.

i am not sure we want to carry parent_build_id concept to LUCI code. Maybe, but it need a discussion.

i am not sure users need parent_build_id either. Once case it was needed is to locate GS file because it had parent_build_id in it. Passing GS file location directly as a property was a much cleaner solution.

Does v8 need parent_build_id?

Note that I think it is perfectly ok to add parent_build_id:<buildbucket_id> build tag for preserve the build association for search and whatnot. Properties are different, they are input to the build

Didn’t mean to close the bug

I don't think v8 uses parent_buildnumber at the moment, but we've been discussing a potential use case: link parent build to simplify viewing compilation steps for the tests run in the child build.

It can also be moved as an entire URL formatted in the parent build, but I don't see why passing parent_build_id and formatting the link in the child build is an issue. Whether we want to add it for all triggered builds via buildbucket module or keep the code in V8 is a different issue and depends on how many realistic uses it has or will potentially have in the future.

displaying a link on a build page from a child build to the parent build is a reasonable feature request in Milo. I've filed bug 779713. This still does not require adding a build property though. 

I think of build properties as input to the build, like parameters (+ianucci in case this is inaccurate). If the build result does not depend on a property, perhaps it shouldn't be a parameter (=property). Currently properties are used for many things including metadata, such as parent build. I believe the closer we get to "properties are parameters", the better it is because we are closer to the Single Responsibility Principle.

Do you anticipate using parent_build_id in recipe code?

I understand your argumentation, but apart from specifying how something is to be built/tested, recipes are currently used for defining user UI via step name, logs and links. Sometimes this UI elements require input parameters that are not relevant to an actual building/testing instructions.

Good point. In that sense parent_build_id property makes sense.
Robbie, do you think we should add parent_build_id property at the buildbucket module level, as opposed to user code triggering builds?

we discussed the need for native support for parent-child build relationship extensively with CrOS in https://groups.google.com/a/google.com/forum/#!topic/cros-trebuchet/WlduAp7gNi4
and came to a conclusion that it is not needed. Also there is argument that we are getting into Dungeon Master problem space. Perhaps we should invest in DM instead.
Therefore, i think it is correct that buildbucket recipe module does not specify parent build id, as buildbucket does not have this concept.