Delving into open source territory with Google: PR #2
Tags: webdev, javascript, programming, opensource
Published: 2023-11-10 19:49:40

## Project repo:
[blockly-samples](https://github.com/google/blockly-samples) by _Google Open Source_. 

## Project description:
[Blockly](https://developers.google.com/blockly) by _Google Open Source_ is a JavaScript library for building visual programming editor, which looks something like this,
>![blockly sample](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/prrqvx0ssmvxdyhvan7b.png)

The project I worked on is called [blockly-samples](https://github.com/google/blockly-samples) which is a supplementary project to the Blockly project. This project holds code for [Plugins](https://github.com/google/blockly-samples/tree/master/plugins) which are _self-contained pieces of code that add functionality to Blockly. Plugins can add fields, define themes, create renderers, and much more_, [Examples](https://github.com/google/blockly-samples/tree/master/examples) which are _self-contained sample projects demonstrating techniques on how to use Blockly's features and extend the Blockly library_ and [Codelabs](https://github.com/google/blockly-samples/tree/master/codelabs) which are _interactive tutorials demonstrating how to use and customize Blockly._

## Issue
[1977](https://github.com/google/blockly-samples/issues/1977)

## PR
[2060](https://github.com/google/blockly-samples/pull/2060)

## Code Fixes
This issue was about adding a feature, specifically GitHub Actions workflow that checks for formatting errors and prints out a human-friendly message and a list of unformatted files. The script `npm run format:check` to run this task was already set, part of the [package.json file](https://github.com/google/blockly-samples/blob/master/package.json#L19), which in turn runs `prettier --check .`. However, I had to research a bit about what are GitHub Actions and how to set it up.

GitHub Actions can be used for building a piece of software or aid in deploying it. They are set up within a root folder called `.github` containing a folder called `workflows`. For example, if we take a look at the project I worked on, it has a [build.yml](https://github.com/google/blockly-samples/blob/master/.github/workflows/build.yml) file located within `/.github/workflows` which defines a workflow of what it's supposed to do. This workflow lints, builds and tests the repository.

A workflow is a configurable automated process that will run one or more jobs. Workflows are defined by a YAML file checked into a repository which can be given a name, which in this case is `name: Build and Test` and will run when triggered by an event in the repository, which in this case is `on: [pull_request]`. 

A job is a set of steps in a workflow that is executed on the same runner. Each step is either a shell script that will be executed or an action that will be run. Steps are executed in order and are dependent on each other. When a new PR is created this workflow will run with 3 jobs namely `build`, `lint` & `format`. 

This was the job I added to the existing build workflow,

>![format workflow](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/5gn3zkldmfvvaa4ozws4.png)

### Breaking down the job:

* `format:`: This is the name of the job. It's used to identify the job in the GitHub Actions UI.

* `timeout-minutes: 5`: This sets a timeout for the job. If the job runs for longer than 5 minutes, it will be automatically cancelled.

* `runs-on: ubuntu-latest`: This specifies the type of runner that the job will run on. In this case, it's the latest version of Ubuntu.

* `steps:`: This is a list of steps that the job will execute. Each step is an individual task that contributes to the job.

   * `uses: actions/checkout@v2`: This step uses the checkout action at version 2 to checkout the repository's code onto the runner.

   * `name: Setup node`: This step sets up a Node.js environment on the runner. It's given the name "Setup node" for clarity in the GitHub Actions UI.
   
   * `uses: actions/setup-node@v3`: This uses the setup-node action at version 3 to set up the Node.js environment.

   * `with:`: This is used to pass parameters to the setup-node action.

      * `node-version: 20`: This specifies that the Node.js version to be set up should be version 20.

   * `name: Npm Install`: This step installs the npm packages required for the project. It's given the name "Npm Install" for clarity in the GitHub Actions UI.

   * `run: npm install`: This runs the command npm install to install the npm packages.

   * `name: Check Format`: This step checks the format of the code. It's given the name "Check Format" for clarity in the GitHub Actions UI.

   * `run: npm run format:check`: This runs the command npm run format:check to check the format of the code.

Besides, post issuing a PR, there were some small issues to take care of, like signing up for Google's  [Contributor License Agreement](https://cla.developers.google.com/clas), following [conventional commit specification](https://www.conventionalcommits.org/en/v1.0.0/) for commit messages, [rebasing the branch onto latest master](https://github.com/google/blockly-samples/pull/2060#issuecomment-1799281362) due to out of sync packages which were failing the Node build and [formatting the code](https://github.com/google/blockly-samples/pull/2060#issuecomment-1799535262).

This was my first time writing GitHub Actions. Its [documentation](https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions) helped me a lot in understanding and breaking down every task that I wrote part of this PR. [The issue also mentioned](https://github.com/google/blockly-samples/issues/1977#issue-1913896095) looking at a similar job setup in another repository [found here](https://github.com/google/blockly/blob/fd873507eba5c2e587bc2156398edc09e88b84d1/.github/workflows/build.yml#L70).

Besides, I have an upcoming lab to set up GitHub Actions on my project and learnings from this PR have already laid the foundation for that lab. Also, this is a proud moment for me knowing that every time someone is going to create a PR on this project, a code that I wrote on a “_Google_” project, will trigger a GitHub Action to check for their PR's formatting issues. 

As far as gauging progress from 0.2 to 0.3 release is concerned, I promised myself to dive deeper into new avenues of software development and this PR is an ideal example of that. Besides, other things I focused on in this release are covered in [first blog of this series](https://dev.to/sdthaker/delving-into-open-source-territory-with-google-pr-1-3gkk) within the section called _"Measuring progress from 0.2 release_".