New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 699813 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Jul 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Feature



Sign in to add a comment

Add build_number field to BuildBucket.Get response.

Project Member Reported by jinjingl@chromium.org, Mar 9 2017

Issue description

This build_number is needed to query milo.BuildInfo.Get. 
 
Cc: estaab@chromium.org hinoka@chromium.org
 

Comment 2 by no...@chromium.org, Mar 9 2017

After our chat, I've realized that 
1) buildnumber is already present in completed builds, e.g. cr-buildbucket.appspot.com/b/8985632559344171808 has the buildnumber in result_details_json

2) You actually want buildnumber to be available when build starts. The only properties we change when the build starts is status is URL. A natural place to store buildnumber is build tags, but I'm reluctant to mutate tags because a build may be reset and started again, in which case multiple build number tags would be added (which may be confusing). It is OK to change url because we always change it, as opposed to appending new builds.

WDYT about extracting master, builder and buildnumber from the build URL? Buildbot build URLs are rather stable, will probably never change. They always end with <master>/builders/<builder>/<buildnumber>. The build URL is available as soon as build starts and you could use it today.

Comment 3 by leecy@chromium.org, Mar 9 2017

I was thinking tags would be a natural fit for this as well -- I'm not sure I understand what the potential multiple build number tags means?  Would it be buildnumber:1, then later buildnumber:4?  Or buildnumber:1, buildnumber:1.  I would definitely prefer not to parse from the URL if possible.  I don't fully understand why if we can specify url, we cannot specify buildnumber etc. in a parsed format as well.
Cc: nxia@chromium.org

Comment 5 by no...@chromium.org, Mar 14 2017

If a buildbot master is restarted, all its running builds are dropped. When it starts again, all the builds that were running are associated with the same buildbucket builds are restarted. In this case, from the buildbucket perspective a build is started twice.

To be clear, today it is possible that a buildbot build is failed, but buildbucket build is not. Later another buildbot build is associated with the same buildbucket build, it succeeds and both buildbot and buildbucket builds are marked green. Buildbucket is the source of truth, not buildbot.

If I append buildnumber tag on build start, there may be multiple buildnumber tags in a single buildbucket build. Buildnumbers are ordered chronologically, so in that case, only the greatest should be considered. 

I can implement buildnumber appending on build start, let me know what you think.

(sorry for the delay, perfing).

==============

An alternative to all this is to add support for buildbucket ids to BuildInfo endpoint. Buidbucket users should not interact with buildnumbers since it breaks the encapsulation. Ryan, how difficult it is to search for a build by buildbucket id?

Comment 6 by no...@chromium.org, May 1 2017

Ping

Comment 7 by no...@chromium.org, May 3 2017

Cc: no...@chromium.org
Owner: ----
we need to continue this discussion in order to make progress in this bug

Comment 8 by leecy@chromium.org, May 3 2017

Cc: jinjingl@chromium.org
We're already starting to query milo using buildnumber, so I think that should be OK with us.  A buildbucket ID would be inconvenient for us currently because our masters aren't scheduled via buildbucket, and we need to query for that builder's status via build numbers in any case.

Comment 9 by no...@chromium.org, May 3 2017

So you don't need this feature?
Status: WontFix (was: Untriaged)
I'll take that as a "no". Please reopen if it is the case. As ChromeOS is also migrating off buildbot, this may not be necessary on the long term?

Sign in to add a comment