Delving into open source territory with Google: PR #2

Project repo:

blockly-samples by Google Open Source.

Project description:

Blockly by Google Open Source is a JavaScript library for building visual programming editor, which looks something like this,

The project I worked on is called blockly-samples which is a supplementary project to the Blockly project. This project holds code for 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 which are self-contained sample projects demonstrating techniques on how to use Blockly's features and extend the Blockly library and Codelabs which are interactive tutorials demonstrating how to use and customize Blockly.

Issue

1977

PR

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, 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 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,

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, following conventional commit specification for commit messages, rebasing the branch onto latest master due to out of sync packages which were failing the Node build and formatting the code.

This was my first time writing GitHub Actions. Its documentation helped me a lot in understanding and breaking down every task that I wrote part of this PR. The issue also mentioned looking at a similar job setup in another repository found here.

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 within the section called "Measuring progress from 0.2 release".