DEV Community

Aastha Shrivastava
Aastha Shrivastava

Posted on • Edited on

How I used github workflow to recognize community contributions(Part-1)

Recently Developer Circles Facebook has concluded its Open Source Immersion Program, and we at DevC Pune thought to make a repository to recognize all the PRs made by the community during this program and decided to make a repository which has leader-board for the same, but collecting all the data was difficult and there comes GitHub workflows to the rescue which made ease the process of collecting data about PR and publishing on the repository. Enough with the stories! Let's talk about what we actually did.

Before starting let's understand what is a workflow and how it works.

What is a GitHub Workflow?

A GitHub Workflow is a mechanism used for automating your projects life cycle, remember event handling in other languages like Java, JavaScript etc? Yep this is the same just with GitHub events.

  • Instead of onClick, onHover etc we have events like: PR opened, Issue opened, Issue edited etc.
  • When an event occurs, the workflow has a list of jobs to be executed, in a job we can do some processing, and use some actions, which are just like functions in our regular programming language.

How does a GitHub Workflow works?

Every workflow needs to have a .yml which contains various sections of identifying the event and list of jobs reacting based upon the event. The yml file can even call another script to do some processing. When a job is executed it creates an instance of you repo on cloud, like a docker image, and now this is instance is just like a copy of your repo on a local machine, once you are done with processing you have to push the changes back to GitHub to see the changes. So you can use this instance to to perform anything which you do on your terminal.

Creating a yml file

  • In the first line we have to specify the name of the workflow:
name: add-project
# This workflow gets executed when someone opens an issue for adding a project
Enter fullscreen mode Exit fullscreen mode

You can also add some comment to describe what that workflow is doing.

  • We can define an event on which a workflow will be triggered like this:
on:
  issues:
      types: [opened,edited]
Enter fullscreen mode Exit fullscreen mode

Now comes the list of jobs, we can define a job as:

jobs:
  add_project_job:
    if: startsWith(github.event.issue.title, 'add|')
    name: add-project
    runs-on: ubuntu-latest
    steps:
Enter fullscreen mode Exit fullscreen mode

Here add_project_job is the name of job. We can also specify condition which decides if certain job will be executed or not.
The runs-on parameter specify the environment which will be created to run the job. Next we have to define steps which will be executed inside a job.

And that is the basic structure of a GitHub workflow. We'll discuss the whole workflow in detail in the next part! Till then keep automating!

References:

Official Documentation
Link to Full Code

Top comments (0)