eba34f5d12
* Bug 1910864 - Return None for profiler urls instead of "N/A" Perfherder frontend has a check if the profiler urls are null, but it doesn't check if it's "N/A" or not. That's why this was causing us to see all the invalid links in the perfherder when user clicks on "Copy Summary" or file a bug directly through perfherder. By changing this to `None`, this API endpoint will return `null` to the frontend, which can successfully understand and omit. * Bug 1887138 - Refactor how we compute the profile urls on the backend There were two issues with how we compute the profile urls in the backend: 1. When we encounter an error, we were returning an error string. This is not good because frontend doesn't know how to handle the error strigs and it thinks that they are simply urls. Then it was trying to append the error strings on the back of profiler urls, which was causing invalid urls in the perf alerts. 2. We had a caching mechanism for the taskcluster metadata. But this caching mechanism wasn't really caching things by adding task id to the cache key. This was resulting a single cache for the whole "push" or multiple pushes. We were caching the latest metadata, and use that last metadata for all the alerts, which is wrong because all individual alerts might have differnet metadata. The good thing is, the taskcluseter metadata was already available to us inside the `alert` variable since we computed it prior this function. So we didn't have to do anything special, just read that from the dictionary. There is one remaining piece I would like to fix still, which is how we cache `tc_root_url`. But that's actually okay for now because a single push should only have one `tc_root_url`. And I'm not so sure how to pass that information to the other function where we genereate the profile urls. |
||
|---|---|---|
| .circleci | ||
| .github | ||
| bin | ||
| deployment/gcp | ||
| docker | ||
| docs | ||
| misc | ||
| requirements | ||
| schemas | ||
| tests | ||
| treeherder | ||
| ui | ||
| .codecov.yml | ||
| .eslintignore | ||
| .eslintrc.js | ||
| .git-blame-ignore-revs | ||
| .gitattributes | ||
| .gitignore | ||
| .markdownlint.json | ||
| .markdownlintignore | ||
| .pre-commit-config.yaml | ||
| .prettierignore | ||
| .prettierrc.js | ||
| .readthedocs.yml | ||
| .renovaterc | ||
| .yarnrc | ||
| CODEOWNERS | ||
| CODE_OF_CONDUCT.md | ||
| LICENSE.txt | ||
| README.md | ||
| babel.config.json | ||
| docker-compose.yml | ||
| initialize_data.sh | ||
| jest-puppeteer.config.js | ||
| jest.config.js | ||
| manage.py | ||
| mkdocs.yml | ||
| newrelic.ini | ||
| package.json | ||
| pylintrc | ||
| pyproject.toml | ||
| setup.cfg | ||
| tox.ini | ||
| version.json | ||
| webpack.config.js | ||
| yarn.lock | ||
README.md
Treeherder
Description
Treeherder is a reporting dashboard for Mozilla checkins. It allows users to see the results of automatic builds and their respective tests. The Treeherder service manages the etl layer for data ingestion, web services, and the data model behind Treeherder.
Instances
Treeherder exists on two instances: staging for pre-deployment validation, and production for actual use.
Installation
The steps to run Treeherder are provided here.
The steps to run only the UI are provided here.
Links
Visit our project tracking Wiki here.
For other setup and configuration, visit our readthedocs page here.
File any bugs you may encounter here.
Contributing
Everyone is welcome to contribute!
If a bug is not assigned to someone, you can request the bug be assigned to you. You should ask the component owner with your request ("Request information" in Bugzilla and mention in Github).
If you do not receive a response within 2-3 days, you can follow up in the #treeherder matrix channel.
After addressing the issue, make sure every test passes before sending a pull request.
We also recommend setting an upstream remote that points to the Mozilla's Github repo, in addition to origin that points to your fork. You should then frequently use git rebase upstream rather than merging from your fork to keep your branch current. There are less conflicts this way and the git history is cleaner.
Sending a Pull Request
We receive contributions from both Bugzilla and Github. We have some specifications to keep track of them:
-
If your bug comes from Bugzilla
After addressing the issue, please send a pull request to this repository, with the Bugzilla's number ID in the title, so that our bot attaches your patch to the corresponding Bugzilla bug.
"Bug xxxxxx - [title of the bug or brief explanation]"For example: "Bug 123456 - Fix scrolling behavior in Perfherder"
-
If your bug comes from Github
In the description of the pull request, please mention the issue number. That can be done by typing #[issue's number].
For example: "This pull request fixes #5135".
Github automatically links both issue and pull request to one another.