I have a codebase that has around nine hundred links in it. It's called Every Link I Wish I Had as a Beginner, and it's a compilation of links that helped me to learn more as a developer. Inside there are links to educational resources about software paradigms, encoding, encryption, learning new programming languages, along with others.
But I was worried that in a year or two, link rot would leave me with a codebase filled with broken links. Checking them all manually was out of the question—there were way too many.
When I researched to find a solution for running code on an automated schedule, I found developers recommending GitHub Actions as a solution. (Later in the blog I'll tell you a secret alternative that overcomes GitHub Actions shortcomings.)
GitHub Actions is an automation tool offered by GitHub that allows you to run workflows on a user-determined schedule.
In my case, I could write a super-simple Node.js script to retrieve the links from my text file and check that they all still worked. All I'd need to do is make a network request to the URL, and then check the HTTP status code that returned. If it returned an HTTP 404 or similar, I would know the link was a candidate to be removed from my repository. Perfect.
GitHub Actions here essentially operates via an Infrastructure as Code (IaC) process. IaC is uses code configuration files, such as YAML files, to provision computer resources to the developers requesting them.
This is the YAML file I created:
```
# This workflow will do a clean install of node dependencies, cache/restore them, build the source code and run tests across different versions of node
# For more information see: https://help.github.com/actions/language-and-framework-guides/using-nodejs-with-github-actions
name: Node.js Link Rot prevention
on:
schedule:
- cron: '0 0 1 * *'
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [16.x]
# See supported Node.js release schedule at https://nodejs.org/en/about/releases/
steps:
- uses: actions/checkout@v2
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v2
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
- run: npm install
- run: node ./index
- run: git config --local user.email "41898282+github-actions[bot]@users.noreply.github.com"
- run: git config --local user.name "github-actions[bot]"
- run: git add broken.txt
- run: git commit -m "GitHub actions link rot prevention"
- name: Push changes
uses: ad-m/github-push-action@master
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
branch: ${{ github.ref }}
```
The code above is a request to GitHub to allocate me a server to action my code on a specific day and time.
There are multiple ways to trigger your request for servers using GitHub Actions.
The example above uses cron to tell GitHub when you want this Action to run. cron is a command-line utility to schedule jobs in a Unix-like environment. You can specify the minute, hours, day of the month, month, and day of the week you need the job to run on.
Workflows can also be triggered by events. A full list of events that can be used to trigger GitHub Actions can be found here, but some of the more common are:
- When someone deletes a Git branch or tag.
- Whenever someone deploys.
- When a discussion in your repository is created or modified.
Now I run my Node script on the first day of each month and send all the non-responsive links to a text file that a bot automatically commits into my repo. I then double-check them manually, and it takes me less than a minute.
This was great and fixed my problem. I've been able to remove several dead links since I started this workflow, which has helped improve the quality of the feature or code.
GitHub Actions is a simple way to run code at a periodic time.
You've already looked at one use case, but developers worldwide use GitHub Actions for a huge variety of tasks, such as closing stale pull requests, automatically linting a codebase, doing deployments, and running integration or unit tests and running security scans.
The Actions are language agnostic, so while the example above used Node, there's no need to use a specific language. This means that almost any code you can package into an executable script can be run via GitHub Actions, which covers a huge number of use cases—anything that makes sense for your business to automate.
GitHub Actions offer a number of benefits, too. The Actions are easily repeatable, and they run on GitHub's servers, which are pretty resilient—GitHub even posts availability reports. GitHub is also owned by one of the biggest tech companies in the world, so neither they nor Actions are likely to disappear, forcing you to abruptly migrate.
No software solution is perfect, and while GitHub Actions can be a solution for many problems, there are also some drawbacks to consider.
Although YAML isn't incredibly complex, it's still a potential hurdle for new users. There are tools that generate the YAML for you, which means you probably won't have to write it. But if complex pipeline needs to be constructed with security and quality gates with thresholds, it requires in-depth knowledge on the YAML.
GitHub Actions isn’t friendly to people who aren't already technically strong. There's no GUI, and it's not a low- or no-code solution, which makes it significantly less accessible for people who don't already have solid coding skills, or who simply don't want to learn YAML.
Reading through the docs can be intimidating, and there's a level of technical knowledge assumed that many people don't have—or need to have.
If you have the technical skills to be able to make full use of GitHub Actions, it’s worth considering. Even if you can sort out the GitHub Actions config, you're still going to need to write custom code to run, which is one more thing to write, debug, and maintain.
When I made my GitHub Action, I lost a lot of time debugging an issue with it. The machine that was running my Action was Unix based, and the terminal was case-sensitive—but my local machine is Windows, where the terminal isn't case-sensitive.
When it was run locally, my Node script worked fine. But my GitHub Action kept failing to run, and it took me hours to discover why. It's easy to make a tiny mistake, like using a lowercase letter when you should've used a capital one, and lose hours debugging, even though the actual error takes only a second to fix.
The observability, feedback cycles, and logs are all something that could be improved. It’s hard to have visibility into the actions to see exactly what is causing the failure. I needed to log multiple times in the file, then wait for it to run again to debug.
You can't run extremely compute-heavy jobs on GitHub Actions, as its max execution time per job is six hours.
While not a common issue, it is one that some users have encountered. The only real way to resolve it is to break up your script, change providers, or self-host your infrastructure.
Opsera is a continuous orchestration tool. Opsera solves problems similar to the ones that GitHub Actions does, but with some simple and notable improvements.
Opsera was created due to the founders' frustration with the way that software teams were forced to rely on manual coding integrations or use single-vendor solutions that lock you in. Opsera empowers developers by enabling them to use any tool, any stack, any platform.
Opsera can help users avoid many of the limitations of GitHub Actions.
Opsera is a platform for everyone: developers, non-technical staff, and executives. Knowledge of YAML shouldn’t bar people from building the tools they need, which is why Opsera allows users to create no-code pipelines from a point-and-click graphical user interface (GUI). You can add security gates and quality control with thresholds and approvals, all from the GUI they offer—no coding required. By removing the need-to-know YAML, a no-code platform allows more people to contribute, so you can draw from a wider talent base instead of looking for people with specific niche skill sets.
Opsera allows you to choose your own tools, and they can take care of the rest. This approach is far more declarative and allows you to focus on what to build—not how to build it. You can stop writing glue or custom scripts and select the tools that will provide the most value without worrying about vendor lock-in or how they'll fit into your existing stack. All the above frees up time so your developers focus on more important tasks.
My GitHub Actions bug left me debugging for hours, but Opsera was built with end-to-end visibility in mind. Pre-built diagnostics, delivery analytics, auditing, and compliance are all observability metrics provided by Opsera, enabling you to run your automated toolchains quicker.
GitHub Actions doesn't offer observability metrics, but Opsera offers a multitude of them. Including a comprehensive analytics suite with over 100 KPIs to enable you c make smarter decisions at every stage of your software development lifecycle. All these metrics can be accessed on a native CLI that's similar to kubectl, which is why site reliability engineers love Opsera.
You've looked at some common problems that can be solved by using software solutions like GitHub Actions and how Opsera, a continuous orchestration tool, can be used to solve these problems without requiring any coding or specialized knowledge. To learn more about Opsera, you can explore their resources center, which is full of blog posts, case studies, webinars, and videos to learn more about how no-code DevOps can improve your workflows.
