DEV Community: Takshak Ramteke

🗿 Get Some (Github) Action

Takshak Ramteke — Mon, 15 Aug 2022 17:50:18 +0000

Github Actions, If you haven't heard already then please allow me tell you calling it amazing would be an understatement !

I personally think, It is one of those once in a decade things that endup having a super huge impact on the whole industry,

GitHub Actions is one of those things that just perfectly embodies rule 34(for devs), think anything of the top of your head and there's a high chance that there's a github action made for it already.

And Im not joking either, there's literally a github action for everything you may need e.g.

[x] Deploying a next.js app to github pages,
[x] making automatic releases,
[x] greet a new contributor,
[x] setting up entire dev enviornment, And much more !

And So today in this blog i'd like to ask you to come along with me on a little adventure, as we go through some stuff about github actions and dare i mention try creating one of our very own github action,

And if you hadn't already guessed by the big image, yes we'll be having ourselves some docker goodness as well, So without further ado, lets begin

What is a Github Action ?

Well on the surface "GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline."

But as you may guess there's more to it than that Github actions goes beyond just the realm of devops and allows us to run workflows in our repo when some or the other event occur

Now when talking about Github Actions, we should also talk about

The Components of Github Actions

There are two componets to a github actions

an Action, which is the action itself and
a Workflow, which is a automated processes that uses an action

A workflow can contain one or more set of different actions which are run in their own seprate containers either in parallel or in the specified sequence

now since we've discussed the components of github actions, It's only fair to have a look at

Types of Github Actions

As of now there are only two types of actions

Container actions : These are the actions that use a Dockerfile, These allow the enviornment to be packaged with github action code and can only be executed in github Hosted linux enviornments, needless to say this is the one we'll be looking at today.
JavaScript actions : Yet another implementation of JS, these type of actions decouple the github actions code from the enviornment allowing faster execution but accepting greater dependency management responsibility.

This was all just a small intro about Github actions, if you want to learn more about it in depth i recommend checking out the docs

Now That we have some background knowledge of what a Github action is, Let's start by setting up our first & very own github action

(spoiler alert it takes only 5 steps to do so)

ps. create a new empty repo before you start following along

Step 1 : Adding a Dockerfile

In the newly created repo create a docker file with the following contents in it

FROM debian:9.5-slim

ADD index.sh /index.sh
RUN chmod +x /index.sh
ENTRYPOINT ["/index.sh"]

A Dockerfile is like a blueprint to our container that is going to run our code for this action, i recommend you do this on a seprate branch from main

Here at line 1 we tell github that the base image for this pirticular action should be debian which is a linux distro then further ahead
We tell it to use the index.sh script as the entrypoint into our action

You might be wondering why bash, well the reason for that is, We don't have any extra programs on debian image other than the essential linux programs (like seriously not even curl is intalled in there),

Step 2 : Adding the entrypoint script

Now in the same directory as the dockerfile create a index.sh script with the contents you want to execute, I've just keet it simple for the sake of simplicity in this blog
please I encourage you to experiment with this yourself

#!/bin/bash

echo "message : $INPUT_MESSAGE"

If you can't tell already, all this line does is print out what ever the value of INPUT_MESSAGE is simple, we'll pass in this variable when we use this action inside of a workflow

Step 3 : Adding some metadata for our action

To add this metadata we'll have to create a yaml file, this file act's as a sort of configuration file for our action. Also it's in here that we'll specify an input parameter in order to read MESSAGE

So go ahead and create a action.yml file in the same folder as the other two files, with the following content's in it :

name: "get some github action"
description: "An action to get some github action"
author: "TakshakRamteke@users.noreply.github.com"

inputs:
  MESSAGE:
    description: "Message to print out"
    required: true

runs:
  using: "docker"
  image: "Dockerfile"

While I personally think most of this is self explanatory, the super important things to look out for are the inputs and runs,

As you can probably tell in the inputs section we're setting up the MESSAGE variable that we used previously in our bash code, here you can define as many inputs as you want and you can also provide a default value for them if you want to

As for the runs section, this is where we define how this action is supposed to be run e.g. in this one we tell it to run using docker and use the Dockerfile to build our image

Step 4 : Add a workflow

Now as we discussed earlier, in order to run a action we'll need to use it inside of a workflow

To do that we need to create a yml file inside of the .github/worlflows/ directory, So go ahead and create the aforementioned folder and inside of that create a .yml file and add the following content into it, (i called mine getsome.yml btw)

name: "A workflow to get some github action"
on: push

jobs:
  builds:
    name: Get some github action
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v1
      - uses: ./action
        with:
          MESSAGE: "GOT SOME GITHUB ACTION 🏆"

Here, the first line is just the name that we want to give our action and it goes without saying that you can name it whatever you want

the next line tho is where we specify the event on which this action to trigger on, for this one we keep it simple and just use the push event, which simply means that the action/workflow will run whenever something is pushed onto this branch, there are quite a lot of triggers that you can chose from tho,

The next section is where all the magic happens, this part is called the action block and it is in here that we provide info on how to run our action, here's a little breakdown of this section

jobs: is the base component of a workflow
build: is the identifier we're attaching to this job, you can name it however you like, i called it build because it builds our docker image 🤷
name: is the name of the job, this is displayed on GitHub when the workflow is running
runs-on: defines the type of machine to run the job on. By default it is run on a GitHub-hosted runner, you can specify your own as well tho.
steps: are the linear sequence of operations that make up a job, simple
uses: actions/checkout@v1 uses a community action called checkout to allow the workflow to access the contents of the repository
uses: ./action provides the relative path to the action you created in the action directory of your repository
with: is used to specify the input variables that will be available to your action in the runtime environment. In this case, the input variable is MESSAGE and i've assigned it a value of "GOT SOME GITHUB ACTION 🏆"

That's basically a high level overview of each key that we use in this current workflow, not to mention there are quite literally ton of more other option that you can use

Now onto our last step which is

Step 5 : Trigger your workflow

As the final step there isn't much to do here but make sure that if you've been following along At this point you're tree should something like so :

.
|-- .github
|   `-- workflows
|       `-- getsome.yml
|-- action
|   |-- Dockerfile
|   |-- action.yml
|   `-- index.sh
`-- readme.md

If it is then well done, all that's left to do is to stage and commit these changes and push them to github

As soon as you do that navigate to the actions tab on you github repo and there you should see a an action running, click on it to see the action you just created in action and it should look something similar to this :

If you see something similar to this, then Congratulations 🥂 you've just made your first github action

Although it is quite the basic and we barely scratched the surface i highly encourage you to check out the Github actions docs to learn more about it,

The reason i wrote this blog is that i personally had quite a lot of fun building it and so i thought is should share it with others as well, Hope you folks liked and enjoyed it to and as always wish to see you in the next one 👋

oh btw please feel free to checkout the github repo for this one, I'll be adding some more examples there soon

🌐 Around the headless landscape : Introduction

Takshak Ramteke — Mon, 25 Jul 2022 17:51:00 +0000

Hey !!!, Glad to see you there, as you might have guessed this is sort of a little introduction blog for a blog series that i started called Around the Headless landscape

In this series, we'll embark on a little adventure (whoo) where we'll have a look around all the majour headless cms providers and play with them to see how we can integrate them into our applications (next.js for me)

So take out your laptops, strap on your seatbelts and get ready, because this one is going to be a lot more fun than you'd expect...

But wait... If you're new around headless CMS space, Don’t worry i’ve got you covered 🙃, lets first quickly go over Some basic stuff

So what even is a headless CMS ?, well good question

Let's say our friend edward over here finally found the treasure, now after all these year's of being a space cowboy, he finally want's to settle down & with all that money he want's to start his own ship business (fair enough ig 🤷‍♂️)

Now for obvious purposes edward also want's to have a website for his business, now edward is a smart kid in his early day's he had learned a lot about computer science and to no ones surprise has awesome frontend skills

but unfortunately he ain't no good with backend stuff, just making api call's and that's all he know's about backend

Now in this situation edward can easily levrage some traditional content management system (CMS) like wordpress. He can just, find a suitable theme, slap on some cool plugins, configure some stuff and tada he's got a fully functional website

except there's a teeny-tiny problem here, edward's partner faye doesn't really like the look and feel of wordpress because of multiple reasons the biggest of which is limited customisability to the frontend

now here's the main

Problem with Traditional CMS

you see when using traditional CMS you're (generally) locked in with a particular set of frontend and backend with little to no wiggle room at all, e.g. just like in the case with Wordpress the flexibility with frontend is kinda limited

and that's where a

Headless CMS Come's In

The whole point of a headless CMS is to have a seprate backend that act's as a single source of truth for all your content which is accessible via some api call's

This way you can have whatever frontend you want to or even better display the same content on various platform via native apps

So now all edward has to do now is to swap out wordpress with a headless cms provider for backend and he's pretty much good with any frontend that suit's him well

💡 TL;DR

A headless CMS is one seprate backend that act's as a single source of truth for all your content which is accessible via some api call's as compared to a traditional CMS where everything is coupled together

And that is pretty much as you'd need to know about a headless cms as long as you are familiar with frontend and making some api call's

I will be using JavaScript (TypeScript) for the most part, but please feel free to switch that around however you see fit, after all the logic is going to be the same as always

and that wrap's up this blog, well have a much more in depth look at every single headless provider in the further episodes of the series until then

Please let me know if you have any questions in the comments and

Thank you very much for reading this blog, hope to see you in the next one ✌️

🧪 E2E tests made easy with Cypress + Cucumber

Takshak Ramteke — Fri, 01 Jul 2022 17:50:28 +0000

If you're a developer I'm pretty sure end to end testing is something you've heard about a lot

While it may “sound” like daunting task at first what if i tell you that there is a relatively easy way to implement it…

Feature : Test redirection

Scenario : Test the redirect 
    Given that im on "Home" page
    When i click "#redirect"
    Then i should see "Redirected" as "h1"

What you read just now is a fully functional test written in what is called a Gherkin syntax used by Cucumber which is a BDD testing tool and its open source ofcourse

But Cucumber on it's own isn't really capable of doing E2E tests And That's where Cypress comes in to save the day

Now, that's fine and all but

How exactly do we do it you may ask

Well apparantly its quite the simple process thanks to the magic✨ that's open source and the hardwork of badeball who created the

cypress-cucumber-preprocessor 🔥 which if you couldn’t guess already allows us to use cucumber along side cypress

now as you might expect (almost) nothing in the tech industry works without a bit of configuration and this tool is no exception, though the good thing is that it is pretty simple to configure and as a matter of fact it can be done in 3 super easy steps

Step 1 : Install all the dependencies

ofcoure 🤷 duh we’d have to do this one & it’s kinda self explanatory, you only need to install a few things i.e cypress, @badeball/cypress-cucumber-preprocessor, esbuild and lastly cypress-esbuild-preprocessor

To do so simply run the following command and watch it complete

yarn add --dev cypress @badeball/cypress-cucumber-preprocessor esbuild cypress-esbuild-preprocessor typescript

npm install --save-dev cypress @badeball/cypress-cucumber-preprocessor esbuild cypress-esbuild-preprocessor typescript if that’s your thing

now you can throw in Typescript (💜) into this if you want to which I obviously did, but it’s totally optional & upto you

Step 2 : Generating the basic configuration

Now that we have all what we need let’s start the actual configuration but here’s the plot twist,

Initially though you will not have the basic cypress configuration, to generate it simply run

yarn cypress open or npx cypress open if npm’s your thing

And follow the dialogs to configure the e2e testing and that should give you a basic configuration that we need

Step 3 : The Actual Configuration

Okay this time for sure

Now that we have all the basic configuration we need lets start by telling cypress to use the .feature files (that’s the extension for a test written with cucumber), To do that all we need to do is specify the “specPattern” property in the cypress.config.ts (or .js if youre using js)

import { defineConfig } from "cypress";

export default defineConfig({
    e2e:{
        setupNodeEvents(on, config){
            //
        },
        specPattern: "**/*.feature",
    }
})

Now that that’s out of the way lets focus on the other part which is actually using the preprocessor to do that we’ll have to use a bundler to process these .feature files, there are many bundlers out there so you can use any bundler you want to, I personally prefer using esbuild because it is fast and easy to configure

And so to do this all we have to do setup an on() event handler and configure our cypress-cucumber-preprocessor plugin and the bundler inside of the setupNodeEvents function that allows us to tap into, modify, or extend the internal behavior of Cypress

import { defineConfig } from "cypress";
import { addCucumberPreprocessorPlugin } from "@badeball/cypress-cucumber-preprocessor";
import createBundler from "@bahmutov/cypress-esbuild-preprocessor";
import createEsbuildPlugin from "@badeball/cypress-cucumber-preprocessor/esbuild";

export default defineConfig({
    e2e:{
        setupNodeEvents(on, config){
            addCucumberPreprocessorPlugin(on, config);
            on("file:preprocessor",createBundler({
          plugins: [createEsbuildPlugin(config)],
        });
            )
        },
        specPattern: "**/*.feature",
    }
})

And That’s all we’re done with the configuration all that’s left is to take it for a spin and write some tests

Writing your First Test

To write a test just add a .feature file inside of the “ cypress/e2e/ ” folder and creative a respective spec file for it

what is a spec file? you may ask well its a file that tells cypress how to process the statements inside of the feature file, you’ll see what i mean in just a sec

So lets quickly write a feature file first

Feature: Google.com
  Scenario: visting the frontpage
      When I visit google.com
      Then I should see Google as the Title

And that’s it, all this test does is navigate to google.com and check whether the title for the website is google or not, simple as that 🙃

Now obviously you can do more complex stuff with this but for the sake of demo and simplicity let’s keep it to that for now

And let’s move on to writing the actual spec file for this test, to do that just create a file ending in .ts (or .js) with the same name as that of the feature file e.g. google.ts if you called it google.feature

import { When, Then } from "@badeball/cypress-cucumber-preprocessor";

When("I visit google.com", () => {
  cy.visit("https://google.com");
});
Then("I should see Google as the Title", () => {
  cy.get("title").should("Google");
});

Now to run this test just run yarn cypress run or npx cypress run and if you followed through correctly then you’ll see the test pass 😌

Common Step Definitions

You don’t have to actually write a spec file for each .feature file what you can do is use a common spec file and define all the reoccurring step definitions inside of it to do so add the following line inside of your package.json

"cypress-cucumber-preprocessor": {
    "stepDefinitions": [
      "cypress/e2e/common/index.ts"
    ]
  }

and now you can define all the common step definitions inside of the index.ts and yes you can call this file whatever you want i call it index.ts because i kinda like it 🤷‍♂️

Reusable Step definitions

YES, you read it right you can actually write reusable step definitions for the feature statements that you will probably use multiple times e.g.

Feature: Google.com
  Scenario: visting the frontpage
    When I visit "google.com"
        Then I should see "Google" as the "title"

Notice the double quotes on google.com, Thats what we're going to use to make this statement reusable

The main part is tho happens in the spec file

import { When, Then } from "@badeball/cypress-cucumber-preprocessor";

When(`I visit {string}`, (url: string) => {
  cy.visit(`https://${url}`);
});
Then(`I should see {string} as the {string}`, (text, target) => {
  cy.get(location).should("contain", text);
});

What we do here is take arguments from the feature statements inside the double quotes and then we use them as parameters in the callbacks

And thus, We can now use these two statements as many times as we want to by just changing the values inside the double quotes

And That is How you can make End to End Testing much more easy and Fun for beginners on your team

Hello there 👋, Thank you for reading to the bottom, Hope you liked this blog and that it was Helpfull to you in some way or the other, This is the first blog post i ever wrote so please feel free to point out some short commings if you find any constructive criticism is always welcomed

Thank you for Reading, and I hope to see you on next one