Mahindra University Students: Setting Up CI Checks for an Internship Repository

To set up CI checks for an internship repository, add one YAML file under .github/workflows/ that installs dependencies, runs your linter and runs your tests on every push and pull request. For a 14-day internship, a single job of about 25 lines is enough, and you can have it green by day 2 or 3.

This guide is for Mahindra University students building a full stack project (Node.js, React or similar) during a short internship. It explains each line of a starter workflow, gives a day-by-day plan, a troubleshooting table for failed runs, and a checklist you can copy into your repo’s README.

Why a small CI pipeline matters in a 14-day internship

In two weeks you will push code often, probably late in the day, and probably from more than one machine. Continuous integration (CI) is an automated check that runs the same commands on a clean server each time you push. If the code only works on your laptop, CI shows it within minutes.

For a reviewer or mentor reading your repository, a green check mark next to each commit says something concrete: the project installs from scratch, the linter is satisfied and the tests pass. It does not say the app is good, but it removes a whole class of “it doesn’t run for me” conversations.

The free two-week online internship at CareerSwami (with a free offer letter and a free completion certificate after successful completion) is a good setting to practise this, because the short timeline rewards habits that stop you losing time to broken builds.

What you need before writing the workflow

• A GitHub repository (public repositories get free Actions minutes; private ones have a monthly quota, so check your plan’s current limits on GitHub).
• A package.json with lint and test scripts. If you use a monorepo with separate client and server folders, note which folder holds each.
• A committed lockfile (package-lock.json) so installs are reproducible.
• A linter configured locally (ESLint is the common choice) and a test runner (Jest, Vitest or similar).
• Both commands passing on your machine first. CI will not fix a failing test; it only reports it.

Check the scripts section of your package.json. An illustrative version looks like this:

{
  "scripts": {
    "lint": "eslint .",
    "test": "jest --ci",
    "build": "vite build"
  }
}

Starter GitHub Actions workflow for lint and tests, line by line

Create the file .github/workflows/ci.yml. The following is an illustrative starter; it has not been run against your project, so adjust names and versions to match your setup.

name: CI

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  lint-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v4

      - name: Set up Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Lint
        run: npm run lint

      - name: Test
        run: npm test

What each block does

If your repo has separate client and server folders

Add a working-directory to the steps, or use defaults on the job. An illustrative fragment:

    defaults:
      run:
        working-directory: server
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
          cache-dependency-path: server/package-lock.json
      - run: npm ci
      - run: npm run lint
      - run: npm test

Duplicate the job with working-directory: client for the front end.

Worked example: adding CI to a task-manager app (illustrative)

Imagine a student building a task-manager app with an Express API and a React front end in one repository. The scenario below is invented to show the sequence; the numbers and errors are not from a real run.

1. Local check. The student runs npm run lint and npm test in server/. Lint reports two unused variables; tests pass. They fix the variables and commit.
2. Add the workflow. They create .github/workflows/ci.yml with the server-folder version above and push to a branch called add-ci.
3. First run fails. The Actions tab shows a red cross at the “Install dependencies” step. The log says the lockfile could not be found, because package-lock.json was in .gitignore.
4. Fix. They remove the lockfile from .gitignore, commit it and push again.
5. Second run fails. Now the “Test” step fails: a test reads process.env.MONGO_URI, which exists on the student’s laptop but not on the runner. They change the test to use a mocked database and add a fallback value for the environment variable.
6. Green run. Both steps pass. They open a pull request into main, and the check appears on it.

The lesson: the first two failures were environment differences, not code bugs. That is exactly what CI is for.

Pipeline failure troubleshooting table for lint and test jobs

Open the failed run in the Actions tab, click the job, and expand the first red step. Read the first error, not the last; later errors are often consequences.

A short debugging routine

1. Reproduce locally with the same sequence: rm -rf node_modules, npm ci, npm run lint, npm test.
2. If it passes locally, compare Node versions and environment variables.
3. Re-run the job after fixing; use the “Re-run failed jobs” option in the Actions tab for flaky network steps.
4. Keep fixes small, one commit per cause, so the history explains itself.

A 14-day plan for adding and using CI

Repository CI readiness checklist

• Workflow file lives at .github/workflows/ci.yml and is on the default branch.
• Lockfile is committed; CI uses npm ci.
• Node version in CI matches your local version.
• lint and test scripts exit with a failing code when something is wrong.
• Tests do not depend on a local .env, a running local database or the current date.
• No secrets, API keys or passwords appear in the YAML or logs.
• README shows the exact commands to run checks locally.
• A status badge or a screenshot of a green run is available for your mentor.

Mahindra University students: how CI evidence fits your internship and project requirements

Mahindra University publishes its academic rules per programme and batch. The B25 ECM B.Tech regulations say, in an excerpt, that the industry internship is done in collaboration with industry or academia and carries no credits. The same excerpt says it is evaluated on a performance evaluation report from the industrial or academic partner, possibly with other components; the rest of that sentence was cut off, so treat the full evaluation method as unconfirmed and read the current document yourself.

In practice this means a clean, tested repository is useful evidence of your work, but you should not assume it replaces any report or form your programme asks for. Duration, timing and the treatment of online internships are not confirmed in what is available here, and your own programme or batch may have different rules.

The B.Tech CSE programme page shows a third-year team project (2 credits) in semester 6, a Year-4 Project of 3 credits in semester 7 and one of 10 credits in semester 8, and lists no internship course in that scheme. The page is undated, so check it against your current curriculum. If you are in CSE, a CI workflow built now is a habit you can reuse directly in those team and final-year projects, where shared repositories and pull requests are common.

Steps to verify your own requirements

1. Download the regulations PDF for your programme and batch from the university website and find the internship clause; note the required duration and evaluation components.
2. Email your programme coordinator or department office asking in writing whether an online internship of about two weeks satisfies the requirement, and keep the reply.
3. Ask what documents are needed from the host organisation (for example, an offer letter, a completion certificate or a partner evaluation report) and in what format.
4. Ask whether a repository link, CI results or a project report can be part of your submission, and who reviews it.
5. Compare the CSE or your own programme’s curriculum page with the PDF; if they disagree, ask the department which is current.
6. Confirm any deadlines for submission with the Career Development Services or your department, since no calendar dates were verified.

Keeping the pipeline useful after the first green run

• Protect main. In repository settings, add a branch protection rule requiring the CI check to pass before merging. This is available on public repositories; confirm current plan limits for private ones.
• Keep runs fast. Cache dependencies (already done by cache: npm), and avoid heavy end-to-end tests in the first version.
• Separate concerns. Once stable, split lint, test and build into separate jobs so a failure points to the cause immediately.
• Pin action versions. Using @v4 tags is fine for a student project; check the Actions marketplace pages for newer major versions before you start.
• Document it. Two lines in the README on how to run the same checks locally help a reviewer trust your work.

Frequently Asked Questions

Do I need to pay for GitHub Actions for an internship repository?

Public repositories can use standard GitHub-hosted runners without charge, and private repositories get a monthly free allowance that depends on your account plan. Check GitHub’s current billing page, since limits change.

Should I use npm ci or npm install in the workflow?

Use npm ci. It installs exactly what the lockfile says and fails loudly if the lockfile and package.json disagree, which is the behaviour you want in CI.

My tests pass locally but fail in GitHub Actions. Where do I start?

Compare Node versions, environment variables and file name casing first. Then reproduce locally with a clean install using npm ci. Most differences come from a missing .env, an uncommitted file or a Linux case-sensitivity issue.

Can I run lint and tests as separate jobs?

Yes. Define two jobs under jobs:, each with its own checkout, setup and install steps. They run in parallel by default, and the Actions tab will show which one failed.

How do I handle API keys that my tests need?

Avoid needing real keys in unit tests; mock external services instead. If you must use a secret, store it under repository Settings, then Secrets and variables, and reference it in the workflow. Never paste keys into the YAML file.

Will a green CI check count towards my university internship evaluation?

That is not confirmed. The B25 ECM excerpt refers to a performance evaluation report from the partner, possibly with other components. Ask your programme coordinator in writing what evidence is accepted.

Does the CareerSwami internship require CI?

CareerSwami does not make that claim here. The programme is a free two-week online internship with a free offer letter and a free completion certificate after successful completion, across 26 tracks. CI is a good-practice addition you can make to your own repository, and your track’s task instructions decide what is actually required.

What if my repository uses Python or Java instead of Node?

The structure stays the same: checkout, set up the language (for example actions/setup-python), install dependencies, run the linter, run the tests. Only the setup action and the commands change.

Related Full Stack Web Development guides

• HBNI Students: Research Lab Tools as a Full Stack Internship Project
• Kolhan University Students: Learning Full Stack Web Development Through Short Daily Practice Blocks
• Pragjyotishpur University Students: Presenting Internship Work in a LinkedIn Post and Profile
• All Full Stack Web Development internship guides