The plan Stuart and I have come up with is basically the following: 1. Get TPS running on someone's laptop. [Karl, this week.] 2. Get TPS running on a QA Jenkins slave. [Karl and Stuart, with help from the rest of their team, this week or next.] 3. Once the tests are actually running and showing red, ask markh (and the rest of the community) for help in turning them green. [By 9 November, we hope.]
If anyone has details of this they'd like to help flesh out, we'd love the input. And if I get stuck on 1, above, I will definitely be asking the list for help. Let us know what you think! Thanks, --KT. On Thu, Oct 29, 2015 at 10:02 AM, Christopher Karlof <[email protected]> wrote: > Thanks, Stuart! > > On Thu, Oct 29, 2015 at 9:54 AM, Stuart Philp <[email protected]> wrote: > >> Yeah! Karl and I are going to work through a plan for this later today, >> so we'll get a proposal together and submit it to sync-dev for everyone to >> read/comment on. >> >> On Thu, Oct 29, 2015 at 12:30 PM, Christopher Karlof <[email protected] >> > wrote: >> >>> I’m a bit sad this conversation isn’t on the sync-dev. >>> >>> On Thu, Oct 29, 2015 at 4:16 AM, Henrik Skupin <[email protected]> >>> wrote: >>> >>>> Stuart Philp wrote on 10/22/2015 09:06 PM: >>>> >>>> Hi all, >>>> >>>> and sorry for the late reply but several RelEng work busted our CI >>>> infrastructure last week and fixing that was a higher priority for me. >>>> But now lets see which information I can give to you all. >>>> >>>> > We've been discussing bringing back TPS lately and what needs to >>>> happen >>>> > to get it stood up inside our services infrastructure so that markh >>>> can >>>> > start using it again and get the tree green for sync deploys. >>>> >>>> That sounds great. >>>> >>>> > Is it possible to just run TPS entirely within a docker image? My >>>> > thinking is that if we have that self-contained/portable environment, >>>> > we'll then easily be able to use that docker image in a jenkins job on >>>> > our jenkins infrastructure to run on every sync build, which also >>>> allows >>>> > for reporting and build history. Mark would also be able to use that >>>> > image locally for development. At some point in the future we would >>>> then >>>> > look at getting the results into treeherder proper. >>>> >>>> I have never checked if docker would work and I also cannot say details >>>> given that we are also not using docker for our firefox-ui-tests. But I >>>> would be highly interested in if you can get this working. Regarding >>>> submission to Treeherder I can give hints given that I was doing that >>>> lately for our tests. >>>> >>>> > Reading through the docs ( >>>> https://developer.mozilla.org/en-US/docs/TPS) >>>> > there doesn't appear to be anything that would limit this, looks like >>>> a >>>> > pretty straight forward venv, but I thought I'd clear it with you >>>> before >>>> > we try some other approach. >>>> >>>> The commands we currently use you can find in the coversheet repository: >>>> >>>> >>>> https://github.com/mozilla/coversheet/blob/master/jenkins-master/jobs/mozilla-central_fx-account/config.xml#L64 >>>> >>>> >>>> https://github.com/mozilla/coversheet/blob/master/jenkins-master/jobs/tools/workspace/trigger.py >>>> >>>> That means all what you would be interested in is in that trigger.py >>>> file. Keep in mind that this is currently broken due to the needed >>>> tests.zip file does no longer exist. You tests should be part of the >>>> common test package. >>>> >>>> > We (Karl and myself) will take ownership of the work if it is indeed >>>> > possible, all we ask is you be available to answer any of our silly >>>> > questions ;) >>>> >>>> Sure! Best here would be if you also join #automation on IRC. >>>> >>>> Best, >>>> Henrik >>>> >>>> -- >>>> Henrik Skupin >>>> Senior Test Engineer >>>> Mozilla Corporation >>>> >>> >>> >> >
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
