Generally speaking, an off-line hackathon event takes place with people getting together at the same time and place for about two to three nights, intensively. On the other hand, all events have turned into online-only nowadays, and there's no exception for the hackathon events either. To keep the same event experiences, hackathon organisers use many online collaboration tools. In this case, almost the same number of event staff members are necessary. What if you have limited resources and budget and are required to run the online hackathon event?
For two weeks, I recently ran an online-only hackathon event called HackaLearn from August 2, 2021. This post is the retrospective of the event from the event organiser's perspective. If anyone is planning a hackathon with a similar concept, I hope this post could be helpful.
In May 2021 at //Build Conference, Azure Static Web Apps (ASWA) became generally available. It's relatively newer than the other competitors' ones meaning it is less popular than the others. This HackaLearn event is one of the practices to promote ASWA. The idea was simple. We're not only running a hackathon event but also offering the participants learning experiences with Microsoft Learn to participants so that they can feel how convenient ASWA is to use. Therefore, all participants can learn ASWA and build their app with ASWA – this was the direction.
In fact, the first HackaLearn event was held in Israel, and other countries in the EMEA region have been running this event. I also borrowed the concept and localised the format for Korean uni students. With support from Microsoft Learn Student Ambassadors (MLSA) and GitHub Campus Experts (GCE), they review the participants pull requests and external field experts were invited as mentors and ran online mentoring sessions.
As mentioned above, running a hackathon event requires intensive, dedicated and exclusive resources, including time, people and money. However, none of them was adequate. I've got very limited resources, and even I couldn't dedicate myself to this event either. I was the only one who could operate the event. Both MLSAs and GCEs were dedicated for PR reviews and mentors for mentoring sessions. Automating all the event operation processes was the only answer for me.
How can I automate all the things?
For me, finding out the solution is the key focus area throughout this event.
There were a few constraints to be considered.
- No Website for Hackathon
🚨 There was no website for HackaLearn. Usually, the event website is built on a one-off basis, which seems less economical.
👉 Therefore, I decided to use the GitHub repository for the event because it offers many built-in features such as Project, Discussions, Issues, Wiki, etc.
- No Place for Participant Registration
🚨 There was no registration form.
👉 Therefore, I decided to use Microsoft Forms.
- No Database for Participant Management
🚨 There was no database for the participant management to record their challenge progress.
👉 Therefore, instead of provisioning a database instance, I decided to use Microsoft Lists.
- No Dashboard for Teams and Individuals Progress Tracking
🚨 There was no dashboard to track each team's and each participant's progress.
👉 So instead, I decided to use their team page by merging their pull requests.
I've defined the overall business process workflow in the following sequence diagrams. All I needed was to sort out those limitations stated above. To me, it was Power Platform, GitHub Actions and Microsoft 365 with minimal coding efforts and maximum outcomes.
All of sudden, the limitations above have become opportunities to experiment with the new process automation!
- The event itself uses the GitHub repository, meaning all PRs and issues can be handled by GitHub Actions.
- Microsoft 365 services like Microsoft Forms and Microsoft Lists are used for data input and storage.
- Power Automate is one of the Power Platform services and is used for the core of process automation.
So, the GitHub repository and Microsoft 365 services are fully integrated with GitHub Actions workflows and Power Automate workflows. As a result, I was able to save a massive amount of time and money with them.
The first automation process I worked on was about storing data. The participant details need to be saved in Microsoft Lists. When a participant enters their details through Microsoft Forms, then a Power Automate workflow is triggered to process the registration details. At the same time, the workflow calls a GitHub Actions workflow to create a team page for the participant. Here's the simple sequence diagram describing this process.
The overall process is divided into two parts – one to process participant details in the Power Automate workflow, and the other to process the details in the GitHub Actions workflow.
Let's have a look at the Power Automate part. When a participant registers through Microsoft Forms, the form automatically triggers a Power Automate workflow. The workflow checks the email address whether the participant has already registered or not. If the email doesn't exist, the participant details are stored to Microsoft Lists.
Then it generates a team page. Instead of creating it directly from the Power Automate workflow, it builds the page content and sends it to the GitHub Actions workflow. The
workflow_dispatch event is triggered for this action.
Finally, the workflow sends a confirmation email. In terms of the name, participants may register themselves with English names or Korean names. Therefore, I need logic to check the participant's name. If the participant name is written in English, it should be
[Given Name] [Surname] (with a space; eg. Justin Yoo). If it's written in Korean, it should be
[Surname][Given Name] (without a space; eg. 유저스틴). The red-boxed actions are responsible for identifying the participant's name. It may be simplified by adopting a custom connector with an Azure Functions endpoint.
As mentioned above, the Power Automate workflow calls a GitHub Actions workflow to generate a team page. Let's have a look. The
workflow_dispatch event takes the input details from Power Automate, and they are
As GitHub Marketplace has various types of Actions, I can simply choose one to create the team page, commit the change and push it back to the repository.
Now, I've got the registration process fully automated. Let's move on.
In this HackaLearn event, each participant was required to complete six challenges. Every time they finish one challenge, they MUST update their team page and create a PR to reflect their progress. As there are not many differences between the challenges, I'm going to use the Social Media Challenge as an example.
Here's the simple sequence diagram describing the process.
- After the participant posts a post to their social media, they update their team page and raise a PR. Then, a GitHub Actions workflow labels the PR with
review-requiredand assigns a reviewer.
- The assigned reviewer checks the social media post whether it's appropriately hashtagged with
- Once confirmed, the reviewer adds the
review-completedlabel to the PR. Then another GitHub Actions workflow automatically removes the
review-requiredlabel from the PR.
- The reviewer completes the review by leaving a comment of
/socialsignoff, and the comment triggers another GitHub Actions workflow. The workflow calls the Power Automate workflow that updates the record on Microsoft Lists with the challenge progress.
- The Power Automate workflow calls back to another GitHub Actions workflow to add
completed-sociallabels to the PR and remove the
review-completedlabels from it.
- If there is an issue while updating the record, the GitHub Actions workflow adds the
review-requiredlabel so that the assigned reviewer starts review again.
As described above, there are five GitHub Actions workflow used to handle this request.
The GitHub Actions workflow is triggered by the participant requesting a new PR. The event triggered is
pull_request_target, and it's only activated when the changes occur under the
If the PR is created later than the due date and time, the PR should not be accepted. Therefore, A PowerShell script is used to check the due date automatically. Since the PR's
created_at value is the UTC value, it should be converted to the Korean local time, included in the PowerShell script.
If the PR is over the due, it's immediately rejected and closed.
If it's before the due, label the PR, leave a comment and randomly assign a reviewer.
The assigned reviewer confirms the challenge and labels the result. This labelling action triggers the following GitHub Actions workflow.
/socialsignoff for the social media post challenge automatically triggers the following GitHub Actions workflow, with the event of
The first step of this workflow is to check whether the commenter is the assigned reviewer, then find out which challenge is approved. The
review-completed label MUST exist on the PR, and the commenter MUST be in the reviewer list (
If all conditions are met, the workflow takes one action based on the type of the challenge. Each action calls a Power Automate workflow to update the record on Microsoft Lists, send a confirmation email, and calls back to another GitHub Actions workflow.
This GitHub Actions workflow completes the challenge, triggered by a Power Automate workflow through the
workflow_dispatch event. Power Automate sends values of
The first action is to add labels to the PR and remove labels from the PR.
And finally, this action merges the PR. If there's an error on the Power Automate workflow side, the
isMeargeable value MUST be
false, meaning it won't execute the merge action.
The challenge approval workflow calls this Power Automate workflow. Firstly, it checks the type of challenges. If no challenge is identified, it does nothing.
If the challenge is linked to the registered participant's GitHub ID, update the record on Microsoft Lists; otherwise, do nothing.
Finally, it sends a confirmation email using a different email template based on the number of challenges completed.
Previously described Power Automate workflows are triggered by GitHub Actions for integration. However, there are other workflows only for management purposes. As most processes are similar to each other, I'm not going to describe them all. Instead, it's the total number of workflows that I used for the event, which is 15 in total.
Now all my business processes are fully automated. As an operator, I can focus on questions and PR reviews, but nothing else.
The HackaLearn even was over! Here are some numbers related to this HackaLearn event.
14: Number of days for HackaLearn
171: Total number of participants
62: Total number of participants who completed Cloud Skills Challenge
21: Total number of teams who uploaded social media posts
17: Total number of teams who completed building Azure Static Web Apps
16: Total number of teams who completed provided their GitHub repository
20: Total number of teams who published their blog post as a retrospective
13: Total number of teams who completed all six challenges
Surely, there are many spaces for future improvement. What I've learnt from the automation exercise are:
- Do not assume the way participants create their PRs is expected
👉 The review automation process should be as flexible as possible.
- Make the review process as simple as possible
👉 The reviewers should only be required to focus on the PR, not anything else.
- Reviewer should be assigned to a team instead of individual PRs
👉 If a reviewer is assigned to a team, the chance for merge conflicts will dramatically decrease.
- Make Power Automate workflows as modular as possible
👉 There are many similar sequence of actions across many workflows.
👉 They can be modularised into either sub-workflows or custom APIs through custom connectors.
- Live Hands-on: GitHub Actions (in Korean)
- Live Hands-on: Azure Static Web Apps (in Korean)
- Live Hands-on: Azure Static Web Apps with Headless CMS (in Korean)
So far, I summarised what I've learnt from this event and what I've done for workflow automation, using GitHub Actions, Microsoft 365 and Power Automate. Although there are lots of spaces to improve, I managed to run the online hackathon event with a fully automated process. I can now do it again in the future.
Specially thanks to MLSAs and GCEs to review all the PRs, and mentors who answered questions from participants. Without them, regardless of the fully automated workflows, this event wouldn't be successfully running.