GitHub

What Does GitHub Mean?

GitHub is a cloud-based platform that extends Git with collaboration, project management, and automation tools. It was founded in 2008 and acquired by Microsoft in 2018.

GitHub is one of the world's largest hosts of source code. Millions of developers and organizations use it for open source and private projects.

GitHub vs. Git: Understanding the Difference

People often use the terms interchangeably, but they serve different purposes. Git is the underlying version control system. It tracks changes locally and has no web interface or user accounts of its own.

GitHub is a commercial service built around Git. Think of Git as the engine and GitHub as the full vehicle, with a dashboard and navigation.

Core GitHub Features

Repository Hosting

• Public: visible to everyone, which supports open source collaboration.
• Private: limited to specific users or teams.
• Internal: visible inside an enterprise organization only.
• Archived: read-only storage for finished projects.

Pull Requests

Pull requests are the core of GitHub collaboration. They let teams:

• Propose changes: merge work from one branch into another.
• Review code: leave inline comments and suggestions.
• Run checks: require automated tests and status checks before merge.
• Discuss decisions: keep implementation discussions next to the code.
• Require approvals: set reviews from specific people or teams.

Issues and Project Management

• Issues: track bugs, features, and tasks.
• Organization: use labels, milestones, and assignees.
• Project boards: visualize work in kanban-style boards.
• Automatic linking: connect issues to commits and pull requests.
• Templates: standardize bug reports and feature requests.

Code Review Capabilities

• Line comments: comment on specific lines of a change.
• Suggested edits: apply proposed fixes with one click.
• Review states: approve, comment, or request changes.
• Protected branches: require reviews before merging.
• CODEOWNERS: assign reviewers automatically.

GitHub Actions for CI/CD

• Build, test, deploy: automate pipelines directly from repositories.
• Event triggers: run on push, pull request, schedule, or manual dispatch.
• Reusable actions: use shared workflows and community actions from the Marketplace.
• Matrix builds: test across operating systems, versions, or configurations.
• Secrets: store credentials and API keys securely.
• Self-hosted runners: run jobs on your own infrastructure.

Security and Dependency Management

• Dependabot: opens pull requests to update dependencies.
• Security advisories: manage vulnerability disclosure.
• Code scanning: detects security issues in code.
• Secret scanning: flags exposed credentials.
• Dependency graph: shows what your project depends on.

GitHub in the Development Ecosystem

• Social coding: follow developers, star repositories, fork projects, and contribute to open source.
• Documentation: Markdown READMEs, wikis, and GitHub Pages for static sites.
• Package distribution: GitHub Packages for npm, Maven, and container images, plus release artifacts.
• Team management: organizations, team hierarchies, fine-grained permissions, and audit logs.

This feature set makes GitHub a full platform for software collaboration and automation, not just a code host.

Why GitHub Matters

Enabling Modern Collaboration

• Single source of truth: code, tests, docs, and config live in versioned repositories.
• Historical context: commit messages explain every change.
• Searchable code: fast search across files and history.
• Asynchronous review: teammates review code on their own schedules across time zones.
• Quality gates: required reviews and status checks enforce standards before merge.
• Knowledge sharing: review comments spread best practices and domain knowledge.

Powering Automation and Continuous Delivery

• Native CI/CD: GitHub Actions runs pipelines without a separate CI tool.
• Event-driven runs: workflows trigger on pushes, pull requests, schedules, or custom events.
• Marketplace: thousands of prebuilt actions cover common tasks.
• Deployment automation: deploy to cloud platforms, Kubernetes, or servers.
• GitOps: Kubernetes manifests, Helm charts, and Terraform live next to app code and change through pull requests.

Benefits for Test Automation

• Automatic triggers: tests run on new commits, pull requests, schedules, or manual dispatch.
• Status checks: failed tests block merges and show directly in pull requests.
• Annotations: failed tests can point to specific lines of code.
• Versioned test code: scripts, data, and fixtures are reviewed like app code.
• Path filters: run only the tests relevant to the files that changed.

A B2B SaaS Example

Picture a customer data platform with a monorepo of 40 services on GitHub. Every pull request triggered the full test suite on GitHub-hosted runners. The runs were slow, and they could not reach internal services inside the Kubernetes cluster.

The team keeps GitHub Actions as the trigger but hands execution to Testkube in the cluster. Tests now reach internal services directly, and runner minutes drop.

Our Perspective: Let GitHub Trigger, Let the Cluster Execute

GitHub Actions is great at reacting to repository events. It is less suited to running heavy integration tests that need access to private cluster services.

Splitting the job works well. GitHub decides when to test, and the cluster decides how to run it.

GitHub Integration in Testkube

Testkube extends testing beyond GitHub-hosted runners and into Kubernetes:

• GitHub Actions integration: set up the Testkube CLI with the official setup-testkube action and run Test Workflows from any workflow.
• Tests from GitHub repos: Test Workflows can clone test code from public or private GitHub repositories at run time.
• Event-driven testing: trigger tests on pull requests, merges, or tag creation.
• Results in GitHub: pass or fail status flows back to Actions logs and pull request checks, with full details in Testkube.

Example: Running Testkube from GitHub Actions

This workflow installs the Testkube CLI and connects to your environment. It then runs a Test Workflow on every pull request to main:

name: Testkube regression
on:
  pull_request:
    branches: [ main ]
jobs:
  run-tests:
    runs-on: ubuntu-latest
    steps:
    - uses: kubeshop/setup-testkube@v1
      with:
        organization: ${{ secrets.TK_ORG_ID }}
        environment: ${{ secrets.TK_ENV_ID }}
        token: ${{ secrets.TK_API_TOKEN }}
    - name: Run Testkube workflow
      run: testkube run testworkflow regression-suite -f

Understanding the Workflow Configuration

• on.pull_request: runs the job whenever a pull request targets the main branch.
• runs-on: uses a GitHub-hosted Ubuntu runner. Self-hosted runners also work.
• kubeshop/setup-testkube: installs the Testkube CLI and connects it to your organization and environment.
• Secrets: the organization ID, environment ID, and API token are stored as GitHub secrets.
• testkube run testworkflow: starts the regression-suite workflow in your cluster. The -f flag follows the run until it finishes.

Workflow Trigger Options

You can change when the workflow runs with GitHub event triggers. Each block below is a separate option:

# Pull request testing
on:
  pull_request:
    branches: [ main, develop ]

# Push-based testing
on:
  push:
    branches: [ main ]

# Scheduled testing (daily at 2 AM UTC)
on:
  schedule:
  - cron: '0 2 * * *'

# Manual triggering
on:
  workflow_dispatch:

Benefits of GitHub Actions Integration

• Unified workflow: tests run inside your existing GitHub process, with no new CI tool to learn.
• Native status checks: results appear on pull requests and can block merges.
• Traceability: Actions history links each run to a commit, branch, or pull request.
• Lower runner usage: tests execute in your cluster, while GitHub Actions only coordinates the run.
• Flexible targeting: run only relevant tests based on changed files, labels, or branches.

Frequently Asked Questions (FAQs)