Track Task-related activities #1810
Conversation
There was a problem hiding this comment.
@jgerigmeyer I'm working on tests and the API endpoints now, but the feature is functionally ready for review (Task history is viewable via the admin)
| pr = self.validated_data["pull_request"] | ||
| if self._is_opened(): | ||
| instance.finalize_pr_opened(pr_number, originating_user_id=None) | ||
| instance.finalize_pr_opened(pr, originating_user_id=None) | ||
| elif self._is_merged(): | ||
| instance.finalize_status_completed(pr_number, originating_user_id=None) | ||
| instance.finalize_status_completed(pr, originating_user_id=None) | ||
| else: | ||
| instance.finalize_pr_closed(pr_number, originating_user_id=None) | ||
| instance.finalize_pr_closed(pr, originating_user_id=None) |
There was a problem hiding this comment.
We now pass a full pr object to the finalize_* methods to have access to both the title and number (and other things if we ever need them in the future).
| TESTER_ACCEPTED = "Tester accepted" | ||
| TESTER_ASSIGNED = "Tester assigned" | ||
| TESTER_UNASSIGNED = "Tester unassigned" | ||
| DEV_ACCEPTED = "Developer accepted" |
There was a problem hiding this comment.
TESTER_ACCEPTED and DEV_ACCEPTED are not used yet but they are in place for the future invitation system
| @property | ||
| def branch_url(self) -> Optional[str]: | ||
| if self.branch_name: | ||
| return f"{self.root_project.repo_url}/tree/{self.branch_name}" | ||
| return None | ||
|
|
||
| @property | ||
| def branch_diff_url(self) -> Optional[str]: | ||
| base_branch = self.get_base() | ||
| branch = self.branch_name | ||
| if base_branch and branch: | ||
| return f"{self.root_project.repo_url}/compare/{base_branch}...{branch}" | ||
| return None | ||
|
|
||
| @property | ||
| def pr_url(self) -> Optional[str]: | ||
| if self.pr_number: | ||
| return f"{self.root_project.repo_url}/pull/{self.pr_number}" | ||
| return None |
There was a problem hiding this comment.
These properties were previously defined in the serializer but we need them to log Task activity so they were moved to the model
|
@jgerigmeyer I'm undecided on what's the best way to expose the TaskActivities to the frontend. We can add an Another option is to give the activities their own endpoint and filter by Task. That seems cleaner but we would then need a mechanism to handle list-based WS subscriptions (drf-live, which we haven't installed on Metecho yet). |
@jerivas I think I'd lean toward a separate endpoint. With our current setup, those WS events could be fired on the task-detail channel anyway, and if/when we switch to drf-live we could use their list channel. But I don't think we'll get to the front-end for this story until February at the earliest (given other priorities and limited budget), so this is probably good enough for now and we can resolve it then? |
|
@jgerigmeyer it looks like we're clear to start working on this again. I still need to fix merge conflicts and add endpoints for the new |
@jerivas Yes, that sounds right to me! |
|
@jgerigmeyer I added the endpoints and WS events for |
Steps to test/reproduce
/api/task-activities/. This endpoint can be filtered by?task=:idTASK_ACTIVITY_LOGGEDevent will be dispatched in the Task's websocket channelNote: you will need to configure GitHub webhooks as explained in CONTRIBUTING.rst for the "Submit pull request" and "Merge pull request" events to be tracked propertly.
Show me