gitlab-ci-cd-and-github-actions - ci-cd-pipelines Interview Questions | Preplance

Mobile App Now Available

Master Interviews
Anywhere, Anytime

Get the Preplance app for a seamless learning experience. Practice offline, get daily streaks, and stay ahead with real-time interview updates.

Get it on

Google Play

4.9/5 Rating on Store

3. Compare Jenkins, GitLab CI/CD, and GitHub Actions. Discuss architecture, configuration, features, scalability, pricing, and use cases for each.

Difficulty: HardType: SubjectiveTopic: CI/CD Fundamentals

Architecture comparison: Jenkins: self-hosted, master-agent architecture. Master manages configuration and schedules jobs, agents execute builds. Flexible but requires infrastructure management. Plugin-based extensibility with 1500+ plugins. Highly customizable but steeper learning curve. GitLab CI/CD: integrated with GitLab (self-hosted or cloud). Runners execute jobs, managed similarly to Jenkins agents. Tight GitLab integration (issue tracking, merge requests, security scanning) providing complete DevOps platform. Can use shared runners on GitLab.com or self-hosted runners. GitHub Actions: cloud-native, integrated with GitHub. GitHub-hosted runners or self-hosted runners. Serverless execution model - no master server to manage. Marketplace with thousands of reusable actions. Designed for GitHub ecosystem. Configuration: Jenkins: Jenkinsfile (Declarative or Scripted Pipeline) or GUI configuration. Groovy-based, powerful but requires learning curve. Supports complex logic with full programming capabilities. GitLab CI/CD: .gitlab-ci.yml YAML file. Straightforward syntax with stages, jobs, rules. Includes/extends for reusability. Good balance of simplicity and power. GitHub Actions: .github/workflows/*.yml YAML files. Event-driven workflows. Marketplace actions reduce configuration complexity. Matrix strategy for multi-configuration testing. Features comparison: Jenkins: - Mature ecosystem with extensive plugins - Blue Ocean modern UI - Distributed builds - Pipeline as Code - Shared Libraries - Approval gates - Cons: requires maintenance, setup complexity GitLab CI/CD: - Integrated with GitLab SCM - Auto DevOps for automated pipelines - Built-in container registry - Security scanning (SAST, DAST, dependency scanning) - Kubernetes integration - Review apps for preview environments - Cons: tied to GitLab ecosystem GitHub Actions: - Native GitHub integration - Extensive marketplace - Matrix builds - Reusable workflows - Environments with protection rules - GitHub Packages integration - Cons: GitHub-specific, limited runner customization compared to Jenkins Scalability: Jenkins: highly scalable with agent pools, cloud agents (AWS, Azure, GCP, Kubernetes), autoscaling support. Requires managing infrastructure but offers maximum control. GitLab CI/CD: scalable with runner autoscaling (Docker Machine, Kubernetes), shared runners on GitLab.com handle scaling automatically. Good balance of managed and self-hosted options. GitHub Actions: GitHub-hosted runners scale automatically (managed by GitHub), self-hosted runners require manual scaling but support autoscaling with custom solutions. Cloud-native approach simplifies scaling. Pricing: Jenkins: free and open-source but requires infrastructure costs (servers, maintenance, support). Total cost includes hosting, maintenance time, support. GitLab CI/CD: free tier with shared runners (400 compute minutes/month for GitLab.com free plan), paid tiers offer more minutes and features, self-hosted GitLab CE is free (unlimited builds), EE has premium features. Costs: subscription or self-hosting infrastructure. GitHub Actions: free for public repositories, private repositories get 2000-3000 minutes/month (varies by plan), additional minutes purchasable. Self-hosted runners free but require infrastructure. Costs: GitHub subscription and runner infrastructure. Use cases: Jenkins best for: - Organizations with existing Jenkins investment - Complex, customized workflows requiring flexibility - On-premise requirements - Multi-SCM environments (Git, SVN, Mercurial) - Need for specific plugins - Maximum control over infrastructure GitLab CI/CD best for: - Teams using GitLab for SCM - Organizations wanting complete DevOps platform - Need for integrated security scanning - Kubernetes-native workflows - Review apps and preview environments - Self-hosted with good scaling GitHub Actions best for: - GitHub-based projects - Open-source projects (free unlimited minutes) - Minimal infrastructure management desired - Leveraging marketplace ecosystem - Quick setup and getting started - Modern, cloud-native approach Migration considerations: - Jenkins to GitLab/GitHub: port Jenkinsfile to YAML, adapt plugins to native features or marketplace actions - GitLab to GitHub: convert .gitlab-ci.yml to workflows, adapt GitLab-specific features - All platforms support Pipeline as Code, artifacts, caching, parallel execution Decision factors: existing toolchain, team expertise, hosting preference (cloud vs self-hosted), budget, required features, integration needs, scalability requirements. Understanding platform differences enables choosing appropriate CI/CD solution for specific organizational needs.

4. Explain advanced CI/CD patterns including multi-stage pipelines, pipeline orchestration, trunk-based development workflows, and deployment strategies integration.

Difficulty: HardType: SubjectiveTopic: Pipeline Concepts

Multi-stage pipelines organize CI/CD into logical phases with progression gates. Example GitLab: ```yaml stages: - build - test - security - staging - production build: stage: build script: make build artifacts: paths: [dist/] unit_test: stage: test script: make test integration_test: stage: test script: make integration-test needs: [build] sast: stage: security script: semgrep scan deploy_staging: stage: staging script: deploy staging environment: name: staging url: https://staging.example.com deploy_production: stage: production script: deploy production when: manual only: [main] environment: name: production url: https://example.com ``` Pipeline orchestration coordinates multiple pipelines across repositories. Parent-child pipelines in GitLab: ```yaml # Parent pipeline trigger_backend: stage: test trigger: project: team/backend strategy: depend # Wait for triggered pipeline trigger_frontend: stage: test trigger: project: team/frontend ``` GitHub Actions workflow dependencies: ```yaml # Backend workflow triggers frontend - name: Trigger Frontend uses: peter-evans/repository-dispatch@v2 with: token: ${{ secrets.PAT }} repository: org/frontend event-type: backend-updated ``` Trunk-based development workflow with short-lived feature branches: ```yaml # GitHub Actions on: push: branches: [main] pull_request: branches: [main] jobs: pr-checks: if: github.event_name == 'pull_request' runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - run: npm test - run: npm run lint deploy: if: github.ref == 'refs/heads/main' needs: pr-checks runs-on: ubuntu-latest steps: - run: ./deploy.sh production ``` Feature flag integration for trunk-based development: ```yaml deploy: stage: deploy script: - deploy --feature-flags=new-ui:50% environment: production ``` Blue-green deployment pattern: ```yaml # GitLab stages: - deploy - switch - cleanup deploy_green: stage: deploy script: - deploy green-environment - run-smoke-tests green environment: name: production-green switch_traffic: stage: switch script: - switch-load-balancer blue green when: manual cleanup_blue: stage: cleanup script: - cleanup blue-environment when: manual ``` Canary deployment with progressive rollout: ```yaml # GitHub Actions - name: Deploy Canary run: | kubectl set image deployment/app app=myapp:${{ github.sha }} kubectl patch deployment app -p '{"spec":{"replicas":1}}' - name: Monitor Canary run: ./monitor-metrics.sh timeout-minutes: 10 - name: Full Rollout if: success() run: kubectl scale deployment/app --replicas=10 - name: Rollback if: failure() run: kubectl rollout undo deployment/app ``` Rollback mechanism: ```yaml rollback_production: stage: rollback script: - kubectl rollout undo deployment/app when: manual only: [main] environment: name: production action: rollback ``` Approval gates for production: ```yaml # GitLab deploy_prod: stage: production script: deploy production when: manual only: [main] environment: name: production # GitHub Actions production: runs-on: ubuntu-latest environment: name: production required-reviewers: ['ops-team'] steps: - run: ./deploy.sh ``` Post-deployment verification: ```yaml verify_deployment: stage: verify script: - curl https://production.example.com/health - run-integration-tests production retry: max: 2 when: script_failure ``` Monitoring integration: ```yaml - name: Send Deployment Event run: | curl -X POST https://monitoring.example.com/api/events \ -d '{"type":"deployment","version":"${{ github.sha }}"}' - name: Check Error Rate run: | ERROR_RATE=$(query-prometheus) if [ $ERROR_RATE -gt 1 ]; then echo "High error rate detected" exit 1 fi ``` Dynamic environment creation (review apps): ```yaml review_app: stage: review script: - deploy review-app-$CI_MERGE_REQUEST_IID environment: name: review/$CI_MERGE_REQUEST_IID url: https://review-$CI_MERGE_REQUEST_IID.example.com on_stop: stop_review_app only: - merge_requests stop_review_app: stage: review script: - destroy review-app-$CI_MERGE_REQUEST_IID environment: name: review/$CI_MERGE_REQUEST_IID action: stop when: manual ``` Understanding advanced patterns enables building sophisticated CI/CD workflows supporting modern development practices and deployment strategies.

5. Explain security best practices for CI/CD pipelines. Include secrets management, artifact security, vulnerability scanning, and supply chain security.

Difficulty: HardType: SubjectiveTopic: CI/CD Security

Secrets management is critical for CI/CD security. Never commit secrets to repositories. Use platform secret managers: GitLab CI/CD variables (masked and protected): ```yaml variables: PUBLIC_VAR: "visible" # SECRET_VAR configured in GitLab UI (Settings > CI/CD > Variables) # Mark as "Masked" to hide in logs # Mark as "Protected" to limit to protected branches deploy: script: - deploy --api-key=$SECRET_VAR ``` GitHub Actions secrets: ```yaml steps: - name: Deploy run: ./deploy.sh env: API_KEY: ${{ secrets.API_KEY }} DATABASE_URL: ${{ secrets.DATABASE_URL }} ``` External secret management integration (HashiCorp Vault): ```yaml # GitLab vault_secrets: image: vault:latest script: - export VAULT_TOKEN=$(vault login -method=jwt role=my-role jwt=$CI_JOB_JWT -field=token) - export SECRET=$(vault kv get -field=value secret/api-key) - deploy --api-key=$SECRET ``` ```yaml # GitHub Actions with Vault - name: Import Secrets uses: hashicorp/vault-action@v2 with: url: https://vault.example.com method: jwt role: github-actions secrets: | secret/data/api key | API_KEY secret/data/db password | DB_PASS ``` Rotate secrets regularly, use short-lived tokens when possible, limit secret scope (per-project, per-environment), audit secret access. Artifact security ensures build outputs are safe. Sign artifacts for verification: ```yaml # Sign container images - name: Sign Image run: | cosign sign --key cosign.key myapp:${{ github.sha }} ``` Verify artifact integrity: ```yaml - name: Verify Signature run: | cosign verify --key cosign.pub myapp:${{ github.sha }} ``` Vulnerability scanning detects security issues: Container scanning: ```yaml # GitLab (built-in) container_scanning: stage: test variables: DOCKER_IMAGE: myapp:latest allow_failure: true # GitHub Actions with Trivy - name: Scan Image uses: aquasecurity/trivy-action@master with: image-ref: 'myapp:${{ github.sha }}' format: 'sarif' output: 'trivy-results.sarif' severity: 'CRITICAL,HIGH' - name: Upload Results uses: github/codeql-action/upload-sarif@v2 with: sarif_file: 'trivy-results.sarif' ``` Dependency scanning: ```yaml # GitLab (built-in) dependency_scanning: stage: test artifacts: reports: dependency_scanning: gl-dependency-scanning-report.json # GitHub Actions with Snyk - name: Snyk Test uses: snyk/actions/node@master env: SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }} with: args: --severity-threshold=high ``` Static Application Security Testing (SAST): ```yaml # GitLab sast: stage: test artifacts: reports: sast: gl-sast-report.json # GitHub Actions with Semgrep - name: Semgrep uses: returntocorp/semgrep-action@v1 with: config: auto ``` Dynamic Application Security Testing (DAST): ```yaml dast: stage: security image: owasp/zap2docker-stable script: - zap-baseline.py -t https://staging.example.com ``` Supply chain security protects against compromised dependencies: Dependency pinning (lock files): ```yaml - name: Verify Lock File run: | if ! git diff --exit-code package-lock.json; then echo "Lock file changed, failing build" exit 1 fi ``` Software Bill of Materials (SBOM): ```yaml - name: Generate SBOM uses: anchore/sbom-action@v0 with: image: myapp:${{ github.sha }} format: cyclonedx output-file: sbom.json - name: Upload SBOM uses: actions/upload-artifact@v3 with: name: sbom path: sbom.json ``` Code signing with Sigstore: ```yaml - name: Sign Artifacts uses: sigstore/cosign-installer@main - run: | cosign sign-blob --key cosign.key artifact.tar.gz > artifact.tar.gz.sig ``` Access control for pipelines: - Protected branches (only certain users can merge/push) - Required reviews before pipeline runs - Branch protection rules - Environment-specific permissions GitHub: ```yaml environment: name: production required-reviewers: ['security-team', 'ops-lead'] ``` GitLab protected environments (Settings > CI/CD > Protected Environments). Audit logging: ```yaml - name: Log Deployment run: | echo "Deployed by ${{ github.actor }} at $(date)" >> audit.log curl -X POST https://audit.example.com/log \ -d '{"user":"${{ github.actor }}","action":"deploy"}' ``` Network security: - Private runners/agents behind firewall - Egress filtering (allow only necessary external access) - Secrets for webhook authentication - HTTPS for all communications Compliance as Code: ```yaml compliance_check: stage: validate script: - run-compliance-tests - check-license-compliance - verify-security-policies ``` Best practices: never commit secrets, use platform secret managers, integrate with Vault/AWS Secrets Manager for production, scan all dependencies, scan containers before deployment, implement SAST/DAST, generate and track SBOMs, sign artifacts, limit pipeline permissions, enable audit logging, regularly update dependencies, use automated security scanning in every pipeline. Understanding security practices prevents breaches and ensures compliance in CI/CD workflows.

7. Explain GitLab CI/CD architecture and .gitlab-ci.yml syntax in detail. Include stages, jobs, artifacts, cache, dependencies, and advanced features.

Difficulty: HardType: SubjectiveTopic: GitLab CI/CD

GitLab CI/CD YAML structure starts with defining stages (pipeline phases). Stages run sequentially, jobs within stages run in parallel. Default stages are build, test, deploy but custom stages can be defined: ```yaml stages: - build - test - security - deploy - cleanup ``` Jobs are tasks within stages. Job definition includes stage assignment, script (commands to run), and optional directives: ```yaml build_app: stage: build image: node:18 script: - npm install - npm run build artifacts: paths: - dist/ expire_in: 1 week cache: key: ${CI_COMMIT_REF_SLUG} paths: - node_modules/ only: - main - merge_requests ``` Artifacts are files generated by jobs passed to subsequent jobs or downloadable after pipeline completes. artifacts keyword specifies paths to preserve. Artifacts persist between stages allowing test stage to use build stage outputs. Example: build job creates dist/ directory, test job uses it: ```yaml test_app: stage: test dependencies: - build_app script: - npm test ``` Cache speeds up jobs by storing dependencies between pipeline runs. Unlike artifacts (passed between jobs in same pipeline), cache persists across pipelines. Cache key determines cache uniqueness, typically using branch name or lock file hash: ```yaml cache: key: files: - package-lock.json paths: - node_modules/ ``` Dependencies specify which jobs' artifacts this job needs. Without dependencies, job receives all previous stage artifacts. With dependencies: [job1, job2], only specified artifacts are available. Variables define environment variables: ```yaml variables: DATABASE_URL: "postgres://localhost/db" DEPLOY_ENV: "staging" job: script: - echo $DATABASE_URL ``` GitLab provides predefined variables (CI_COMMIT_SHA, CI_PIPELINE_ID, CI_COMMIT_BRANCH). Rules provide advanced conditional execution: ```yaml job: script: echo "Deploy" rules: - if: '$CI_PIPELINE_SOURCE == "merge_request_event"' when: never - if: '$CI_COMMIT_BRANCH == "main"' when: on_success - when: manual ``` Before_script and after_script run before/after main script: ```yaml job: before_script: - echo "Setup" script: - echo "Main task" after_script: - echo "Cleanup" ``` Services provide additional containers for job (databases, caches): ```yaml test: image: node:18 services: - postgres:13 variables: POSTGRES_DB: testdb script: - npm test ``` Includes enable reusing configuration: ```yaml include: - local: '.gitlab-ci-templates.yml' - project: 'group/project' file: '/templates/ci.yml' - remote: 'https://example.com/ci-template.yml' ``` Extends inherits configuration from templates: ```yaml .deploy_template: script: - ./deploy.sh only: - main deploy_staging: extends: .deploy_template variables: ENVIRONMENT: staging deploy_prod: extends: .deploy_template variables: ENVIRONMENT: production ``` Triggers for multi-project pipelines: ```yaml trigger_downstream: stage: deploy trigger: project: group/downstream-project branch: main ``` Understanding GitLab CI/CD YAML syntax enables building sophisticated pipelines with proper dependency management, caching strategies, and modular configuration.

8. Explain GitHub Actions workflow syntax comprehensively. Include events, jobs, steps, actions, contexts, and advanced patterns.

Difficulty: HardType: SubjectiveTopic: GitHub Actions

GitHub Actions workflow starts with name and trigger events: ```yaml name: CI/CD Pipeline on: push: branches: [ main, develop ] paths: - 'src/**' pull_request: branches: [ main ] schedule: - cron: '0 2 * * *' # Daily at 2 AM workflow_dispatch: # Manual trigger inputs: environment: description: 'Deployment environment' required: true default: 'staging' ``` Jobs define workflow tasks running in parallel by default. Jobs can have dependencies using needs: ```yaml jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - run: npm install - run: npm run build - uses: actions/upload-artifact@v3 with: name: dist path: dist/ test: needs: build runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: actions/download-artifact@v3 with: name: dist - run: npm test deploy: needs: [build, test] runs-on: ubuntu-latest if: github.ref == 'refs/heads/main' steps: - run: ./deploy.sh ``` Steps are individual tasks in job. Steps can run commands (run) or use actions (uses): ```yaml steps: - name: Checkout code uses: actions/checkout@v3 - name: Setup Node.js uses: actions/setup-node@v3 with: node-version: '18' cache: 'npm' - name: Install dependencies run: npm ci - name: Run tests run: npm test env: NODE_ENV: test ``` Actions are reusable units from marketplace or custom. Actions have inputs (with) and outputs: ```yaml - uses: docker/build-push-action@v4 with: context: . push: true tags: ${{ secrets.DOCKER_USERNAME }}/myapp:latest cache-from: type=gha cache-to: type=gha,mode=max ``` Contexts provide information about workflow run: ```yaml steps: - name: Print context info run: | echo "Event: ${{ github.event_name }}" echo "Branch: ${{ github.ref }}" echo "Commit: ${{ github.sha }}" echo "Actor: ${{ github.actor }}" echo "Runner OS: ${{ runner.os }}" echo "Job status: ${{ job.status }}" ``` Secrets access sensitive data: ```yaml - name: Deploy run: ./deploy.sh env: AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} ``` Matrix strategy for multiple configurations: ```yaml strategy: matrix: os: [ubuntu-latest, windows-latest, macos-latest] node: [14, 16, 18] fail-fast: false runs-on: ${{ matrix.os }} steps: - uses: actions/setup-node@v3 with: node-version: ${{ matrix.node }} ``` Conditionals control step/job execution: ```yaml steps: - name: Deploy to staging if: github.ref == 'refs/heads/develop' run: ./deploy-staging.sh - name: Deploy to production if: github.ref == 'refs/heads/main' && success() run: ./deploy-prod.sh ``` Environments for deployment protection: ```yaml jobs: deploy: runs-on: ubuntu-latest environment: name: production url: https://example.com steps: - run: ./deploy.sh ``` Environments can have required reviewers and wait timers. Reusable workflows enable workflow composition: ```yaml # .github/workflows/reusable-deploy.yml on: workflow_call: inputs: environment: required: true type: string secrets: deploy-key: required: true jobs: deploy: runs-on: ubuntu-latest steps: - run: ./deploy.sh ${{ inputs.environment }} env: DEPLOY_KEY: ${{ secrets.deploy-key }} # .github/workflows/main.yml jobs: deploy-staging: uses: ./.github/workflows/reusable-deploy.yml with: environment: staging secrets: deploy-key: ${{ secrets.STAGING_KEY }} ``` Understanding GitHub Actions syntax enables building sophisticated workflows with proper dependency management, reusability, and integration with GitHub ecosystem.

9. Explain GitLab Runner architecture, executor types, registration, and configuration. Include Docker, Kubernetes, and autoscaling setups.

Difficulty: HardType: SubjectiveTopic: Runners & Agents

GitLab Runner is an application executing jobs from GitLab CI/CD. Runner architecture consists of runner manager (coordinates job execution), executor (environment where job runs), and job executor (specific implementation for platform). Runner polls GitLab instance for jobs matching its tags, downloads job artifacts, executes job script, uploads results and artifacts. Executor types determine how jobs run. Shell executor runs commands directly on runner machine, sharing environment with runner process. Simple but no isolation: ```toml [[runners]] name = "shell-runner" executor = "shell" ``` Use for simple cases or when runner has required tools installed. Docker executor runs each job in fresh Docker container providing isolation, clean environment per job, and easy tool management via Docker images: ```toml [[runners]] name = "docker-runner" executor = "docker" [runners.docker] image = "alpine:latest" privileged = false volumes = ["/cache", "/var/run/docker.sock:/var/run/docker.sock"] ``` Jobs specify image: ```yaml job: image: node:18 script: - npm test ``` Docker executor with DinD (Docker-in-Docker) enables building Docker images: ```yaml build_image: image: docker:20.10 services: - docker:20.10-dind variables: DOCKER_TLS_CERTDIR: "/certs" script: - docker build -t myapp . ``` Kubernetes executor runs jobs as Kubernetes pods, ideal for cloud-native environments: ```toml [[runners]] name = "k8s-runner" executor = "kubernetes" [runners.kubernetes] namespace = "gitlab-runner" image = "alpine:latest" privileged = false cpu_request = "100m" memory_request = "128Mi" service_cpu_request = "100m" service_memory_request = "128Mi" ``` Runner registration connects runner to GitLab: ```bash gitlab-runner register \ --non-interactive \ --url "https://gitlab.com/" \ --registration-token "PROJECT_REGISTRATION_TOKEN" \ --executor "docker" \ --docker-image "alpine:latest" \ --description "docker-runner" \ --tag-list "docker,linux" \ --locked="false" ``` Registration types: shared runners (available to all projects in GitLab instance), group runners (available to all projects in group), specific runners (tied to specific projects). Runners match jobs based on tags. Autoscaling with Docker Machine enables dynamic runner provisioning based on load: ```toml [[runners]] executor = "docker+machine" [runners.machine] IdleCount = 2 IdleTime = 600 MaxBuilds = 100 MachineDriver = "amazonec2" MachineName = "gitlab-runner-%s" MachineOptions = [ "amazonec2-access-key=...", "amazonec2-secret-key=...", "amazonec2-region=us-east-1", "amazonec2-instance-type=t3.medium" ] ``` Creates machines on demand when jobs queued, destroys after idle period. Kubernetes autoscaling uses Kubernetes cluster autoscaler. Deploy runner as Kubernetes deployment, cluster automatically scales nodes based on pod resource requests. Runner configuration file (config.toml) contains all runner settings: ```toml concurrent = 4 # Max concurrent jobs check_interval = 0 [[runners]] name = "production-runner" url = "https://gitlab.com/" token = "TOKEN" executor = "docker" [runners.cache] Type = "s3" Shared = true [runners.cache.s3] ServerAddress = "s3.amazonaws.com" BucketName = "runner-cache" ``` Cache configuration enables sharing cache between jobs: ```yaml variables: CACHE_KEY: "${CI_COMMIT_REF_SLUG}" cache: key: ${CACHE_KEY} paths: - node_modules/ policy: pull-push ``` Security considerations: don't use privileged mode unless necessary, isolate runners (dedicated machines/namespaces), use private Docker registry for base images, implement network policies restricting runner access, regularly update runners, rotate tokens, limit runner scope (specific > group > shared). Understanding runner architecture and configuration enables building scalable, secure CI/CD infrastructure.

10. How do you create custom GitHub Actions? Explain action types (JavaScript, Docker, Composite), inputs, outputs, and publishing to marketplace.

Difficulty: HardType: SubjectiveTopic: GitHub Actions

GitHub Actions support three action types: JavaScript actions (run directly on runner), Docker container actions (run in container), and composite actions (combine multiple steps). JavaScript actions execute directly on runner (fast, no container overhead). Create action: 1. Create action repository with action.yml: ```yaml name: 'Hello World' description: 'Greet someone and record time' inputs: who-to-greet: description: 'Who to greet' required: true default: 'World' outputs: time: description: 'The time we greeted you' runs: using: 'node16' main: 'index.js' ``` 2. Create index.js: ```javascript const core = require('@actions/core'); const github = require('@actions/github'); try { const nameToGreet = core.getInput('who-to-greet'); console.log(`Hello ${nameToGreet}!`); const time = (new Date()).toTimeString(); core.setOutput('time', time); core.setSecret('mySecret'); // Mask in logs } catch (error) { core.setFailed(error.message); } ``` 3. Package dependencies: ```bash npm install @actions/core @actions/github npm install @vercel/ncc -g ncc build index.js -o dist ``` Usage: ```yaml steps: - uses: user/hello-world-action@v1 with: who-to-greet: 'GitHub' id: hello - run: echo "Time was ${{ steps.hello.outputs.time }}" ``` Docker container actions run in container with custom environment: 1. Create action.yml: ```yaml name: 'Container Action' description: 'Runs in Docker container' inputs: myInput: description: 'Input parameter' required: true runs: using: 'docker' image: 'Dockerfile' args: - ${{ inputs.myInput }} ``` 2. Create Dockerfile: ```dockerfile FROM alpine:3.15 COPY entrypoint.sh /entrypoint.sh RUN chmod +x /entrypoint.sh ENTRYPOINT ["/entrypoint.sh"] ``` 3. Create entrypoint.sh: ```bash #!/bin/sh -l echo "Input was $1" echo "::set-output name=result::Success" ``` Composite actions combine multiple steps (shell commands or other actions): ```yaml name: 'Composite Action' description: 'Runs multiple steps' inputs: node-version: description: 'Node.js version' required: true runs: using: 'composite' steps: - uses: actions/checkout@v3 shell: bash - uses: actions/setup-node@v3 with: node-version: ${{ inputs.node-version }} shell: bash - run: npm install shell: bash - run: npm test shell: bash ``` Composite actions simplify workflow by grouping common steps. Action inputs and outputs enable parameterization: ```yaml inputs: api-key: description: 'API key' required: true environment: description: 'Deployment environment' required: false default: 'staging' outputs: deployment-url: description: 'Deployed application URL' value: ${{ steps.deploy.outputs.url }} ``` Publishing to GitHub Marketplace: 1. Create release with tag (v1, v1.0.0) 2. Add action.yml metadata: ```yaml name: 'My Action' author: 'Your Name' description: 'Detailed description' branding: icon: 'activity' color: 'blue' ``` 3. Publish to marketplace through GitHub UI 4. Users reference: uses: username/action-name@v1 Versioning best practices: use semantic versioning, maintain major version tags (v1, v2), update major tag on releases (git tag -fa v1 -m "Update v1"), users can pin to specific version (v1.0.0) or major version (v1). Testing actions: create .github/workflows/test.yml: ```yaml on: [push] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v3 - uses: ./ # Test local action with: who-to-greet: 'Test' ``` Understanding custom actions enables creating reusable automation, sharing with community, and building organization-specific action libraries.

Master Interviews
Anywhere, Anytime

GitLab CI/CD & GitHub Actions – CI/CD Pipelines interview questions

Set overview

CI/CD Pipelines – GitLab CI/CD & GitHub Actions questions (15)

1. What file defines GitLab CI/CD pipelines?

Continue your preparation

2. Where are GitHub Actions workflows stored?

3. Compare Jenkins, GitLab CI/CD, and GitHub Actions. Discuss architecture, configuration, features, scalability, pricing, and use cases for each.

4. Explain advanced CI/CD patterns including multi-stage pipelines, pipeline orchestration, trunk-based development workflows, and deployment strategies integration.

5. Explain security best practices for CI/CD pipelines. Include secrets management, artifact security, vulnerability scanning, and supply chain security.

6. What are self-hosted runners in GitHub Actions?

7. Explain GitLab CI/CD architecture and .gitlab-ci.yml syntax in detail. Include stages, jobs, artifacts, cache, dependencies, and advanced features.

8. Explain GitHub Actions workflow syntax comprehensively. Include events, jobs, steps, actions, contexts, and advanced patterns.

9. Explain GitLab Runner architecture, executor types, registration, and configuration. Include Docker, Kubernetes, and autoscaling setups.

10. How do you create custom GitHub Actions? Explain action types (JavaScript, Docker, Composite), inputs, outputs, and publishing to marketplace.

11. What are GitLab Runners?

12. What is GitHub Actions Marketplace?

13. Which trigger is valid in GitLab CI/CD?

14. In GitHub Actions, what does 'strategy: matrix:' do?

15. How do stages work in GitLab CI/CD?

More sets in CI/CD Pipelines

Explore related subjects

Master Interviews Anywhere, Anytime

GitLab CI/CD & GitHub Actions – CI/CD Pipelines interview questions

Set overview

1. What file defines GitLab CI/CD pipelines?

Continue your preparation

2. Where are GitHub Actions workflows stored?

3. Compare Jenkins, GitLab CI/CD, and GitHub Actions. Discuss architecture, configuration, features, scalability, pricing, and use cases for each.

4. Explain advanced CI/CD patterns including multi-stage pipelines, pipeline orchestration, trunk-based development workflows, and deployment strategies integration.

5. Explain security best practices for CI/CD pipelines. Include secrets management, artifact security, vulnerability scanning, and supply chain security.

6. What are self-hosted runners in GitHub Actions?

7. Explain GitLab CI/CD architecture and .gitlab-ci.yml syntax in detail. Include stages, jobs, artifacts, cache, dependencies, and advanced features.

8. Explain GitHub Actions workflow syntax comprehensively. Include events, jobs, steps, actions, contexts, and advanced patterns.

9. Explain GitLab Runner architecture, executor types, registration, and configuration. Include Docker, Kubernetes, and autoscaling setups.

10. How do you create custom GitHub Actions? Explain action types (JavaScript, Docker, Composite), inputs, outputs, and publishing to marketplace.

11. What are GitLab Runners?

12. What is GitHub Actions Marketplace?

13. Which trigger is valid in GitLab CI/CD?

14. In GitHub Actions, what does 'strategy: matrix:' do?

15. How do stages work in GitLab CI/CD?

More sets in CI/CD Pipelines

Explore related subjects

Master Interviews
Anywhere, Anytime