Closed Bug 1146379 Opened 9 years ago Closed 8 years ago

hgtool should avoid pulling if it already has a revision

Categories

(Release Engineering :: General, defect)

x86_64
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: catlee, Assigned: catlee)

Details

Attachments

(1 file, 1 obsolete file)

Most cases in automation specify the revision they want to checkout to hgtool. Right now it's always does a pull prior to updating to the revision.

We could save on some load by checking first to see if we have the revision locally prior to contacting the remote.
Great idea!
Attachment #8583076 - Flags: review?(bhearsum)
Assignee: nobody → catlee
Attachment #8583076 - Flags: review?(bhearsum) → review+
Attachment #8583076 - Flags: checked-in+
Comment on attachment 8583076 [details] [review]
check to see if we have a revision before pulling

backed out on suspected bustage for Try:
remote:   https://hg.mozilla.org/build/tools/rev/3e1b71cac152

failed builds started rolling in around the time of this deployment complaining about Revisions. I suspect this is because Try is a special snowflake that calls hgtool differently (with --revision for example)

log examples:
https://treeherder.mozilla.org/logviewer.html#?job_id=5948205&repo=try
https://treeherder.mozilla.org/logviewer.html#?job_id=5953389&repo=try
Attachment #8583076 - Flags: checked-in+ → checked-in-
hrm, maybe this is not the cause of failed jobs but treehereder is highlighting the errors:

15:27:00    ERROR -  abort: unknown revision 'af9c9ff307d0'!
15:27:00    ERROR -  Automation Error: hg not responding

but it looks like it recovers after:

15:27:30     INFO -  command: output:
15:27:30     INFO -  af9c9ff307d0
15:27:30     INFO -  Got revision af9c9ff307d0
15:27:30     INFO - Return code: 0
yes it looks like all green builds are getting highlighted in try with:

"abort: unknown revision '$SOME_REV'!" 

we should probably just surpress/catch that output. Sounds like the exception subprocess.CalledProcessError is not enough
Fixed up the logging a bit. It now looks like this on success:

...
checking to see if 2d6cc215dc64 exists in /home/catlee/test/buildbotcustom
command: START
command: hg log -r 2d6cc215dc64 --template {node}
command: cwd: /home/catlee/test/buildbotcustom
command: env: {'HGPLAIN': '1'}
command: END (0.25s elapsed)

command: output:
2d6cc215dc6480808296d386cf8b97a04ef4785e
2d6cc215dc64 exists in /home/catlee/test/buildbotcustom
skipping pull since we already have 2d6cc215dc64
...

and on failure:

...
checking to see if 2d6cc215dc65 exists in /home/catlee/test/buildbotcustom
command: START
command: hg log -r 2d6cc215dc65 --template {node}
command: cwd: /home/catlee/test/buildbotcustom
command: env: {'HGPLAIN': '1'}
2d6cc215dc65 does not exist in /home/catlee/test/buildbotcustom
...
Attachment #8583076 - Attachment is obsolete: true
Attachment #8583839 - Flags: review?(bhearsum)
Attachment #8583839 - Flags: review?(bhearsum) → review+
Attachment #8583839 - Flags: checked-in+
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Component: Tools → General
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: