Continuing on from last post, I'm adding more types of stages to the stages module which contain the actual implementation of quests. This is an exciting time because after all the framework building, this is finally where the core of what LGTM is begins to emerge. Again, most of the work is now in the stages module, the code for this post is at commit 0e67f0d
Sending comments
The previous post describes the CreateIssueStage() which creates an issue. But we also need to be able to create comments, so I have a viry similar-looking CreateIssueCommentsStage(). The reason it's comments plural is because this stage allows me to define a whole conversation that takes place in the comments section between two different accounts. Makes it easy to convey narrative through a conversation.
class CreateIssueConversationStage(Stage):
""" This stage posts multiple comment to an existing issue to a user's fork """
@property
@abstractmethod
def character_comment_pairs(cls) -> List[Tuple[Character, str]]:
""" Pairs of characters and comments to post """
return NotImplemented
@property
@abstractmethod
def issue_id_variable(cls) -> int:
""" Variable containing the ID of the issue to use """
return NotImplemented
# variable to store last comment ID in for later
comment_id_variable: Optional[str] = None
# variable to store datetime of comment
comment_datetime_variable: Optional[str] = None
def execute(self) -> None:
""" Post the issue to the fork """
game = self.quest.quest_page.game
game.load()
fork_url = game.data.fork_url
issue_id = getattr(self.quest.quest_data, self.issue_id_variable)
logger.info("Creating comments", issue_id=issue_id, fork_url=fork_url)
for character, body in self.character_comment_pairs:
comment_id = character.issue_comment_create(fork_url, issue_id, body)
if self.comment_id_variable:
logger.info(
"Storing comment Id in variable",
comment_id=comment_id,
variable=self.comment_id_variable,
)
setattr(self.quest.quest_data, self.comment_id_variable, comment_id)
if self.comment_datetime_variable:
setattr(
self.quest.quest_data, self.comment_datetime_variable, datetime.now()
)
In the CreateIssueStage() we created an issue and stored the issue_id in the quest data model. This stage now reads that ID, as it's needed for it to decide which issue to post in.
It simply loops through a list of character and text tuples to post each comment in turn. It additionally stores the last comment's comment_id in the quest storage as well as its post time. The reason for this is in case we have another quest stage that needs to detect emoji reactions to a comment. The comment post time can be used to fetch comments from that date onwards, to avoid seeing older comments no longer relevant to this stage.
Checking for replies
The final piece of the puzzle needed to build the most basic form of quest, is to detect a response from a user. This type of quest will ask the user to "find out" something in a git repository or the history or metadata, and the user must respond with an answer. We have to be able to detect the correct answer returned, so this stage checks for user replies:
class CheckIssueCommentReply(Stage):
""" Check issues for reply """
@property
@abstractmethod
def character(cls) -> Character:
""" Which character will do the check and reply, character needs permission for the repo """
return NotImplemented
@property
@abstractmethod
def regex_pattern(cls) -> Pattern:
""" Compiled regex pattern using re.compile() """
return NotImplemented
@property
@abstractmethod
def issue_id_variable(cls) -> int:
""" Variable containing the ID of the issue to use """
return NotImplemented
# A list of possible responses
incorrect_responses: List[str] = []
# variable to store matching group values in
result_groups_variable: Optional[str] = None
# variable to store matching id in in
result_id_variable: Optional[str] = None
# variable to get check since from
comment_datetime_variable: Optional[str] = None
def fast_condition(self) -> bool:
"""If hasn't been run before, run once, otherwise fail to avoid hitting github API too much,
letting notification scan process run this quest when it receives a notification"""
if self.get_stage_data() is None:
return self.condition()
return False
def condition(self) -> bool:
""" Check messages """
game = self.quest.quest_page.game
game.load()
fork_url = game.data.fork_url
user = game.parent
user.load()
user_id = user.data.id
issue_id = getattr(self.quest.quest_data, self.issue_id_variable)
# use either last runtime (saved in stage data), or otherwise last comment datetime variable provided
check_datetime = datetime.utcfromtimestamp(self.get_stage_data(0))
if self.comment_datetime_variable is not None:
check_datetime = max(
check_datetime,
getattr(self.quest.quest_data, self.comment_datetime_variable),
)
logger.info(
"Fetching comments",
user_id=user_id,
issue_id=issue_id,
fork_url=fork_url,
check_datetime=check_datetime,
)
if check_datetime is None:
comments = self.character.issue_comment_get_from_user(
fork_url, issue_id, user_id
)
else:
comments = self.character.issue_comment_get_from_user_since(
fork_url, issue_id, user_id, check_datetime
)
logger.info("Got comments", count=len(comments))
self.set_stage_data(datetime.now().timestamp())
for comment_id, comment_body in comments.items():
results = self.regex_pattern.match(comment_body)
if results:
logger.info("Got comment match on pattern!", comment_id=comment_id)
if self.result_groups_variable:
setattr(
self.quest.quest_data,
self.result_groups_variable,
results.groups(),
)
if self.result_id_variable:
setattr(self.quest.quest_data, self.result_id_variable, comment_id)
return True
# issue incorrect response
if len(comments) and self.incorrect_responses:
comment_id = self.character.issue_comment_create(
fork_url, issue_id, random.choice(self.incorrect_responses)
)
return False
At the core of this is the regex_pattern. This stage will simply run the provided regex pattern against all comments seen since the last check or the last post date provided, and when it matches, the condition passes.
Some of the code also deals with minimizing how many comments need to be checked, by only searching from the date this stage was last run (using the stage data store facility), or the last post date provided from the quest data store.
There's also some extra code that relate to capturing the result. This could be useful if we ask the player a question like "which do you pick?" and want to store the result. We can use this to check for a reply and then store the matched group in the quest data storage.
Finally, we can also randomise the response when there's a comment that doesn't match. So the usage looks like this:
class CheckNumber2(CheckIssueCommentReply):
children = ["ReplyGroup2"]
character = character_zelma
regex_pattern = re.compile(
r"(?<!\d)2(?!\d)"
) # exactly 42, no digits either side
issue_id_variable = "issue_id"
comment_datetime_variable = "last_comment"
incorrect_responses = [
"No, it wasn't that",
"Try again, that's not it",
"Oh, we would have known if it was that, try again",
"It must be something different, try again",
"Can't have been that, please check again",
]
Here, we are looking for the exact number 2 The regex pattern (?<!\d)2(?!\d) uses negative lookbehind and lookahead to avoid matching the number 2 inside other numbers, for example 12 would not be matched.
The comment_datetime_variable is a value set by the previous stage; and issue_id_variable is set by the first stage that creates the issue.
The result:
Quest types and further plans?
We now are sufficiently feature-complete to author the first type of quest on LGTM, which I'll be calling a "Type 1" quest for lack of better terminology. I think we can split the quest types (and this could govern future dev plans) into:
- Type 1: the player looks for a specific information or value in git (e.g. what was the last commit? who made this change?) and respond with a comment in the issue with the value that we can check for
- Type 2: perhaps this will be when we actually ask a player to deal with a Pull Request or merge (e.g. help merge these two branches! Help resolve this merge conflict!) and requires the player to actually deal with merges into a branch. To do this, we'll need to be able to raise PRs, as well as read files after a commit to see if they got it right
- Type 3: perhaps this will be when we ask the player to actually make commits, eprhaps even branches, raising PRs, and even force-pushes?
Top comments (0)