Closed Bug 1170309 Opened 9 years ago Closed 9 years ago

add a .travis.yml file to run flake8 and unit tests on Talos

Categories

(Testing :: Talos, defect)

defect
Not set
normal

Tracking

(firefox41 affected)

RESOLVED FIXED
Tracking Status
firefox41 --- affected

People

(Reporter: parkouss, Assigned: parkouss)

Details

Attachments

(1 file)

Talos is hosted on an internal mercurial repo here:

http://hg.mozilla.org/build/talos

This makes things a bit hard to build some continuous integration around this, but we have a mirror on a public github:

https://github.com/mozilla/build-talos

So we could add a .travis.yml file to run flake8 and unit tests on travis server for free. This won't be perfect (builds will be triggered after the merge...) but this is better than nothing. :)
Well there is a test that fails (see bug 1169596) and blocks this bug. The test file is the following:

https://github.com/mozilla/build-talos/blob/master/tests/test_install.py

It looks like it is testing a talos install. I am not sure this is really useful (we do not want to test virtualenv, setuptools or distribute I think), and installing it on travis anyway should replace this test.

I propose that we simply remove that test file along with this bug. :jmaher, what do you think ?
Flags: needinfo?(jmaher)
So I started to work on this. Here is the commit (pushed on my github fork so I can trigger travis build):

https://github.com/parkouss/build-talos/commit/b2fc45d3c441a5fbe232d87b7d14d6bd4e0810c3

The patch can be seen here:

https://github.com/parkouss/build-talos/commit/b2fc45d3c441a5fbe232d87b7d14d6bd4e0810c3.patch

Here is the result of the travis build:

https://travis-ci.org/parkouss/build-talos

Note that I also removed the runtests.py file, replacing it by using test_suite="tests" in the setup.py file. I think it is a good cleanup - now the tests can be run with: "python setup.py test".

You'll tell me what do you think of all this.


Also, I'm wondering if we could use github PR to submit talos patches ? It would allow to run flake8/tests automatically,
then it should be possible to merge this into hg using the PR url + ".patch".

I created for example the PR:

https://github.com/mozilla/build-talos/pull/3

So full patch is available with:

https://github.com/mozilla/build-talos/pull/3.patch

Pretty easy. It is also possible to separate patches (if the PR has multiple commits and we want to keep them separated).

Then last thing would be to apply patch(es) in the hg repo, then close the PR.

Again, what do you think Joel ?
Well this is a bit more complicated in fact. :) git patch to hg patch conversion is a science, luckily implemented with:

https://github.com/mozilla/moz-git-tools/blob/master/hg-patch-to-git-patch

so it is possible to import a patch from github using:

> wget -O - 'https://github.com/mozilla/build-talos/pull/3.patch' 2>/dev/null | git-patch-to-hg-patch | hg import -

given that git-patch-to-hg-patch is executable and available on PATH. But after, it works all great: username, commit message, ...

I'm going to star moz-git-tools. :)
test_install.py - we can ax it; we are almost away from the virtual env for the mozharness script.
runtests.py - yes, we can remove that- I like "python setup.py test" as a good replacement

regarding the PR -> git stuff, I think that could be confusing- the ultimate goal is to get this into mozilla-central after we cleanup a larger series of things.  If we can make this work for now while making a big push for cleanup/tests, I am fine with this.  Keep in mind that developers check in fixes and they might not want to use this model.
Flags: needinfo?(jmaher)
Attached patch 1170309.patchSplinter Review
(In reply to Joel Maher (:jmaher) from comment #4)

> regarding the PR -> git stuff, I think that could be confusing- the ultimate
> goal is to get this into mozilla-central after we cleanup a larger series of
> things.  If we can make this work for now while making a big push for
> cleanup/tests, I am fine with this.  Keep in mind that developers check in
> fixes and they might not want to use this model.

Oh, I did not mean to impose this workflow. It was more a question if you are ok with that workflow (as you are merging stuff into talos). That would allow me to push on github (so I know that I don't break flake8/tests before actually merging the code) and to not copy the patch on bugzilla too.

But this is not a problem for me, I can continue to attach raw patches in bugzilla that I will convert myself from my github pushes. I will certainly find a way to automate that part, no worries. :)
Assignee: nobody → j.parkouss
Status: NEW → ASSIGNED
Attachment #8613992 - Flags: review?(jmaher)
No longer depends on: 1169596
Comment on attachment 8613992 [details] [diff] [review]
1170309.patch

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

great, lets land this!
Attachment #8613992 - Flags: review?(jmaher) → review+
I have asked level 3 access to be able to land on Talos: bug 1170654
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: