client.py needs to pass the revision argument to hgtool.py

RESOLVED FIXED in Thunderbird 43.0

Status

MailNews Core
Build Config
RESOLVED FIXED
5 years ago
2 years ago

People

(Reporter: standard8, Assigned: Fallen)

Tracking

Thunderbird 43.0

Thunderbird Tracking Flags

(thunderbird41 fixed, thunderbird42 fixed, thunderbird43 fixed, thunderbird_esr38+ fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
hgtool.py can take a revision argument, and will also do a reasonable job of ensuring the end result has the right revision, including cloning from scratch if necessary.

I think if we've got a revision specified, we should just let hgtool.py do the work rather than try and do it ourselves in client.py.
(Reporter)

Updated

5 years ago
Blocks: 757798
(Reporter)

Comment 1

5 years ago
I believe this doesn't need to block bug 757798 as bug 764284 is fixing the fundamental issue of hgtool.py being wrong. This bug is further bullet-proofing on top of fixing those bugs.
No longer blocks: 757798
(Assignee)

Comment 2

2 years ago
Created attachment 8658652 [details] [diff] [review]
Fix - v1

[Approval Request Comment]
Regression caused by (bug #): 
User impact if declined: 
Testing completed (on c-c, etc.): 
Risk to taking this patch (and alternatives if risky):

[Approval Request Comment]
Regression caused by (bug #): 
User impact if declined: 
Testing completed (on c-c, etc.): 
Risk to taking this patch (and alternatives if risky):

[Approval Request Comment]
Regression caused by (bug #): 
User impact if declined: 
Testing completed (on c-c, etc.): 
Risk to taking this patch (and alternatives if risky):

I am using this bug to fix the remains of bug 757798, and the current failures we have been getting for a while:

command: START
command: hg pull --traceback -b releases/comm-beta https://hg.mozilla.org/releases/mozilla-beta
command: cwd: /builds/hg-shared/releases/mozilla-beta
command: env: {'HGPLAIN': '1'}
Hit exception running hg:
Traceback (most recent call last):
  File "../scripts/buildfarm/utils/../../lib/python/util/hg.py", line 99, in get_hg_output
    return get_output(['hg'] + cmd, timeout=timeout, env=env, **kwargs)
  File "../scripts/buildfarm/utils/../../lib/python/util/commands.py", line 207, in get_output
    raise error
CalledProcessError: Command '['hg', 'pull', '--traceback', '-b', u'releases/comm-beta', 'https://hg.mozilla.org/releases/mozilla-beta']' returned non-zero exit status 255
Error pulling changes into /builds/hg-shared/releases/mozilla-beta from https://hg.mozilla.org/releases/mozilla-beta; clobbering
command: START
command: hg clone --traceback -U https://hg.mozilla.org/releases/mozilla-beta /builds/hg-shared/releases/mozilla-beta
command: cwd: /builds/slave/tb-rel-c-beta-m64_rpk_2-000000/comm-beta
command: env: {'HGPLAIN': '1'}
command: END (171.73s elapsed)

This problem occurs since the environment has PROPERTIES_FILE set, which hgtool uses if no revision/branch is specified. The sourcestamp section of the properties file has revision = null, so the branch is used instead, which in the properties file is releases/comm-beta.

The patch fixes this by making sure PROPERTIES_FILE is unset and also passing the revision to hgtool explicitly.
Assignee: nobody → philipp
Status: NEW → ASSIGNED
Attachment #8658652 - Flags: review?
Attachment #8658652 - Flags: approval-comm-esr38?
Attachment #8658652 - Flags: approval-comm-beta?
Attachment #8658652 - Flags: approval-comm-aurora?
(Assignee)

Updated

2 years ago
Attachment #8658652 - Flags: review? → review?(bugspam.Callek)
Comment on attachment 8658652 [details] [diff] [review]
Fix - v1

Review of attachment 8658652 [details] [diff] [review]:
-----------------------------------------------------------------

Looks sane enough, sadly though I don't have the bmo magic to approve.
Attachment #8658652 - Flags: review?(bugspam.Callek) → review+

Comment 4

2 years ago
Why after 3 years is this problem now causing failures? Did something change in the build infrastructure? If so, does that change affect all of our branches?
(Assignee)

Comment 5

2 years ago
It has been broken all along, and has also been causing failures all along. It just seems the failures didn't cause any issues. This is "just cleanup", but it would make sure that the correct revisions are pulled during repacks. If you are not comfortable with pushing to comm-esr38, I'd at least ask for beta approval since it will only really be clear if it works in beta l10n repacks. If it works there next cycle, we could backport it to esr38 (if we haven't forgotten).

Comment 6

2 years ago
Comment on attachment 8658652 [details] [diff] [review]
Fix - v1

That sounds like a good idea. We look at beta before deciding what to do with esr38

Is this involved at all with the issue of the try server not reliably switching back to the default mozilla repo revision after a test that changed it?
Attachment #8658652 - Flags: approval-comm-beta?
Attachment #8658652 - Flags: approval-comm-beta+
Attachment #8658652 - Flags: approval-comm-aurora?
Attachment #8658652 - Flags: approval-comm-aurora+
(Assignee)

Comment 7

2 years ago
(In reply to Kent James (:rkent) from comment #6)
> Is this involved at all with the issue of the try server not reliably
> switching back to the default mozilla repo revision after a test that
> changed it?

Nope, that is bug 1154222. I can spin up a patch there that uses MOZ_AUTOMATION to automatically remove hgtool, add apply-patches, and clean out the patches.
(Assignee)

Comment 8

2 years ago
Pushed to comm-central changeset 917c6e36e640
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 43.0
(Assignee)

Comment 9

2 years ago
Backported to releases/comm-aurora changeset d274c6770247
Target Milestone: Thunderbird 43.0 → Thunderbird 42.0
(Assignee)

Comment 10

2 years ago
Backported to releases/comm-beta changeset 0ac48cae54bf
Target Milestone: Thunderbird 42.0 → Thunderbird 41.0
(Assignee)

Updated

2 years ago
status-firefox41: --- → fixed
status-firefox42: --- → fixed
status-firefox43: --- → fixed
Target Milestone: Thunderbird 41.0 → Thunderbird 43.0

Updated

2 years ago
status-firefox41: fixed → ---
status-firefox42: fixed → ---
status-firefox43: fixed → ---
status-thunderbird41: --- → fixed
status-thunderbird42: --- → fixed
status-thunderbird43: --- → fixed
status-thunderbird_esr38: --- → affected
tracking-thunderbird_esr38: --- → +
(Assignee)

Comment 11

2 years ago
We've successfully build TB 41.0b2 with this patch, can you complete the approval for esr38?
Flags: needinfo?(rkent)

Updated

2 years ago
Flags: needinfo?(rkent)
Attachment #8658652 - Flags: approval-comm-esr38? → approval-comm-esr38+
(Assignee)

Comment 12

2 years ago
Backported to releases/comm-esr38 changeset d201ce27282f
Target Milestone: Thunderbird 43.0 → Thunderbird 38.0
(Assignee)

Updated

2 years ago
status-thunderbird_esr38: affected → fixed
Target Milestone: Thunderbird 38.0 → Thunderbird 43.0
You need to log in before you can comment on or make changes to this bug.