What is a “Codemod”?

By doing a google search, Codemods are transformations that run on your codebase programmatically. This allows a large number of changes to be programmatically applied without having to manually go through every file.

Let’s simplify it. if we break the word codemod it kind of sounds like “code modification” or in short codemod. we are creating a script that goes through our file and modifies our code. It’s as simple as that.But you can thing why not regex, we can also target via regex and write a node script that does the same thing. Regex works great for text but not for code. Regex doesn’t understand structure. for e.g when we are updating some random component like say a Button

<Button primary>Click Me!</Button>

<Button variant="primary">Click Me!</Button>

and you want to transform Button primary attribute to variant=”Primary” . With the regex approach it will look something like this code.replace(/<Button\s+primary(.*?)>/g, '<Button variant="primary"$1>') , Now imagine you have to target <Button secondary>Click Me!</Button> or success.It becomes very hard from regex to manage all this scenario. Now to handle these situations we are going to need to use AST(Abstract syntax tree). another jargon huh. Let’s understand AST

What is AST?

According to google `An Abstract Syntax Tree (AST) is a tree representation of the abstract syntactic structure of a code snippet or formal language. A lot of jargon and a little hard to understand. Lt’s simplify it. Think of an AST is like an x-ray of your code. It doesn’t care about how your code looks but focuses on what it’s mean.

For e.g const sum = a + b take this code now how it will look as an abstract tree

VariableDeclaration (const)
├── VariableDeclarator
│   ├── Identifier (sum)
│   └── BinaryExpression (+)
│       ├── Identifier (a)
│       └── Identifier (b)

This is the AST.

so instead of working with raw text (which is messy and error-prone), you get a clean, structured representation that’s much easier to traverse, analyze and modify safely.

If you want to visualize your code to AST you can go to this website link.

Codemod Tools

There are some popular codemod tools that helps us streamline the process.

• jscodeShift (by facebook): https://github.com/facebook/jscodeshift

• ts-morph (for TypeScript-heavy codebases) : https://ts-morph.com/

• babel plugins (for custom transformations) : https://babeljs.io/

• recast and ast-types (used under the hood)

For the purpose of this blog we’ll just focus on jscodeshift.

Writing your first codemod

Let’s start with the simple like renaming a variable. Here I’ll take the example of upgrading react-router-dom from v5 top v6

In react-router-dom v6 there is no useHistory and we have to rename it to useNavigate.

First let’s install jscodeShift in our project where we want to change our code. Also you can go through the jscodeShift docs here https://jscodeshift.com.

npm install jscodeshift

Second create a javascript file in the root name migrate.js(you can name anything) and inside that create a module that exports a function and accepts two parameters file and api.

module.exports = function transformer(file, api) {
}

Now we need to initialize the jscodeshift and file source inside the transformer function to convert the source code to AST.

module.exports = function transformer(file, api) {
    const j = api.jscodeshift;
    const root = j(file.source);
}

let’s see what going on

• const j = api.jscodeshift; we are assigning the jscodeshift library to the variable j as an utility function.We’ll use this for parsing, traversing and transforming js code as an AST.

• const root = j(file.source); It will parse the source code of the file into an AST and wraps it in jscodeshift collection. Now root is the entry point for finding and transforming nodes in the code.

now we want to change the const history = useHistory() → const navigate = useNavigate(), now to do so we’ll visualize using this link https://astexplorer.net/

Now this is how this simple react program will look like.

Let’s deep dive the right part. we can see we have two ImportDeclaration as in the left we have two import for react and react-router-dom. Then there is a VariableDeclaration and that is CustomComponent

const CustomComponent = (props)=>{
  const history = useHistory();
  const location = useLocation()

  return <button onClick={(e) => history.push(`/hello/${e}`)}>click me</button>
}

now if we expand the VariableDeclarator we get a lot of info, but if you can see the highlighted part we have two more VariableDeclaration and a ReturnStatement.Now if we see on the left part of the code, we’ll see

const history = useHistory();
const location = useLocation()

return <button onClick={(e) => history.push(`/hello/${e}`)}>click me</button>

these history, location and the return statements are the VariableDeclaration and the ReturnStatement.

Now we need to find the node that contains the history and useHistory and to do that jscodehift provides us a method called find(type) it takes what type of node you want to finds. Since, we wants VariableDeclaration will pass this as a type.

module.exports = function transformer(file, api) {
    const j = api.jscodeshift;
    const root = j(file.source);

    const variableDeclarations = root.find(j.VariableDeclaration);
}

Now the variableDeclarations is a an array as it will have all the variableDeclarations node, so we need to loop through it and reach to the correct node or property

Now looping thorugh variableDeclarations will give a Collection of nodepaths which has a .value property.Also Declarations is also an array So we need to loop through again to go to the history and that is inside declarations[i] > id > name

module.exports = function transformer(file, api) {
    const j = api.jscodeshift;
    const root = j(file.source);

    const variableDeclarations = root.find(j.VariableDeclaration);

    variableDeclarations.forEach((declaration) => {
        declaration.value.declarations.forEach((declarator) => {
              if (declarator.id.name === 'history') {
                    declarator.id.name = 'navigate';
              }
        });
  });
}

similarly for the useHistory it is inside the declaration > init > callee > name

so now to replace that we need to update the name.

module.exports = function transformer(file, api) {
    const j = api.jscodeshift;
    const root = j(file.source);

    const variableDeclarations = root.find(j.VariableDeclaration);

    variableDeclarations.forEach((declaration) => {
        declaration.value.declarations.forEach((declarator) => {
              if (declarator.id.name === 'history') {
                    declarator.id.name = 'navigate';
                    declarator.init.callee.name = 'useNavigate';
              }
        });
  });
}

It’s almost done. we have completed the process of renaming the history → navigate and useHistory → useNavigate. The only then left for us is to return the output from AST back to original source code(js)

and to do that we need to return root.toSource(), where root is the transformed AST and toSource() is converting the AST back to js

module.exports = function transformer(file, api) {
    const j = api.jscodeshift;
    const root = j(file.source);

    const variableDeclarations = root.find(j.VariableDeclaration);

    variableDeclarations.forEach((declaration) => {
        declaration.value.declarations.forEach((declarator) => {
              if (declarator.id.name === 'history') {
                    declarator.id.name = 'navigate';
                    declarator.init.callee.name = 'useNavigate';
              }
        });
  });

  return root.toSource()
}

Now let’s create a script in package.json to run this codemod, the command will look like this

jscodeshift -t <jsocdeshit-script-path-we-created> <source-of-file-we-want-to-update>

  "scripts": {
    "migrate": "jscodeshift -t migrate.js index.js"
  }

or if we want to pass the source file we can make like this,

  "scripts": {
    "migrate": "jscodeshift -t migrate.js --"
  }

npm run migrate src/pages/home

let’s see the magic

Now we can even make the import statement to change from the useHistory → useNavigate.

Hint: use find(j.ImportDeclaration).

Conclusion

Codemods and AST provide a powerful tool to automate code refactoring at scale. Something to keep in mind is that have some kind of versioning system like git to help some mishaps. Also starts with small repo before running on /src.

Hope you have learned something and will build something cool for your usecase.

Drop a comment, or ping me on twitter/linkedIn. I’d love to see what you are building.

Transformers

In the realm of generative AI, "transformers" are a type of model architecture that has revolutionized natural language processing. Much like the Autobots and Decepticons from the Transformers universe, these models are powerful and versatile. They can transform input data into meaningful output, whether it's translating languages, generating text, or even creating images.

Transformers work by using a mechanism called "attention," which allows them to focus on different parts of the input data when producing an output. This is akin to how Autobots and Decepticons can change their forms to adapt to different situations. The attention mechanism helps the model understand context and relationships within the data, making it highly effective for tasks that require understanding complex patterns and sequences.

GPT

GPT stands for generative pre-trained transformer. Here's a simpler breakdown:

• "Generative" means it can create new text (or other forms) based on the input it receives.

• "Pre-trained" means it has already learned a lot about language from a big collection of text before being used for specific tasks.Since it is pre-trained it will have a cut-off date

• "Transformer" is the type of model it uses, which helps it understand and generate text efficiently.

Together, these parts make GPT good at understanding and creating human-like text.

Encoder and Decoder

Transformers don't naturally understand English; they interpret data as numbers. To do this, we need to convert our text into numbers, a process called encoding. Encoding changes the input text into a numerical form that the transformer can work with.

After encoding, we also need a way to change it back to its original form. This reverse process, called decoding, lets the transformer reconstruct the initial input from the numbers, ensuring the information is accurately understood and used.

Think of it like a spy sending a message. They can't send it in plain English because they might get caught, so they encode the message. Even if someone else reads it, they won't understand it. At the receiving end, the message is converted back to normal English through decoding. Similarly, GPT understands numbers, so we encode our input into numbers, and GPT converts it back to the original format using decoding.

You can visualise this on tiktokenizer link.

I have created my own encoding and decoding program and you can access it on this link.

Here is a quick demo

Vector Embedding

Imagine every word in a sentence is like an item in a big super mart. Now, you want to group similar items together — all the fruits in one rack, all spices in another, and snacks in one corner. That’s exactly what vector embeddings do. They turn each word into a number-based location — kind of like giving it a spot on Google Maps. Words that are similar (like king and queen, or pani puri and chaat) are placed closer on this map. So when an AI model “looks” at words, it doesn’t just see random text — it sees them like neatly arranged grocery aisles. This helps it figure out meaning, tone, and relationships — just like you know that aloo and bhindi go in the same sabzi section.

Thanks to vector embeddings, AI can:

• Understand what you’re talking about

• Reply more naturally

• Group similar things together (like in recommendation systems)

Want to see how this works visually? Check this out — it’s super cool!

Postional Encoding

Imagine you’re at a wedding buffet. You see roti, then dal, then paneer, then gulab jamun. Now imagine if someone randomly shuffled it to gulab jamun, dal, paneer, roti. Ufff. Total confusion, right?

That’s where positional encoding comes in for AI.

LLMs (like ChatGPT) don’t naturally understand word order. They just see a bunch of words. So we have to tell the model where each word is in the sentence — like giving it a seat number at a shaadi.

For example:

• “Ram ate mango” → makes sense.

• “Mango ate Ram” → now the mango is a cannibal?

So we assign positional values to each word to maintain meaning. Just like you know starters come before main course and dessert comes last, the AI understands sentence flow better when we tag word positions.It’s like adding a “row number” to your Excel sheet — the data’s the same, but now it’s organized. Without positional encoding, an AI model would treat “I love biryani” and “Biryani loves I” as the same thing.

Semantic Meaning

Let’s say you’re watching an India vs Pakistan match. Kohli walks out to bat, the stadium is roaring, expectations are sky-high. But then — he gets out on the very first ball. The next day, someone says, “Kohli broke millions of hearts yesterday.” Now if an AI model takes that sentence literally, it might think Kohli was involved in some emotional drama. But as an Indian cricket fan, you understand the real meaning — he got out early, and fans were hugely disappointed. That’s what semantic meaning is all about: understanding the real intent behind words based on context — not just what the words say, but what they actually mean in that situation.

This is a big deal in AI. To truly “understand” language, models need to figure out these hidden meanings. For example, the sentence “the crowd went silent” could mean people are bored, shocked, or deeply emotional — and the model needs to infer the right reason based on the overall context.

AI models learn this by studying how words appear together in huge amounts of text. They start seeing patterns — like “Kohli,” “match,” “out,” and “fans” often appearing together in emotional contexts. This helps the model connect the dots and guess the intended meaning.

Self Attention

Imagine you’re reading an Indian newspaper headline:

“Modi met Shah at Delhi airport after the G20 summit.”

Now, as a human, you naturally understand who did what, where, and when. You know that “Modi” and “Shah” are people, “met” is the action, “Delhi airport” is the place, and “G20 summit” gives you context. But for an AI model, it needs to pay attention to the right words at the right time. This is where Self-Attention comes in — it helps the model focus on important words in a sentence, depending on what it’s trying to understand or generate.

In AI, when a model reads a word like “met,” it looks at all the other words in the sentence and decides which ones are relevant. For “met,” the model might pay more attention to “Modi” and “Shah” to figure out who met whom.

Self-attention assigns weights to each word — higher weights to more relevant ones. That’s how the model keeps track of relationships in a sentence, no matter how long it is.

Multi Head Attention

Multi-Head Attention is like watching an IPL match with a group of friends—everyone’s watching the same game, but each person is noticing something different. One is focused on Kohli’s stance, another is watching the bowler’s grip, someone’s tracking the field setup, and someone else is reacting to the crowd. That’s exactly what multi-head attention does: it lets a transformer model look at the same sentence from different angles, all at once.

Each “head” in this mechanism acts like a specialist. One might focus on the relationship between subjects and verbs, another on sentiment, and yet another on word positions. These heads process the sentence in parallel, and their individual insights are later combined, giving the model a richer, more detailed understanding of the input. It’s like assembling different pieces of gossip from your cousins to figure out what really happened at the wedding.

For instance, in the sentence “Virat hit the ball and the crowd went wild,” one head might link “Virat” to “hit,” another might tie “ball” to “crowd,” and a third might interpret the emotional shift. This multi-perspective view makes language models incredibly good at picking up nuances—whether it’s translating Tamil to English or understanding sarcastic memes on Indian Twitter.

Softmax

Imagine you and your friends are choosing where to eat. You list your top 3 picks: pizza, biryani, and dosa. Everyone gives a score out of 10 for each option. Instead of just picking the one with the highest score, you want to see how likely each place is to be chosen based on everyone's preferences. This is where Softmax helps.

In machine learning, Softmax takes a bunch of raw scores (called logits) — which might be any number, positive or negative — and converts them into probabilities that are easy to compare. It does this by making the biggest numbers stand out even more and squashing the rest proportionally. So if biryani gets a score of 10, pizza gets 7, and dosa gets 2, Softmax will say something like: “Biryani has an 80% chance, pizza 18%, and dosa 2%.”

It’s like your brain thinking, “I’m mostly in the mood for biryani, but I could settle for pizza. Dosa? Not today.” This helps AI models make decisions confidently by understanding how strong each option is relative to the rest. Softmax doesn’t just look at the best option — it compares all of them to make a well-balanced decision.

Temperature

Imagine you’re using an AI chatbot to generate pickup lines (no judgment). Now, if you set the temperature to 0, the model plays it super safe — it’ll always choose the most predictable, bland line like, “Are you a library book? Because I want to check you out.” Meh. Reliable? Yes. Spicy? Not at all.

Now crank the temperature up to 1.0 or higher, and suddenly the AI gets a little wild. It might say something like, “Are you made of copper and tellurium? Because you’re Cu-Te, but also highly reactive in my neural circuits.” Riskier, funnier, and more creative — but it could also backfire and say something totally off-beat. That’s the trade-off.

In short: Temperature controls randomness. A low temperature makes the model stick to safe, high-confidence responses. A high temperature lets it explore less likely, but more diverse or creative outputs. Think of it like masala levels in your food — too low and it’s bland, too high and it might just burn your brain. The sweet spot depends on the vibe you’re going for.

Softmax vs Temperature

Imagine you’re at a chaat stall in Delhi. The vendor asks, “What would you like—Pani Puri, Dahi Puri, or Aloo Tikki?” Your cravings are like logits (raw scores)—you’re leaning more toward Pani Puri, but the other options are still tempting. Now, Softmax is like your brain calculating the odds: “Hmm, I love Pani Puri (60%), but I’m also in the mood for Aloo Tikki (30%), and maybe just a little Dahi Puri (10%).” Softmax takes your raw cravings and turns them into neat, sharable probabilities.

But what if your mood isn’t stable? That’s where Temperature comes in. Let’s say your hunger level is low (temperature = 0.3). You’ll go straight for Pani Puri, no second thoughts—zero randomness. But if you’re in an adventurous mood (temperature = 1.5), you might say, “Why not try Dahi Puri today, even if it wasn’t the top pick?” With higher temperature, you’re more open to exploring new tastes. Lower temperature? You’re sticking to tried-and-tested.

So in AI, Softmax is the logic that turns model guesses into probabilities. Temperature is the spice meter—it decides whether the model sticks to its top guess or experiments with something offbeat. Together, they help models balance between sensible and surprising, just like we do at a food stall!

Knowledge cutoff

A knowledge cutoff is like a student who stopped studying the news after a certain date—let’s say they last read the newspaper in December 2023. So, if you ask them about the 2024 Lok Sabha elections or who won IPL 2025, they’ll blank out. Similarly, AI models like me are trained on a snapshot of the internet up to a certain point (for me, it’s June 2024). Anything that happened after that—new tech releases, policy changes, cricket wins, viral memes—I won’t know unless I’m updated. So, when talking to an AI, always remember: it’s not ignoring you, it’s just stuck in the past like that friend who still thinks TikTok is banned in India.

Conclusion: AI Doesn’t Have to Be Rocket Science

If you’ve made it this far—congrats! You’ve just unpacked some of the trickiest AI jargons out there, and hopefully, they now feel more like familiar roadside dhabas than alien tech towers.

From tokenization slicing up text like your mom chops veggies for sabzi, to vector embeddings helping AI understand context like how we know “Kohli” means cricket and not chemistry, you’ve started peeling back the layers of how machines process language. Positional encoding showed us that order matters—just like your roll number did in school. Softmax and temperature taught us how models decide what to say and how creatively to say it, while self-attention and multi-head attention proved that models aren’t just looking at words—they’re analyzing the full picture, much like how you scan your friends’ faces before cracking a joke.

And finally, knowledge cutoff? That’s just the AI saying, “Bro, I stopped reading the news after June 2024.”

This is just the beginning. The more we break down these buzzwords, the more power we gain to understand—and maybe even shape—the AI shaping our world. Stay curious, ask dumb questions (they’re usually the best ones), and remember: you don’t need a PhD to decode AI. Sometimes, all it takes is a little masala and a lot of curiosity. 🚀

Why Cypress?

Cypress is gaining popularity due to its developer-friendly nature, real-time reloads, and powerful testing capabilities. It’s an all-in-one testing framework that supports end-to-end testing, unit testing, and integration testing. Cypress provides detailed and interactive error reports, making it easier to debug tests.

Prerequisites

Before diving in, ensure you have the following:

• A GitLab repository with your project code.

• A basic understanding of GitLab CI/CD pipelines.

Step 1: Set Up Cypress in Your Project

If you haven’t already installed Cypress in your project, you can do so with npm or yarn:

npm install cypress --save-dev

or

yarn cypress --dev

Once installed, you can initialize Cypress by running

npx cypress open

This command sets up the necessary folder structure and configuration files. You’ll find a cypress.config.js file in the root directory, where you can configure Cypress settings.

Step 2: Add Code coverage

You need to install @cypress/code-coverage and nyc (Istanbul's command-line interface) in your project:

npm install --save-dev @cypress/code-coverage nyc

In your cypress.config.js file, add the following configuration to include the code coverage plugin:

const { defineConfig } = require('cypress');

module.exports = defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      require('@cypress/code-coverage/task')(on, config);
      return config;
    },
  },
});

If you want to add it for component testing you can add the

const { defineConfig } = require('cypress');

module.exports = defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      require('@cypress/code-coverage/task')(on, config);
      return config;
    },
  },
  component: {
     setupNodeEvents(on, config) {
       require('@cypress/code-coverage/task')(on, config);
       return config;
    },
  },
});

Create or update the cypress/support/command.js file to include the code coverage support:

import '@cypress/code-coverage/support';

also, import the cypress/support/command.js file into cypress/support/e2e.js and cypress/support/component.js to get the coverage for the e2e and component test files.

To generate the code coverage report, you can use the following command:

nyc report --reporter=<reporter>

You can replace <reporter> with any of the available reporter options provided by nyc. Some common reporter options include:

• html: Generates an HTML report.

• text: Outputs the report in plain text.

• text-summary: Provides a summary in plain text.

• lcov: Generates an lcov report, which can be used with various CI tools.

• json: Outputs the report in JSON format.

For example, to generate an HTML report, you would use:

npx nyc report --reporter=html

You can specify multiple reporters by separating them with a space:

npx nyc report --reporter=html --reporter=text-summary\

This command will generate both an HTML report and a text summary of the code coverage.

Step 3: Create Your Cypress Tests

Cypress organizes tests into specs, which are just JavaScript files. You can create a new spec file in the cypress/e2e/mytest.cy.js folder:

describe('My First Test', () => {
  it('Visits the Kitchen Sink', () => {
    cy.visit('https://example.cypress.io')
    cy.contains('type').click()
    cy.url().should('include', '/commands/actions')
    cy.get('.action-email')
      .type('fake@email.com')
      .should('have.value', 'fake@email.com')
  })
})

This is a simple test that visits the Cypress example page, clicks a link, and asserts that the URL contains /commands/actions. Cypress provides a clean syntax to interact with web elements and make assertions.

Step 4: Configure GitLab CI

Next, we need to set up GitLab CI to run our Cypress tests automatically. Start by creating a .gitlab-ci.yml file in the root directory of your project if you don’t already have one.

Here’s a basic configuration to run Cypress in GitLab CI:

stages:
  - test

test:
  image: cypress/base:10 # you can use different docker image on cypress official website
  stage: test
  variables:
    NODE_ENV: test # if you want to set up the node_env to test
    STATEMENT: 50  # Set your desired threshold for statements to be covered
    FUNCTION: 50   # Set your desired threshold for functions to be covered
    BRANCHES: 50   # Set your desired threshold for branches to be covered
    LINES: 50      # Set your desired threshold for lines to be covered
  cache:
    key: ${CI_COMMIT_REF_SLUG}-setup
    paths:
      - node_modules/
  before_script:
    - npm ci
  script:
    - npx cypress install  # Explicitly install Cypress as a fallback
    - npx cypress run --headless
    - npx nyc check-coverage --lines $LINES --statements $STATEMENT --functions $FUNCTION --branches $BRANCHES
  after_script:
    - npx nyc report --reporter=cobertura --reporter=text-summary
  coverage: '/^Statements\s*:\s*([^%]+%)/'
  allow_failure: true # this will fail the pipeline
  artifacts:
    paths:
     - coverage/lcov-report/index.html
     - coverage/cobertura-coverage.xml
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage/cobertura-coverage.xml
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'master'

This configuration is designed to run Cypress tests in a GitLab CI pipeline with NYC for coverage checking. It ensures that your code meets the defined coverage thresholds before being merged or deployed.

• Stages: Defines the stages in the CI/CD pipeline. In this case, there is a single test stage where the Cypress tests will be executed.

• Test Job: This is the job that runs in the test stage.

• Image: Uses cypress/base:10 Docker image, which has Node.js and Cypress pre-installed. You can use different versions or images based on your requirements.

• Variables:

• NODE_ENV: test: Sets the environment to test mode.

• STATEMENT, FUNCTION, BRANCHES, LINES: These variables define the minimum coverage thresholds (in percentage) for statements, functions, branches, and lines. If your tests do not meet these thresholds, the job will fail.

• Cache: Caches the node_modules/ directory to speed up subsequent pipeline runs. The cache key is based on the current branch, ensuring different branches do not conflict.

• Before Script: This command installs the project dependencies using npm ci, which is faster and more reliable in CI environments compared to npm install.

• Script:

• npx cypress install: Explicitly installs Cypress, ensuring it’s available even if something goes wrong with the initial setup.

• npx cypress run --headless: Runs Cypress tests in headless mode, meaning no browser UI is shown, which is typical in CI environments.

• npx nyc check-coverage: Checks the test coverage against the defined thresholds (LINES, STATEMENT, FUNCTION, BRANCHES). If the coverage falls below these thresholds, the job will fail.

• After Script: Generates coverage reports in cobertura format (which is compatible with many CI tools) and a text summary, allowing you to easily review coverage results.

• Coverage Regex: A regular expression that GitLab uses to parse the coverage percentage from the job output, enabling the coverage percentage to be displayed in the merge request widget.

• Allow Failure: This option allows the job to fail without failing the entire pipeline. This is useful for non-blocking jobs where you might want to allow code to be merged even if coverage is below the threshold.

• Artifacts: Specifies the files to be retained after the job completes. Here, the coverage report in cobertura format is stored as an artifact, which can be accessed later for review.

• Rules: Defines conditions under which the job will run. In this case, the job will run for merge requests and when committing directly to the master branch.

Step 5: Push to GitLab and Trigger the Pipeline

Once your .gitlab-ci.yml file is ready, commit and push the changes to your GitLab repository:

git add .gitlab-ci.yml
git commit -m "Add GitLab CI configuration for Cypress tests"
git push origin main

This will trigger a new pipeline in GitLab. You can monitor the progress of your pipeline by navigating to the CI/CD > Pipelines section in your GitLab project or you can create a merge request to master.

Step 6: Reviewing Test Results

When the pipeline completes, you can review the test results directly in the GitLab interface. If any tests fail, you’ll be able to download the screenshots and videos captured during the test run, which can be invaluable for debugging.

Additionally, the test results can be viewed on the Merge Request (MR) dashboard, providing a convenient overview of the test outcomes and making it easier to identify and address issues.

Step 6: Advanced Configuration (Optional)

For larger projects, you might want to parallelize tests to reduce the overall runtime. Cypress supports test parallelization natively, but you’ll need to configure your GitLab runner accordingly and use Cypress Dashboard to manage parallel runs.

Another advanced configuration involves setting environment variables for different stages, such as running tests in different environments (staging, production) or using custom configurations for different types of tests.

Conclusion

By integrating Cypress with GitLab CI, you’re taking a big step towards ensuring your codebase remains bug-free and stable. Automated tests run on every push, catching issues before they reach production. This setup not only saves time but also boosts confidence in your code.

With the basics covered, you can now expand on this foundation by exploring advanced Cypress features, optimizing your pipeline, or integrating other tools like Slack for notifications. Happy testing!

This guide should help developers set up Cypress testing in GitLab CI. If you need any more details or specific sections expanded, just let me know!