Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run stable and beta releases on TaskCluster #12679

Merged
merged 9 commits into from
Sep 6, 2018
Merged

Run stable and beta releases on TaskCluster #12679

merged 9 commits into from
Sep 6, 2018

Conversation

jgraham
Copy link
Contributor

@jgraham jgraham commented Aug 24, 2018

No description provided.

@jgraham
Copy link
Contributor Author

jgraham commented Aug 24, 2018

@jugglinmike if you happen to already have a staging repo configured to run TaskCluster I would appreciate some testing of this branch. If you don't I can set one up myself.

@gsnedders
Copy link
Member

Also can we document how to set something up to test TC changes?

Copy link
Contributor

@jugglinmike jugglinmike left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jgraham in wpt.fyi, we use the terms "stable" and "experimental" to refer to
various browser releases generically. Internally, we map the latter to Chrome's
"dev" channel and Firefox's "nightly" channel. Taking that approach here would
allow us to expose a much more uniform interface. The new terminology will have
to be documented, but it may be easier to explain what we mean by
"experimental" versus having to interpret input like "Chrome nightly" or
"Firefox dev". What do you think?

@jugglinmike if you happen to already have a staging repo configured to run
TaskCluster I would appreciate some testing of this branch. If you don't I
can set one up myself.

Sure. I had to apply some of my suggestions to get it to run, but here's a push
to "epochs/daily": https://tools.taskcluster.net/groups/PS2oLaLRRZOl0M94VKHLZQ

@@ -3,8 +3,8 @@
./wpt manifest-download

if [ $1 == "firefox" ]; then
./wpt run firefox --log-tbpl=../artifacts/log_tbpl.log --log-tbpl-level=info --log-wptreport=../artifacts/wpt_report.json --log-mach=- --this-chunk=$3 --total-chunks=$4 --test-type=$2 -y --install-browser --no-pause --no-restart-on-unexpected --reftest-internal --install-fonts --no-fail-on-unexpected
./wpt run firefox --log-tbpl=../artifacts/log_tbpl.log --log-tbpl-level=info --log-wptreport=../artifacts/wpt_report.json --log-mach=- --this-chunk=$4 --total-chunks=$5 --test-type=$3 -y --install-browser --borwser-channel=$2 --no-pause --no-restart-on-unexpected --reftest-internal --install-fonts --no-fail-on-unexpected
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: --borwser-channel=$2 -> --browser-channel=$2

@@ -32,10 +33,21 @@ git checkout -b build ${REV}

sudo sh -c './wpt make-hosts-file >> /etc/hosts'

if [[ $BROWSER == "chrome"* ]] || [[ "$BROWSER" == all ]]
if [[ $BROWSER == "chrome" ]] || [[ "$BROWSER" == all ]]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Appreciate the specificity this buys us

then
deb_archive=google-chrome-stable_current_amd64.deb
else
exit 1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While we're here, how about echo Unrecognized release channel: $CHANNEL >&2?

version = {
"stable": "latest",
"beta": "latest-beta",
"nightly": "latest",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mind removing the trailing comma for consistency?

"""Install latest Browser Engine."""
if channel != "nightly":
raise ValueError("Only nightly versions of Servo are availalbe")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typo: "availalbe" -> "available"

def get_parser():
parser = argparse.ArgumentParser()
parser.add_argument('browser', choices=['firefox', 'chrome'],
parser.add_argument('browser', choices=['firefox', 'chrome', 'servo'],
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea

@@ -16,6 +19,13 @@ def get_parser():
def run(venv, **kwargs):
browser = kwargs["browser"]
destination = kwargs["destination"]
channel = kwargs["channel"]
if browser == "chrome" and channel == "nightly":
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think many users will expect this behavior. Would you be open to failing under these conditions instead?

.taskcluster.yml Outdated
$map:
$if: event.ref == 'refs/heads/master'
then:
{config: [{name: firefox, channel: nightly}, {name: chrome, channel: dev}]}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll need to remove {config: ...} and render the array values directly

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Separately, the $match operator might make this section more readable:

$if: tasks_for == "github-push"
then:
  $map:
    $flatten:
      $match: {
        event.ref == "refs/heads/master": [{name: firefox, channel: nightly}, {name: chrome, channel: dev}],
        event.ref == "refs/heads/epochs/daily": [{name: firefox, channel: beta}, {name: chrome, channel: beta}],
        event.ref == "refs/heads/epochs/weekly": [{name: firefox, channel: stable}, {name: chrome, channel: stable}]
      }
  each(browser):

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't do that because it's not exhaustive, but if/else is. I agree that $match is more readable, but I don't know what the right tradeoff is. Maybe I shouldn't care about handling every case since hitting a case that isn't handled here resulting in a runtime error would be fine.

"nightly": "latest",
}
if channel not in branch:
raise ValueError
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above regarding error message

@jugglinmike
Copy link
Contributor

Also can we document how to set something up to test TC changes?

The .taskcluster.yml file currently includes the following:

# Contributors interested in configurating TaskCluster to run
# against their fork of WPT should change the `workerType` to
# "github-worker".
workerType: wpt-docker-worker

I'm open to suggestion for improving this. Do you think more of an explanation
is necessary? Maybe instruction to enable the TaskCluster GitHub app? Or maybe
we should move this elsewhere--the top of the file, or a dedicated page in the
docs directory?

@jgraham
Copy link
Contributor Author

jgraham commented Aug 28, 2018

Regarding using experimental/stable, I don't think that quite works because we have three states; nightly, beta and stable. In fact for Chrome there are four states; canary, dev, beta and stable. Running stable and beta gives us the ability to test version N+1 and version N simultaneously (assuming that beta and stable are both using the same configuration which is more or less true for gecko at least).

I think that latest/beta/stable would be a sufficient ontology to cover our needs (although I'm not exactly sure how Edge and WebKit/Safari fit in there). In terms of actual command line arguments, if we expect people to run this generally I would prefer to be liberal in what we accept rather than forcing people to learn a specific set of nomenclature (e.g. I would happily accept all of experimetal, nightly, dev, preview, latest to mean whatever the most up to date version of the browser is (dev is perhaps the least appealing since Firefox has a developer edition that isn't quite the same thing). And equally I would happily accept stable, release, and other synonyms used for the stable channel.

@jgraham
Copy link
Contributor Author

jgraham commented Aug 29, 2018

https://tools.taskcluster.net/groups/KkY09Cj_QKO4A2JPHUyn_Q is a run starting from a `epochs/daily' push on my fork.

@Hexcles
Copy link
Member

Hexcles commented Aug 29, 2018

Alright, so first of all the installation part looks good to me.

We don't currently have the infra for pushing epochs/* refs, right? And I imagine it would be some cron job that pushes these refs based on @mdittmer 's revision announcer?

Lastly, while you're at it, could you add browser_channel to wptrunner.wpttest.RunInfo so that we can include it in wptreport.json? This is very useful information that we can't always reliably get from version strings of all browsers.

@jgraham
Copy link
Contributor Author

jgraham commented Aug 29, 2018

@foolip created some infrastructure for pushing to the epochs branches; see e.g. https://github.com/web-platform-tests/wpt/tree/epochs/daily

@wpt-pr-bot wpt-pr-bot added the wptrunner The automated test runner, commonly called through ./wpt run label Aug 29, 2018
.taskcluster.yml Outdated
@@ -4,10 +4,16 @@ policy:
tasks:
$if: tasks_for == "github-push"
then:
$if: event.ref == "refs/heads/master"
$if: event.ref == "refs/heads/master" || event.ref == "refs/heads/epochs/daily" || event.ref == "refs/heads/epochs/weekly"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With the introduction of $match, this condition is no longer necessary.

@ghost
Copy link

ghost commented Aug 30, 2018

Submitting the task to Taskcluster failed. Details

bad indentation of a mapping entry at line 15, column 13:
each(browser):
^

@jgraham
Copy link
Contributor Author

jgraham commented Aug 31, 2018

@foolip
Copy link
Member

foolip commented Aug 31, 2018

Exciting! I guess that wasn't triggered by a branch update, but otherwise is the same as what we want?

@jgraham
Copy link
Contributor Author

jgraham commented Aug 31, 2018

It wasn't but I can do that too if you like. I had an earlier run that was triggered by a branch update so I'm pretty sure that works, I was mostly checking my refactoring didn't break the yml file entirely.

The channel derived from the binary turns out to not always be reliable.
Also we were using an incorrect tagging scheme for beta prefs, so we tried
to download a file that didn't exist. To prevent clashes store downloaded firefox
and its prefs in channel-specific directories.
@jgraham
Copy link
Contributor Author

jgraham commented Sep 4, 2018

@jugglinmike Added some more help text.

Copy link
Member

@Hexcles Hexcles left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just got one question regarding the --browser-version argument.

version, channel_ = self.get_version_and_channel(binary)
if channel is not None and channel != channel_:
# Beta doesn't always seem to have the b in the version string, so allow the
# manually supplied value to override the one from the binary
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, really? This is good to know. It's yet another reason why we need to include channels in wptreport.json. Currently the receiver infers the channel from the version string, which according to this comment is apparently unreliable.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I only found this out when writing this patch :) I think what happens is that shortly before release the beta switches to the actual release config and so gets a release-like version string. But I"m not sure.

'nightly': latest_channels,
'dev': latest_channels,
'preview': latest_channels,
'experimental': latest_channels,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I suppose "preview" might be used for the future Safari support, perhaps?

@@ -192,6 +192,12 @@ def create_parser(product_choices=None):
help="Path to directory containing extra json files to add to run info")
config_group.add_argument("--product", action="store", choices=product_choices,
default=None, help="Browser against which to run tests")
config_group.add_argument("--browser-version", action="store",
default=None, help="Informative string detailing the browser "
"release version. This is included in the run_info data.")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my earlier change, I added this to wpt/run.py:

kwargs['browser_version'] = setup_cls.browser.version(kwargs.get("binary"))

Would it always override the command line argument?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. But we can remove that in a future patch.

jgraham and others added 3 commits September 5, 2018 11:41
This (ab)uses mozdownload to grab the common.tests.tar.gz package from the
latest nightly build and extracts geckodriver from that. The main disadvantage
is that it's rather slow since the package itself is rather large and we want
only a small part of it. The solution to this would be to package up
geckodriver by itself on taskcluster, but that will require changes in the
gecko buildsystem.
Install nightly geckodriver when testing Firefox nightly.
@jugglinmike jugglinmike merged commit 32fc9a3 into master Sep 6, 2018
@jugglinmike jugglinmike deleted the tc_epoch branch September 6, 2018 15:49
Hexcles added a commit to web-platform-tests/wpt.fyi that referenced this pull request Sep 7, 2018
This change makes the results processor to save the merged report
instead of just the last chunk of the report if the original report is
chunked when uploaded.

Besides, it also sets the channel label (stable/experimental) based on a
new property in the report, `run_info.browser_channel`, introduced in
web-platform-tests/wpt#12679 .
@foolip
Copy link
Member

foolip commented Sep 8, 2018

Oh cool, this is merged! epochs/daily currently points to 9a5d71b and I see that we had beta results:
https://tools.taskcluster.net/groups/dMjbBGL-TPu9z6TuZYzonw

However, I can't find the regular (experimental) results. Did beta run instead of experimental?

$map:
$flatten:
$match: {
event.ref == "refs/heads/master": [{name: firefox, channel: nightly}, {name: chrome, channel: dev}],
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The answer to my question is probably here, but I can't interpret it. Pushes to master and pushes to epochs/* will be separate events, but they will be the same sha. Does Taskcluster do something to avoid retesting the same sha? Or is it perhaps just task group triggered by push to master is now hidden in GitHub's UI? @Hexcles, if that is the case, will your integration code be able to find both after the fact, or will it only work if we react to the webhooks as the runs are happening?

Copy link
Contributor Author

@jgraham jgraham Sep 10, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The answer is actually at https://api.github.com/repos/web-platform-tests/wpt/commits/9a5d71b326166e12784bdd9d161772e20f87c1fd/statuses There are two success statuses with context Taskcluster (push), one with the URL https://tools.taskcluster.net/groups/dMjbBGL-TPu9z6TuZYzonw and one with the URL https://tools.taskcluster.net/groups/FFjitCXpQ2C4fD_7O7gPeA

GitHub groups by context so it only displays one run in the UI. AFAIK there isn't a way to have the TaskCluster tasks get different GitHub context values (possibly we could add that feature?) so we can still get at all the results even thought we can't seee them all.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool, thanks! The epochs/weekly branch currently points to 9614def, and the statuses API does include three runs: stable, beta and dev.

@Hexcles, is that the API you use to find Taskcluster runs?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My code listens to the "status" webhook events, whose payload is similar to that API. There'll be two separate updates in this scenario and my code will run twice. Therefore, all Taskcluster runs will be uploaded as long as the status is "success", regardless of how GitHub UI displays them and whether they are on the same revision.

Hexcles added a commit to web-platform-tests/wpt.fyi that referenced this pull request Sep 11, 2018
When the uploader does not provide the channel label
(stable/experimental), the processor will now set it based on a new
property in the report, `run_info.browser_channel`, introduced in
web-platform-tests/wpt#12679 .
Hexcles added a commit to web-platform-tests/wpt.fyi that referenced this pull request Sep 12, 2018
When the uploader does not provide a channel label, the processor will
now set it based on a new property in the report,
`run_info.browser_channel`, introduced in
web-platform-tests/wpt#12679 .

A new channel label, "beta", is also introduced in this commit, since we
now have beta browsers running on Taskcluster daily.
@whimboo
Copy link
Contributor

whimboo commented Sep 13, 2018

@jgraham are we creating artifacts especially for the logs? If not yet, what is the follow-up issue to get this integrated?

@jugglinmike
Copy link
Contributor

Log files are available for all builds. They can be downloaded via the TaskCluster UI or via the command ./wpt tc-download (more detail on that is available from the --help argument).

@whimboo
Copy link
Contributor

whimboo commented Sep 13, 2018

@jugglinmike I tried but I cannot find any log for https://tools.taskcluster.net/groups/ccZFTpXgQ1CqBIHft81eXQ which was triggered by #12968. Taskcluster doesn't list any artifacts nor logs.

@whimboo
Copy link
Contributor

whimboo commented Sep 13, 2018

Oh, wait. That is actually a task group! Navigating to a single test job I can see the artifacts now. So all is fine.

@Hexcles
Copy link
Member

Hexcles commented Sep 13, 2018

@whimboo https://tools.taskcluster.net/groups/ccZFTpXgQ1CqBIHft81eXQ/tasks/DuJQTji0QomkUiTD3q3CCg/runs/0/logs/public%2Flogs%2Flive.log

You need to select a task in the group first. Then you'll see some logs in the "Run Logs" dropdown.

By the way, this particular example had no "affected tests", so no tests ran.

Hexcles added a commit to web-platform-tests/wpt.fyi that referenced this pull request Sep 14, 2018
When the uploader does not provide a channel label, the processor will
now set it based on a new property in the report,
`run_info.browser_channel`, introduced in
web-platform-tests/wpt#12679 .

A new channel label, "beta", is also introduced in this commit, since we
now have beta browsers running on Taskcluster daily.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci docker infra testharness.js wpt wptrunner The automated test runner, commonly called through ./wpt run
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants