Questions in: GitLab

In Google Cloud Platform (GCP), IAM (Identity and Access Management) roles define what actions a user or service account can perform on resources.

There are 3 types of IAM roles:

1. Basic Roles: Broad permissions (e.g., Viewer, Editor, Owner).

2. Predefined Roles: Granular roles created by GCP for specific services (e.g., Storage Admin, Compute Viewer).

3. Custom Roles: User-defined roles with selected permissions.

To manage permissions:

• Assign roles to users, groups, or service accounts at the project, folder, or resource level.

• Use the IAM policy binding (gcloud projects add-iam-policy-binding) or the GCP Console.

• Follow the principle of least privilege—grant only the minimum permissions needed.

Roles ensure secure and controlled access to GCP resources.

In GitOps:

• Used GitLab as the single source of truth for infrastructure as code.

• Implemented CI/CD pipelines to auto-deploy to Kubernetes clusters using tools like ArgoCD or Flux.

• Managed environment states entirely through version-controlled Git repositories.

In DevSecOps:

• Integrated GitLab’s built-in security features (SAST, DAST, dependency scanning, secret detection) into pipelines.

• Enforced security checks before merge approvals.

• Used GitLab CI/CD to automate compliance and vulnerability checks throughout the development lifecycle.

Overall, GitLab streamlined the deployment and security process through automation and transparency.

To troubleshoot a failed GitLab CI pipeline:

1. ✅ Check the pipeline/job logs for error messages.

2. 🔄 Verify the .gitlab-ci.yml syntax and job dependencies.

3. 🔐 Confirm required environment variables and secrets exist.

4. 🧪 Test failing commands locally to reproduce the issue.

5. 📦 Ensure runners have necessary tools and permissions.

6. 🔁 Retry the job or pipeline after fixing identified problems.

• only: Run job only for specified conditions (e.g., branches).

• except: Skip job for specified conditions.

• rules: More advanced, flexible replacement for only/except.

• when: Controls job timing (e.g., manual, always, on_success).

How It Works:

1. Detection: GitLab detects your project’s language and framework automatically.

2. CI/CD Pipeline: It auto-generates .gitlab-ci.yml using predefined CI templates.

3. Build: Builds a Docker image using Auto Build.

4. Test: Runs auto-generated tests.

5. Code Quality & SAST: Runs code quality analysis and security scans.

6. Review App: Deploys temporary environments for each merge request.

7. Deploy: Auto-deploys to Kubernetes using Helm charts.

8. Monitor: Provides performance metrics and logging if integrated.

🟢 Requirements:

• Kubernetes cluster connected to GitLab

• GitLab Runner

• Enable Auto DevOps in project settings

Jira Integration with GitLab

• Go to GitLab:
  → Settings → Integrations → Select Jira

• Enter:

  • Jira URL

  • Project Key

  • Username + API token

• Enables:

  • Linking GitLab commits/MRs to Jira issues using JIRA-123 in commit messages

  • Jira issue status updates

✅ Slack Integration with GitLab

• Go to GitLab:
  → Settings → Integrations → Select Slack notifications

• Enter:

  • Webhook URL (from your Slack app or channel)

  • Channel name

  • Choose events (push, merge request, pipeline, etc.)

• Enables:

  • GitLab events trigger messages in Slack channels

✅ Other Tools (e.g., Trello, Microsoft Teams, Jenkins)

• GitLab supports integrations via:

  • Webhooks

  • API tokens

  • Custom scripts in .gitlab-ci.yml

  • GitLab Apps/Marketplace

Example webhook:
→ Settings → Webhooks
→ Add URL of external service and select trigger events

Steps to Deploy to Kubernetes Using GitLab CI/CD:

1. Connect GitLab to Your Kubernetes Cluster
   → In your GitLab project:
   Settings → CI/CD → Kubernetes
   → Add your cluster credentials (API URL, CA cert, Token, etc.).

2. Define .gitlab-ci.yml Pipeline
   Example:

   yaml

   CopyEdit

   image: bitnami/kubectl:latest

   stages:
   - deploy

   deploy:
stage: deploy
script:
- kubectl config set-cluster my-cluster --server=$KUBE_URL --certificate-authority=$KUBE_CA
- kubectl config set-credentials gitlab --token=$KUBE_TOKEN
- kubectl config set-context default --cluster=my-cluster --user=gitlab
- kubectl config use-context default
- kubectl apply -f k8s/deployment.yaml


3. Store Sensitive Variables Securely
   → Add KUBE_URL, KUBE_TOKEN, and KUBE_CA in GitLab CI/CD variables.

4. Add Your Kubernetes YAML Files
   → Add deployment files like deployment.yaml, service.yaml inside a folder (e.g., /k8s).

5. Optional: Use Helm Charts
   Replace kubectl apply with:

   - helm upgrade --install my-app ./chart


🔒 Make sure access is secure and only CI/CD has permission to deploy.

To handle secrets in GitLab pipelines:

1. Use CI/CD Variables
   → Go to Settings → CI/CD → Variables and add secrets (e.g., API keys).

2. Mask and Protect
   → Enable Masked (hides in logs) and Protected (only used in protected branches).

3. Access in .gitlab-ci.yml

   yaml

   script:
- echo "$MY_SECRET"


4. Avoid Hardcoding
   → Never put secrets directly in the pipeline or code.

5. Use Group Variables
   → For shared secrets across projects.

6. Optional: Use Secret Managers
   → Integrate tools like HashiCorp Vault or AWS Secrets Manager.

In GitLab CI/CD:

- parallel: N runs the same job N times concurrently.
- parallel: matrix: runs jobs with different variable combinations.

Used for faster builds/tests across configs or environments.

In GitLab CI/CD, the needs keyword defines job dependencies and allows jobs to run earlier by enabling parallel execution when possible.

✅ Purpose:

It tells GitLab that a job depends on the output of another job.

🔧 Syntax:

📌 When to use:

• To reduce pipeline time by skipping stage sequencing

• When jobs in later stages need artifacts/results from earlier jobs

• For creating DAG-style (Directed Acyclic Graph) pipelines

In GitLab CI/CD, you can set environment variables in several ways:

1. 🔧 In the GitLab UI (recommended for secrets)

• Go to: Project → Settings → CI/CD → Expand Variables

• Add key-value pairs (e.g., API_KEY = abc123)

• You can mark them as protected or masked

2. 📝 In .gitlab-ci.yml

3. 📦 In job definitions

✅ Tip: Use UI for sensitive values (API keys, tokens) and .gitlab-ci.yml for general config.

In GitLab CI/CD, you use artifacts and caches to manage files between pipeline jobs:

🔹 Artifacts:

• Used to pass files from one job to another.

• Saved files after a job finishes (e.g., compiled binaries, test reports).

• Defined using:

  artifacts:
paths:
- build/
expire_in: 1 hour


🔹 Cache:

• Used to speed up jobs by reusing dependencies (like npm packages, pip installs).

• Not passed between jobs but stored for reuse.

• Defined using:

  cache:
paths:
- node_modules/


✅ Use artifacts to share outputs.
✅ Use cache to reduce build time.

The difference between Shared and Specific Runners in GitLab:

🔹 Shared Runners

• Available to all projects in a GitLab instance.

• Useful for CI/CD across multiple projects.

• Maintained by GitLab or an admin.

• Suitable for general-purpose jobs.

🔹 Specific Runners

• Assigned to a specific project or group.

• Provide more control over the runner environment.

• Ideal for jobs that need special dependencies or isolation.

✅ Use Shared Runners for simplicity.
✅ Use Specific Runners for customization or security.

Types of GitLab Runners:

1. Shared Runners – Provided by GitLab, available to all projects in an instance.

2. Specific Runners – Dedicated to a project or group, gives more control over environment.

Executors used by runners include:

• Shell

• Docker

• Kubernetes

• SSH

• Custom

They determine how and where the job runs.

In GitLab CI/CD, you can trigger pipelines in several ways:

🔹 1. Manually (From GitLab UI):

• Go to CI/CD > Pipelines in your project.

• Click the “Run pipeline” button.

• You can choose a branch and pass variables.

🔹 2. On Specific Events:

• push: Automatically triggered on code push.

• merge_request_events: On merge requests.

• schedule: Using CI/CD > Schedules to run periodically.

• tags: Trigger when a tag is pushed.

🔹 3. Via .gitlab-ci.yml Rules:

Use rules, only, or except to specify conditions:

🔹 4. Trigger Token (API):

Use the GitLab API and a trigger token to start pipelines externally:

These options give you flexibility for automation and control over your CI/CD process.

🔹 Common Stages:

1. build – Compile or build your application.

2. test – Run unit, integration, or other automated tests.

3. deploy – Deploy your app to staging or production.

4. review – Create review apps for testing in an isolated environment.

5. cleanup – Clean up temporary resources or cache.

✅ You can customize and define any number of stages in your .gitlab-ci.yml file depending on your workflow. Jobs in each stage run in parallel, and stages run sequentially.

🔹 Key Features:

• Code Review: Team members can review code, comment, and suggest changes.

• Pipeline Integration: CI/CD pipelines automatically run (e.g. tests, builds) before merging.

• Approvals: You can set required approvals before allowing merge.

• Conflict Detection: GitLab checks for merge conflicts automatically.

• Squash & Merge: Option to squash commits into a single commit on merge.

• Merge Strategies: Merge commit, fast-forward, or squash merge.

✅ Summary: MRs ensure quality and collaboration by combining code review, automated testing, and controlled merging.

🔹 Purpose:

It tells GitLab:

• What jobs to run (e.g., build, test, deploy)

• When to run them

• In what order

🔹 Key Components:

• stages: Defines stages like build, test, deploy.

• jobs: Specific tasks under each stage.

• script: Commands to execute in a job.

• rules / only / except: Define when jobs should run.

• artifacts: Files to pass between jobs or store.

💡 Summary: It automates your development workflow by defining CI/CD steps in a single YAML file at the root of your repository.

In GitLab, access control is managed using:

1. Project & Group Memberships:

• Users are assigned roles at the project or group level.

2. Role-Based Permissions:

Common roles include:

• Guest – limited access (issues, comments)

• Reporter – can view and download code

• Developer – can push code, create branches

• Maintainer – full access, including CI/CD and settings

• Owner (group level only) – manage everything, including members

3. Private, Internal, and Public Visibility:

• Controls who can access the project/repo.

4. Protected Branches and Tags:

• Limit who can push, merge, or delete branches/tags.

5. Access Tokens:

• Personal, project, or group access tokens for CI/CD or API use.

These tools together help enforce secure and flexible access policies in GitLab.

In GitLab:

- Groups are containers that organize related projects and manage permissions for multiple users. Think of them like folders or teams.

- Projects are where your actual code, issues, CI/CD pipelines, and settings live.

Key Differences:

So, Groups = Organization level, and Projects = Actual work/code.