Closed Bug 1406006 Opened 2 years ago Closed 2 years ago

Build SHA1 incorrectly displayed when built in hg repository

Categories

(Testing :: geckodriver, defect, P3)

Version 3
defect

Tracking

(firefox62 fixed)

RESOLVED FIXED
mozilla62
Tracking Status
firefox62 --- fixed

People

(Reporter: ato, Assigned: o0ignition0o, Mentored)

References

Details

(Keywords: good-first-bug, Whiteboard: [lang=rust])

Attachments

(1 file)

We compile in the SHA1 from which the geckodriver binary was built,
but it appears not to be working:

> 1507199756141	geckodriver	INFO	geckodriver 0.19.0 (0000000000000000000000000000000000000000 2017-10-04)
Blocks: 1401129
It appears to work with git:

> % ./mach geckodriver 
>  0:00.41 /home/ato/src/gecko/obj-x86_64-pc-linux-gnu/dist/bin/geckodriver --binary /home/ato/src/gecko/obj-x86_64-pc-linux-gnu/dist/bin/firefox
> 1518457267636	geckodriver	INFO	geckodriver 0.19.1 (3ee38289dac8838fe848f7234d75f3cef5d3dbc7 2018-02-09)
Priority: -- → P3
whimboo reported the following for hg:

> 1518458462131    geckodriver    INFO    geckodriver 0.19.1 ( '802cb5d2c482'  '2018-02-07 08:28 +0100')

This means the build SHA1 isn’t broken, but that it is incorrectly
displayed when building from hg.
Keywords: good-first-bug
Summary: Build SHA1 broken → Build SHA1 incorrectly displayed when built in hg repository
Whiteboard: [lang=rust]
The problem here is that the build SHA1 inside the parenthesis
should not contain quotes.  I’m assuming hg returns them
with quotes and that we need to massage the output a bit in
testing/geckodriver/build.rs.
Mentor: ato
It is returned correctly by `commit_hash()`, but maybe the `writeln!` macro adds those extra quotes?
(In reply to Henrik Skupin (:whimboo) from comment #4)

> It is returned correctly by `commit_hash()`, but maybe the
> `writeln!` macro adds those extra quotes?

I think the output from hg must contain the quotes, considering we
write it correctly for git.
What I did was to run the hg command as listed in build.rs, that's all. 

When I have a look at the generated build-info.rs file I see:

> const COMMIT_HASH: Option<&'static str> = Some(" \'802cb5d2c482\'");
> const COMMIT_DATE: Option<&'static str> = Some(" \'2018-02-07 08:28 +0100\'");

The output file contains:

> Output { status: ExitStatus(ExitStatus(0)), stdout: " \'38b3c1d03a59\'", stderr: "" }
> Output { status: ExitStatus(ExitStatus(0)), stdout: " \'2018-02-13 11:39 +0200\'", stderr: "" }

So it's something inside `exec` which puts the quotes around the strings.
No longer blocks: 1401129
Blocks: 1466818
No longer blocks: 1441204
Heya :) 

It turns out the hg log command -T flag doesn't require quotes or anything. 

The output is now : 

```
$ cargo run
   Compiling geckodriver v0.21.0 (file:///C:/Users/Ignition/Projects/mozilla/mozilla-unified/testing/geckodriver)
    Finished dev [optimized + debuginfo] target(s) in 26.51 secs
     Running `c:\Users\Ignition\Projects\mozilla\mozilla-unified\target\debug\geckodriver.exe`
1529221334142   geckodriver     INFO    geckodriver 0.21.0 (944187065098 2018-06-17 09:38 +0200)
1529221334192   geckodriver     INFO    Listening on 127.0.0.1:4444
```

Does it look good to you ?
Attachment #8985821 - Flags: review?(hskupin) → review?(ato)
Thank you for the patch. I forwarded the review to Andreas, who is the mentor of this bug and can also reproduce it compared to me.
Assignee: nobody → jeremy.lempereur
Status: NEW → ASSIGNED
Comment on attachment 8985821 [details]
Bug 1406006 - Get well formatted commit hash and commit date when building geckodriver.

https://reviewboard.mozilla.org/r/251318/#review257672
Attachment #8985821 - Flags: review?(ato) → review+
Thanks for the patch!
Pushed by atolfsen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/4cdab1b804e8
Get well formatted commit hash and commit date when building geckodriver. r=ato
https://hg.mozilla.org/mozilla-central/rev/4cdab1b804e8
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla62
You need to log in before you can comment on or make changes to this bug.