Refactor Treeherder's branch model#9496
Conversation
4f9489f to
fa96c6e
Compare
|
Alright, a couple notes for the reviewer:
|
fa96c6e to
43aaae6
Compare
|
The changes will be applied to the prototype instance in the next 30 minutes. |
|
Deployment to prototype failed with: |
|
@Archaeopteryx so the problem is that Then I need to understand how the deploys work to figure out the proper fix. Does If so, then I think the migration just needs to not convert existing branches to If not, Claude suggests we add a line to Wdyt? |
|
Possibly answered my own question. Assuming this is what runs during migrations: It looks like we always call
I'll update this PR and we can try again. |
43aaae6 to
21a1056
Compare
21a1056 to
9003b67
Compare
|
I updated this PR such that instead of This will allow us to fix a request from the firefox-ios team. |
9003b67 to
9833a18
Compare
When pushing a new branch to Github, the base revision is empty ("0" *
40). When we passed this into the `comapre_shas` function, it was
raising a 404 error.
Instead we now detect the commits from the Github webhook payload
(`body["commits"]`). Github caps this list at 20 commits, so if the push
exceeds this, not every commit in the push will exist in the DB. This
isn't a problem for the UI because the frontend also caps commits at 20.
But there are certain Treeherder APIs that might misbehave.
The alternative would be to compare the head_sha against the default
branch. Github automatically finds the merge base here, so it would
provide an accurate list of commits in the push. But the catch is it
assumes the push was based on the default branch. For a case like try
where a developer makes a try push based off of `beta`, the compare
endpoint would return every commit on beta since it branched off.
With that in mind, using the commits listed in the webhook payload feels
like the lesser of evils.
Each transformer can have its own bespoke logic for resolving a repository. So instead of having an if/else at the call site, move this logic onto a helper method of the transformer itself for cleaner code.
…yBranch model The Repository model has a "branch" field, which means repositories are inherently tied to single branch. It was likely designed this way because we colloquially called Mercurial repos "branches", so there was a 1:1 mapping of branches to repositories. But as Github repos started getting added, this was obviously no longer the case. To support Github, we started adding hacks that overrode the "branch" field. We turned it into a comma separate list that gets parsed by a regex to support multiple branches. We added the string "pull request" to support pull requests. This worked, but it's inherently limiting. For example, pushes that match the comma separated regex lose the information of which branch they actually matched. This is valuable information that Treeherder could be using in its UI and API. Instead, we can store branches in a separate table in the DB. This decouple branches from repository in the model and allows for more sophisticated configurations. It will also make it easier to implement "wildcard" support for branches, which will be needed for "try-like" repositories.
bf0e83a to
d868be0
Compare
As part of the Gecko2Github migration, we need a way for Treeherder to display _all_ pushes to certain repositories in order to support an equivalent to "try".
d868be0 to
f77a091
Compare
|
This change is currently deployed to prototype. Here's And here's |
This makes backend changes to better support complex mappings between projects and repositories / branches: