Automated testing on push in Git - Step-by-Step Execution

Process Flow - Automated testing on push

Developer writes code

↓

Developer pushes code to remote repo

↓

Remote repo triggers CI pipeline

↓

CI runs automated tests

↓

Notify success

↓

Developer sees results

This flow shows how pushing code triggers automated tests in a CI system, which then reports success or failure back to the developer.

Execution Sample

Git

git push origin main
# Remote CI runs tests
# Tests pass or fail
# Notification sent

This simulates pushing code to a remote repository which triggers automated tests.

Process Table

Step	Action	System Response	Result
1	Developer runs 'git push origin main'	Code is sent to remote repository	Code received by remote repo
2	Remote repo triggers CI pipeline	CI pipeline starts automated tests	Tests running
3	Tests execute	Tests check code correctness	Tests pass or fail
4	CI pipeline sends notification	Developer receives pass/fail status	Developer informed
5	Developer reviews notification	Decides next steps	Fix bugs if tests failed or continue development

💡 Execution stops after developer receives test results and decides next steps

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	Final
Code State	Local changes	Pushed to remote	Tests running	Tests passed/failed	Notification sent	Developer informed

Key Moments - 3 Insights

Why does pushing code trigger tests automatically?

Because the remote repository is configured with a CI pipeline that listens for push events, as shown in step 2 of the execution_table.

What happens if tests fail after a push?

The CI pipeline sends a failure notification to the developer (step 4), so they can fix issues before continuing.

Does the developer have to run tests manually after pushing?

No, tests run automatically on the remote CI system after the push, as shown in steps 2 and 3.

Visual Quiz - 3 Questions

Look at the execution table, what happens immediately after the developer pushes code?

A The code is merged automatically

B The remote repo triggers the CI pipeline

C The developer runs tests locally

D The developer receives a notification

💡 Hint

Check step 2 in the execution_table where the CI pipeline starts after push

At which step does the developer get informed about test results?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at step 4 in the execution_table where notification is sent

If tests fail, what is the developer's next action according to the flow?

A Fix bugs before pushing again

B Push more code without changes

C Ignore the failure and continue

D Delete the remote repository

💡 Hint

Refer to key_moments about handling test failures and step 5 in execution_table

Concept Snapshot

Automated testing on push:
- Developer pushes code to remote repo
- Remote triggers CI pipeline automatically
- CI runs tests on new code
- Results (pass/fail) sent to developer
- Developer fixes issues if tests fail
This ensures code quality before merging.

Full Transcript

When a developer pushes code to a remote repository, the remote system triggers a continuous integration (CI) pipeline automatically. This pipeline runs automated tests on the new code to check for errors or issues. The tests either pass or fail. The CI system then sends a notification back to the developer with the results. If tests fail, the developer must fix the problems before pushing again. This process helps keep the codebase stable and prevents broken code from being merged.

Practice

1. What is the main purpose of automated testing on push in Git workflows?

easy

A. To run tests automatically when code is pushed to catch errors early

B. To manually review code before merging

C. To delete old branches after pushing

D. To speed up the push command execution

Solution

1. Step 1: Understand automated testing on push

   Automated testing on push means tests run automatically when code is pushed to a repository.

2. Step 2: Identify the main benefit

   This helps catch errors early and keeps the project stable by preventing broken code from merging.

3. Final Answer:

   To run tests automatically when code is pushed to catch errors early -> Option A

4. Quick Check:

   Automated testing on push = run tests automatically [OK]

Hint: Automated testing runs tests on push to catch bugs early [OK]

Common Mistakes:

• Thinking it speeds up git push command
• Confusing with manual code review
• Assuming it deletes branches automatically

2. Which file is commonly used to configure automated tests to run on push in a GitHub repository?

easy

A. package.json

B. README.md

C. .gitignore

D. .github/workflows/ci.yml

Solution

1. Step 1: Identify configuration file for GitHub Actions

   GitHub Actions uses YAML files inside the .github/workflows directory to define workflows.

2. Step 2: Match file to automated testing on push

   The file .github/workflows/ci.yml typically contains instructions to run tests on push events.

3. Final Answer:

   .github/workflows/ci.yml -> Option D

4. Quick Check:

   GitHub Actions config = .github/workflows/ci.yml [OK]

Hint: GitHub Actions workflows live in .github/workflows/ [OK]

Common Mistakes:

• Choosing .gitignore which ignores files
• Selecting README.md which is documentation
• Picking package.json which is for Node.js dependencies

3. Given this GitHub Actions workflow snippet, what happens when you push code to the main branch?

name: CI
on:
  push:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run tests
        run: echo "Tests passed!"

medium

A. The workflow fails because 'run' command is invalid

B. The workflow runs only on pull requests, not on push

C. The workflow runs and prints 'Tests passed!' on every push to main

D. Nothing happens because branches is empty

Solution

1. Step 1: Analyze the trigger event

   The workflow triggers on push events to the 'main' branch as specified under 'on: push: branches: [main]'.

2. Step 2: Check the job steps

   The job runs on ubuntu-latest, checks out the code, then runs the command echo "Tests passed!" which prints that message.

3. Final Answer:

   The workflow runs and prints 'Tests passed!' on every push to main -> Option C

4. Quick Check:

   Push to main triggers workflow = prints message [OK]

Hint: Push to main triggers workflow with echo command [OK]

Common Mistakes:

• Thinking it runs only on pull requests
• Assuming 'run' command is invalid syntax
• Believing branches list is empty

4. You wrote this GitHub Actions workflow to run tests on push but it never runs:

name: Test
on:
  push:
    branch: main
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: echo "Running tests"

What is the error?

medium

A. The 'run' command must be inside a 'steps' array

B. The key 'branch' should be 'branches' under 'push' to specify branches list

C. The 'uses' action 'actions/checkout@v3' is deprecated

D. The 'runs-on' value 'ubuntu-latest' is invalid

Solution

1. Step 1: Check the event trigger syntax

   The workflow uses 'branch' instead of 'branches' under 'push'. The correct key is 'branches' which expects a list.

2. Step 2: Understand impact of wrong key

   Because 'branch' is invalid, the workflow never triggers on any push event.

3. Final Answer:

   The key 'branch' should be 'branches' under 'push' to specify branches list -> Option B

4. Quick Check:

   Correct key is 'branches' not 'branch' [OK]

Hint: Use 'branches' (plural) under push, not 'branch' [OK]

Common Mistakes:

• Confusing 'branch' with 'branches'
• Thinking 'runs-on' value is wrong
• Assuming checkout action is deprecated

5. You want to run automated tests only when code is pushed to either the 'main' or 'develop' branches. Which is the correct snippet to add in your GitHub Actions workflow YAML to trigger on these pushes?

hard

A. on:
push:
branches:
- main
- develop

B. on:
push:
branch: ['main', 'develop']

C. on:
push:
branch: 'main, develop'

D. on:
push:
refs: ['main', 'develop']

Solution

1. Step 1: Understand correct YAML syntax for branches

   The 'branches' key expects a list of branch names, each on its own line or in a list format.

2. Step 2: Compare options

   on: push: branch: ['main', 'develop'] uses incorrect singular 'branch' key instead of plural 'branches'. on: push: branches: - main - develop uses the correct 'branches' key with standard YAML list format using dashes, which is widely used.

3. Step 3: Identify invalid options

   on: push: branch: 'main, develop' uses 'branch' (wrong key) and a string with comma, which is invalid. on: push: refs: ['main', 'develop'] uses 'refs' which is not the correct key for branches under push.

4. Final Answer:

   on: push: branches: - main - develop -> Option A

5. Quick Check:

   Use 'branches' with list syntax for multiple branches [OK]

Hint: Use 'branches:' with dash list for multiple branches [OK]

Common Mistakes:

• Using 'branch' instead of 'branches'
• Passing branches as a comma string
• Using 'refs' instead of 'branches'