Improve docs for try server with non-tip mozilla-central changeset

Open
#61 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
55/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Stale
Domain
documentation

Research direction

Start with the linked try-server documentation section, “Testing Mozilla-central patches,” and compare its instructions with the issue’s .gecko_rev.yml example. Add guidance for testing a non-tip mozilla-central changeset, including GECKO_HEAD_REV and the requirement to commit the file; done means the scenario and resulting workflow are documented clearly.

Written by the indexing model from the issue text.

Description

Yesterday comm-central was busted when I did a try server run (which failed due to the bustage). I followed the docs to redo the try run with a mozilla-central changeset that was earlier than the one that busted comm-central. The docs could be improved for this use case.

The relevant docs are here, but they cover a different use case, and didn't work for me when I tried to follow them. I had to get some help on IRC, and what I ended up having to do is not what was described in the docs.

All I had to do was add a GECKO_HEAD_REV line to my .gecko_rev.yml file so it looked like this:

GECKO_BASE_REPOSITORY: https://hg.mozilla.org/mozilla-unified
GECKO_HEAD_REPOSITORY: https://hg.mozilla.org/mozilla-central
GECKO_HEAD_REF: default
GECKO_HEAD_REV: 7faec8e0996bce01fdd1bb9f1b2a1c60045de16c

One thing I didn't realize, since these docs don't mention it, is that you have to commit your changes to the .gecko_rev.yml file for them to take effect on the try server.

Since bustages are still common, I think it would be worth having a different section in the docs to cover this scenario.

Dominant language
No language data
Stars
114
Forks
86
Avg merge
2h 37m
Merged PRs (30d)
1

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from thunderbird/developer-docs

All issues in thunderbird/developer-docs

Similar issues

More Documentation issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.