1023843 - Possible bug in end_to_end_reconfig.sh when using -p option?

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect)

Description

[Pete Moore [:pmoore][:pete]]

From: Simone Bruno <[e-mail]>
Subject: Maybe a bug in your end_to_end_reconfig script
Date: Thu, 5 Jun 2014 21:12:47 +0200
To: Peter Moore <[e-mail]>

Hey pete,

You know yesterday I run a reconfig using your script.

Today I run a dry-run reconfig (-p) option, and the list of changes which would have been brought live partially overlapped with some changes which were brought live by the previous reconfig.

I then removed the /tmp/reconfig folder and tried again: the new dry-run execution gave me a different list of bugs (which I suppose is the correct one).

Is this a bug?

Cheers,

Simone

Comment 1

[Pete Moore [:pmoore][:pete]]

Would be really cool if you could reproduce this and attach the logs. At the moment I can't quite work out how that might have happened. Can you try to reproduce?

I think if you have an old reconfig that did not complete (e.g. you did a dry run), if you later ran it again, it should hg pull / update and find the merge that somebody (you or somebody else) did that put those changes in production, and if it was somebody else, then there should be a merge conflict. If it was you, then your cached reconfig should have been deleted automatically. So I'm not quite sure what happened.

If you have the time to reproduce, this would be really useful (I mean reproduce the problem, not making children).

Thanks,
Pete

Comment 2

[Pete Moore [:pmoore][:pete]]

So I had a similar issue, which may or may not have the same root cause.

The check that something has gone live (and is removed from the list of "things to add to the wiki page") is that the reconfig has been successful. However, if somebody else in between times does a reconfig, and something goes live, it will not be removed from the pending list of things to publish on the wiki.

The solution to this is to build a clean view of the merged changesets when they are finally pushed, to make sure we know exactly what got picked up, and what was already in production branch.

Comment 3

[Pete Moore [:pmoore][:pete]]

My above explanation is perhaps not so clear: just to clarify, I am talking about running a reconfig locally, and then exiting out (e.g. to manage a merge conflict). The next time I run the reconfig, I can continue with the "existing" reconfig, and on this next run, the reconfig script will build on the "cached" state it previously had, to build a list of changes that should be merged, and added to the wiki page.

So for example, I prepare a reconfig, without pushing it. A bug X is added to the list of bugs to publish to the maintenance wiki page. A day later, a different RelEnger does a reconfig, and merges bug X into the production branch, and pushes to production, which causes the wiki page to be updated, saying this bug is live. In my local cached view of the world, this bug did not exist on the production branch at the time I checked it out, and is listed as a pending change, which should be published to the wiki page when the reconfig completes (at some point in the future, when I run it without the -p option). This is a problem, because the assumption that if *I* haven't pushed it to the production branch, then it is something that will go live with my reconfig, is false.

Comment 4

[Pete Moore [:pmoore][:pete]]

I'm not aware this occurred again, and jobs are now moving to task cluster, so marking this as WONTFIX.