GitHub Actions Workflow

Introduction

In this week's focus on enhancing the development process for Learn2Blog, I delved into the realm of Continuous Integration (CI) by implementing a GitHub Actions Workflow. Continuous Integration pipelines and workflows are pivotal in modern software development, providing automated checks and balances to ensure code quality and stability.

Setting Up the Workflow

To start, I turned to the starter-workflows repository, a valuable resource housing diverse YAML files for various project types. My project being in .NET, I checked out the dotnet.yml file to get insights into the setup process. Understanding the YAML syntax and keywords like on, push, jobs, and steps is crucial for crafting an effective workflow. In my case, I wanted to the workflow to trigger "on" any "pushes" on the main branch. The job describes the specific task which can be given a name, and steps outline the necessary steps to run the job.

You can also go the Actions tab on your main repository page and and select new workflow from the menu on the left hand side. GitHub will recommend some templates for you based on your project. You can always modify it to your specific needs.

Drawing inspiration from another open-source project, explore-cli, I learned how to tailor the workflow to accommodate the nested structure of my tester project. This involved specifying the path to the test .csproj file, a key adjustment for successful execution.

My workflow encompasses several essential steps:

• Checking out the latest code from the main branch.
• Setting up the .NET environment.
• Restoring dependencies (which ensures that the project has all the necessary packages)
• Building the application.
• Running the test files

For a detailed view of the workflow, refer to the dotnet.yml file.

Hiccups Along the Way

Just when everything seemed to be working fine, an unexpected challenge arose. While the workflow passed when I ran it, a contributor's pull request triggered failures in seemingly unrelated tests. Despite the contributor's newly added test passing, other existing tests failed mysteriously. Investigating this remains something I had to leave behind for the time being and come back to it later, and the pull request is temporarily on hold. But if you know why, please let me know in the comments!

Contributing to Node-TILify

Beyond my project, I also contributed to Node-TILify, a similar project by my friend @sdthaker. Although I have an aversion to JavaScript [cue laugh emoji], he threw me a challenge my way. Testing his workflow seemed like a good gig!

There are of course many differences between Jest and xUnit. I am fairly familiar with Jest as I have worked with it in the past, so setting up a new test for him was not particularly difficult. I would say working with xUnit has actually been more challenging since I am very new to it.

Conclusion

To wrap it up, Continuous Integration (CI) plays a pivotal role in safeguarding code quality and stability. Whether you're an external contributor or the project's main developer, CI systems act as a safety net, significantly reducing the likelihood of errors. Setting up CI for your project, ideally at an early stage, is a worthwhile investment in the long-term reliability and health of your codebase.