Forem: Ali Ahsan

This Week in Commits History (GitHub Action)

Ali Ahsan — Thu, 17 Sep 2020 23:25:55 +0000

My idea was to have something like Facebook's "On this day" or Snapchat's Memories from today and apply it to a repository. So I started working on this action "Week-History-Action." I figured doing it every day would be another daily spam, so I went along with doing it weekly.

This action gathers the commits applied to the repo every week and packages them in an email. Every Monday, at 7 AM, the cron job runs, leveraging GitHub's API; every commit from the current date until seven days from now in history gets collected.

So let's say your repository is two years old and today is Monday, 17th Sept 2020. The action will find commits from 17th Sept 2019 to 23rd Sept 2019 and 17th Sept 2018 to 23rd Sept 2018. All the commits fitting the timeframe will get sent to the interested users via email. For email, I'm using NodeMailer. Currently, the committer's name, email, and date are gleaned along with the commit message.

This action is still a work in progress. The initial goal was to complete it by 17th Sept 2020, the deadline of the GitHub Actions Hackathon on DEV.

Unfortunately, due to numerous reasons, this is not complete. I'm merely sharing here for some thoughts from the community. During the development, I realized this might not be a useful action, so I would like to know if someone is interested in developing this with me going forward. This is the repo for those who are interested:

aliahsan07 / Week-History-Action

This Week in Commits History

So let's say your repository is two years old and today is Monday, 17th Sept 2020. The action will find commits from 17th Sept 2019 to 23rd Sept 2019 and 17th Sept 2018 to 23rd Sept 2018. All the commits fitting the timeframe will get sent to the interested users via email. For email, I'm using NodeMailer. Currently, the committer's name, email, and date are gleaned along with the commit message.

This action is still a work in progress. The initial goal was to complete it by 17th Sept 2020, the deadline of the GitHub Actions Hackathon on DEV.

…

View on GitHub

The features are incomplete that will be implemented in the coming days, to name a few:

The email template to send has to be crafted, it's currently rudimentary, and I had trouble setting up a nice HTML table.
Configurable options i.e, to limit the number of commits the user gets, if plentiful commits were made in a week might not be wise to send everyone in the mailbox. Also, a notion of "useful" commit would be beneficial so that only the most important commits are sent.
It's not runnable as of yet; I encounter this issue today:

! [remote rejected] main -> main (refusing to allow an OAuth App to create or update workflow `.github/workflows/main.yml` without `workflow` scope)

This also needs to be addressed.

Its a bummer I couldn't complete the action, but I'm glad I got to work on an action and understand what's going on behind the hook. (Lesson learned: Just start early from next time.)

A Primer on GitHub Actions

Ali Ahsan — Fri, 21 Aug 2020 20:22:48 +0000

DEV is running a GitHub Actions Hackathon till 17th September, so I figured this might be the right time to dive deep in GitHub Actions.

GitHub Actions automate the custom workflows inside of GitHub. Kyle Daigle, the director of ecosystem engineering at that time of launch, described Actions as "GitHub running code on your behalf for the first time" on a Changelog podcast. This line will make more sense when we go over a few examples, but this definition alone should give you some idea about how powerful this feature can be.

One common use case is sending a message in a Slack channel when code is pushed to a repository. The action gets triggered when code is pushed, or it could be when a pull request is created. Similarly, there is an action that reminds the reviewers on Slack to merge the pull request. What is seemingly a simple task has quite an impact as recounted by the creator of Pull Reminders himself. Pinging everyone on slack to merge a pull request is a tedious task and might need multiple rounds of messages before every reviewer approves the request. The action automated the reminders thus ensuring speedier review and merge of code (and this is how GitHub is running code for you).

Using an action in your codebsase

The hackathon folks at Dev are running is looking for developers to build an action. This can be achieved in multiple ways; the two most common are:

Docker container actions
JavaScript actions

Right now, I'm going over how to use an existing action (tonnes of GitHub actions present in the marketplace) in your codebase.

To configure a workflow inside your repository, create a YAML file inside (.yml/.yaml) inside the .github/workflows directory. The official documentation delineates how to create an action and the various properties that are associated with it. I'll give a small example and discern the key components of it.

The following configuration sets up a unit suite to run whenever a pull request is created against the master branch on a node application. (Full Disclosure: The snippet is inspired by this Youtube Video)

name: Node Unit Tests

on:
  pull_request:
    branches:
      - master

jobs:
  test:
    name: Running Unit Tests
    runs-on: ubuntu-latest

    steps:
    uses: actions/checkout@v2
    name: Use Node.js ${{ matrix.node-version }}

    uses: actions/setup-node@v2
    with:
      node-version: ${{ matrix.node-version }}
    - name: installing dependencies
      run: npm install
    - nam: running tests
      run: npm test

name defines the title of the GitHub Action.
on is required, which specifies the GitHub event that triggers the workflow. In this example, a pull request to the master branch stimulates the proceedings.
jobs make up a workflow. They run in parallel by default. Here, we have one job we call test. Inside it, we name the job Running Unit Tests. It's running on ubuntu-latest container. This is followed by the steps the workflow carries out.
uses refers to the action we're using, the first action is actions/checkout@v2 which checkouts your repository so that your workflow can access it. The next step is more interesting in which we use actions/setup-node@v2 action to install node dependencies and run npm test. The name gets printed whenever the corresponding step starts executing, so it's imperative to write meaningful names. installing dependencies and then running tests will give the user a good sense of how the flow is executing. Both of the actions used in this example are open-source.

Using an existing action in your codebase is usually very straightforward. Let's say you want to delete a branch when the pull request is merged from that branch—a fairly common use case, which prevents the accumulation of unused branches. There is an action Delete merged branch in the marketplace that you can use for it. The YAML file can be as follows:

  name: Delete merged branch
  uses: SvanBoxel/delete-merged-branch@v1.3.3

That's it, that takes care of branches merged into your codebase. I just had to visit the repo of the action and copy this small snippet to make it work. Of course, you can modify the workflow to suit your needs but this gets the ball rolling for a very minimal setup.

What's next?

As we move towards the hackathon deadline, I'm searching the web and brainstorming ideas about possible useful action. You're allowed to use any open source technology to build your own GitHub Action, which makes the competition more broad and exciting. I intend to write next on what goes on under the hood and convey a better understanding of the internals. For now, I'm focusing on building a badass GitHub Action that will win me the grand prize 🤩

(This post originally appeared on https://aliahsan.tech/github-actions)

Covid Relief Pakistan

Ali Ahsan — Fri, 01 May 2020 03:46:05 +0000

Category: COVID-19 Communications

The arrival of the holy month of Ramadan coincides with the worst days of the virus in Pakistan.

Authors

The actual Idea

Initially, the scope of the project was broader and rather ambitious. We wanted to build an application that essentially synchronizes the relief operations on a city level in Pakistan such that the charities divide the regions(of a city/district) amongst themselves and only distribute ration there. Our portal would show where each charity/NGO operated. What this would have meant is a more efficient and egalitarian solution to the food crisis problem.

But this turned out to be a difficult task mainly due to two reasons:
1) The complexity of the task: Ensuring such synchronicity and collaboration would mean operating from the ground, communication with relevant authorities: charities, local governments, public perhaps. It was simply not feasible, so we had to limit our scope.
2) The lack of time on our hands: We couldn't invest as much time as we would have liked and had to constrict the scope of the project.

What we actually built

Covid Relief Pakistan is a web portal that gives the user an option to select a city from the dropdown and view charities operating there. This would show a list of exclusive charities working in that city as well as those working nationwide. If the user is interested in more details about the charity/NGO, they have the option to subscribe for more details. This is where the Twillio SMS API comes in. Once the user provides us their phone number, we send them relevant details about the selected charity.

A sample message is as follows:

Charity Name: Shahid Afridi Foundation
website: https://shahidafridifoundation.org/donatekarona/
Contact Number: Not Provided
EasyPaisa: Not Provided
Bank Details are as follows
Account Title: Shahid Afridi Foundation
Bank Name: Habib Bank Limited
Account Number: ----------
IBAN: ----------------

Users can also contribute by filling out a Google form that can be accessed by clicking the Add Charity Button. We are manually vetting the data that we get from the form to ensure authenticity.

Link to Demo

The project is deployed on heroku:
Demo

Link to Code

Github Repository

Tech Stack

Frontend

React (create-react-app)
Google Maps React
Downshift
SCSS

Backend

Node
Express
Twillio API

Other Technologies

GitHub for Repository Management
Heroku for deployment
Notion for Project Management

Discoveries/Reflections from Project

Experimented with downshift for the first time. A convenient library to build dropdowns and store state.
Had issues integrating WhatsApp API, so stuck with the messaging Twillio API only. Twillio has done an amazing job in maintaining and documenting their APIs, their starter codes are beneficial, and if you play along enough, you realize you can achieve a lot with them (that's the intention). That's our submission to the Twillio API hackathon, a nice and simple node app with React frontend. All the best, everyone!