GitHub Actions Marketplace Aksiyonlarını Kullanma Rehberi

Tarafındankomut
0 Comments

GitHub Actions ile CI/CD pipeline kuruyorsunuz ve her şeyi sıfırdan yazmak zorunda mıyım diye düşünüyorsunuz? İşte tam burada Marketplace devreye giriyor. GitHub Actions Marketplace, binlerce hazır action barındıran dev bir ekosistem ve bu ekosistemi doğru kullanmak pipeline geliştirme sürecinizi dramatik biçimde hızlandırıyor. Bu yazıda Marketplace action’larını nasıl bulacağınızı, güvenli şekilde nasıl kullanacağınızı ve gerçek deployment senaryolarında nasıl entegre edeceğinizi adım adım ele alacağız.

GitHub Actions Marketplace Nedir?

Marketplace, GitHub tarafından barındırılan ve topluluk ya da resmi organizasyonlar tarafından geliştirilmiş action’ların bir kataloğudur. Temel olarak üç tip action bulursunuz:

  • Docker container action: İzole bir ortamda çalışır, daha yavaş başlar ama tutarlıdır
  • JavaScript action: Node.js üzerinde çalışır, hızlıdır ve tüm runner’larda çalışır
  • Composite action: Birden fazla adımı tek bir action’da birleştirir

Bir action kullanmak için yapmanız gereken tek şey uses: direktifini workflow dosyanıza eklemek. Ancak “tek şey” dediğimde bunu hafife almayın, çünkü hangi versiyonu kullandığınız, action’ın güvenilirliği ve gizli bilgilerin nasıl yönetildiği kritik öneme sahip.

Action Versiyonlama ve Güvenlik

Marketplace’ten action kullanırken versiyonu her zaman sabitleyin. Bunu üç farklı şekilde yapabilirsiniz:

# Tag ile (önerilen - semantik versiyonlama)
uses: actions/checkout@v4

# Commit SHA ile (en güvenli yöntem)
uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683

# Branch ile (tehlikeli - production'da kullanmayın)
uses: actions/checkout@main

Commit SHA kullanımı en güvenli yöntemdir çünkü tag’lar değiştirilebilir. Bir saldırgan popüler bir action’ın maintainer’ını ele geçirirse tag’ı kötü amaçlı koda yönlendirebilir. SHA sabitlediğinizde bu riske karşı korunursunuz.

Hangi action’lara güveneceğinizi belirlerken şu kriterlere bakın:

  • actions/ veya github/ organizasyonuna ait action’lar GitHub’ın resmi action’larıdır
  • Yıldız sayısı ve fork sayısı yüksek, aktif maintenance olan projeler tercih edin
  • Action’ın kaynak kodunu mutlaka inceleyin, özellikle secrets kullanıyorsa
  • “Verified creator” rozetine sahip action’ları önceliklendirin

Temel Marketplace Action’ları

actions/checkout

Her workflow’un neredeyse başına koyacağınız ilk action bu:

name: Build Pipeline

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

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Kodu checkout et
        uses: actions/checkout@v4
        with:
          fetch-depth: 0        # Tüm git geçmişini al
          submodules: recursive  # Submodule'leri de çek
          token: ${{ secrets.GITHUB_TOKEN }}

fetch-depth: 0 parametresi özellikle önemli. Varsayılan değer 1 olduğunda sadece son commit gelir, bu da bazı araçların (SonarQube gibi) düzgün çalışmamasına yol açar.

actions/setup-node ve Dil Setup Action’ları

Uygulama dağıtımlarında runtime ortamını ayarlamak için setup action’ları kullanırsınız:

jobs:
  deploy-nodejs-app:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Node.js ortamını hazırla
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'          # npm cache'ini etkinleştir
          cache-dependency-path: package-lock.json

      - name: Bağımlılıkları yükle
        run: npm ci

      - name: Build al
        run: npm run build

      - name: Testleri çalıştır
        run: npm test

cache: 'npm' parametresi çok değerli, özellikle büyük projelerde build sürelerini ciddi ölçüde kısaltır. Benzer şekilde Python için actions/setup-python, Java için actions/setup-java bulunur.

Gerçek Dünya Senaryosu 1: Node.js Uygulamasını AWS EC2’ye Deploy Etmek

Diyelim ki bir Node.js REST API’niz var ve bunu AWS EC2’ye SSH üzerinden deploy etmek istiyorsunuz. Bu senaryoda birkaç Marketplace action’ı bir arada kullanacağız:

name: Production Deploy

on:
  push:
    branches: [main]

env:
  APP_DIR: /var/www/myapi
  PM2_APP_NAME: myapi

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'
      - run: npm ci
      - run: npm test

  deploy:
    needs: test
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4

      - name: Node.js kur
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Production build
        run: |
          npm ci --production
          npm run build

      - name: Artifact oluştur
        run: |
          tar -czf deploy.tar.gz 
            dist/ 
            node_modules/ 
            package.json 
            ecosystem.config.js

      - name: Sunucuya dosyaları kopyala
        uses: appleboy/[email protected]
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ${{ secrets.EC2_USER }}
          key: ${{ secrets.EC2_SSH_KEY }}
          source: deploy.tar.gz
          target: /tmp/

      - name: Deploy scripti çalıştır
        uses: appleboy/[email protected]
        with:
          host: ${{ secrets.EC2_HOST }}
          username: ${{ secrets.EC2_USER }}
          key: ${{ secrets.EC2_SSH_KEY }}
          script: |
            set -e
            cd ${{ env.APP_DIR }}
            cp -r . ./backup_$(date +%Y%m%d_%H%M%S)
            tar -xzf /tmp/deploy.tar.gz -C ${{ env.APP_DIR }}
            pm2 reload ${{ env.PM2_APP_NAME }} --update-env
            pm2 save
            echo "Deploy tamamlandi!"

Bu workflow’da appleboy/scp-action ve appleboy/ssh-action kullandık. Bu action’lar topluluk tarafından çok yaygın kullanılıyor ve güvenilir kabul ediliyor ancak her zaman SHA sabitlemeyi düşünün.

actions/cache ile Build Sürelerini Optimize Etmek

jobs:
  build-java-app:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Java 17 kur
        uses: actions/setup-java@v4
        with:
          java-version: '17'
          distribution: 'temurin'
          cache: 'maven'

      - name: Maven bağımlılıklarını cache'le
        uses: actions/cache@v4
        with:
          path: ~/.m2/repository
          key: ${{ runner.os }}-maven-${{ hashFiles('**/pom.xml') }}
          restore-keys: |
            ${{ runner.os }}-maven-

      - name: Build ve test
        run: mvn clean package -DskipTests=false

      - name: JAR artifact'ı sakla
        uses: actions/upload-artifact@v4
        with:
          name: app-jar
          path: target/*.jar
          retention-days: 7

hashFiles('**/pom.xml') ile pom.xml değiştiğinde cache otomatik geçersiz olur. Bu pattern Docker layer caching mantığına benzer ve çok etkili.

Gerçek Dünya Senaryosu 2: Docker Image Build ve Registry’e Push

Containerized uygulamalar için en yaygın kullanılan pattern budur:

name: Docker Build ve Deploy

on:
  push:
    branches: [main]
    tags: ['v*']

jobs:
  docker-build-push:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write

    steps:
      - uses: actions/checkout@v4

      - name: Docker meta bilgileri oluştur
        id: meta
        uses: docker/metadata-action@v5
        with:
          images: |
            ghcr.io/${{ github.repository }}
            mycompany/myapp
          tags: |
            type=semver,pattern={{version}}
            type=semver,pattern={{major}}.{{minor}}
            type=ref,event=branch
            type=sha,prefix=sha-

      - name: QEMU kur (multi-platform için)
        uses: docker/setup-qemu-action@v3

      - name: Docker Buildx kur
        uses: docker/setup-buildx-action@v3

      - name: GitHub Container Registry'e giriş yap
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Docker Hub'a giriş yap
        uses: docker/login-action@v3
        with:
          username: ${{ secrets.DOCKERHUB_USERNAME }}
          password: ${{ secrets.DOCKERHUB_TOKEN }}

      - name: Build ve push
        uses: docker/build-push-action@v5
        with:
          context: .
          platforms: linux/amd64,linux/arm64
          push: ${{ github.event_name != 'pull_request' }}
          tags: ${{ steps.meta.outputs.tags }}
          labels: ${{ steps.meta.outputs.labels }}
          cache-from: type=gha
          cache-to: type=gha,mode=max

Burada dikkat çekici birkaç nokta var. docker/metadata-action otomatik olarak tag stratejisi yönetiyor. type=sha ile her commit’in SHA’sı tag olarak ekleniyor, bu da rollback yaparken büyük kolaylık sağlıyor. cache-from: type=gha ise GitHub Actions cache’ini Docker layer cache için kullanıyor.

Bildirim ve Entegrasyon Action’ları

Pipeline sonuçlarını takım üyelerine bildirmek için Slack veya diğer mesajlaşma araçları entegrasyonları çok işe yarıyor:

      - name: Slack bildirimi gönder
        if: always()
        uses: slackapi/[email protected]
        with:
          payload: |
            {
              "text": "Deploy Durumu: ${{ job.status }}",
              "blocks": [
                {
                  "type": "section",
                  "text": {
                    "type": "mrkdwn",
                    "text": "*${{ github.repository }}* - Deploy ${{ job.status == 'success' && 'basarili' || 'basarisiz' }}n*Branch:* ${{ github.ref_name }}n*Commit:* ${{ github.sha }}n*Tetikleyen:* ${{ github.actor }}"
                  }
                }
              ]
            }
        env:
          SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
          SLACK_WEBHOOK_TYPE: INCOMING_WEBHOOK

if: always() koşulu job başarısız olsa bile bildirimin gönderilmesini sağlar. Production ortamlarında bu özellikle önemli.

Güvenlik Tarama Action’ları

Modern bir CI/CD pipeline güvenlik taramaları içermeli. Bunu ihmal etmek ciddi açıklara yol açabilir:

  security-scan:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
      contents: read

    steps:
      - uses: actions/checkout@v4

      - name: Trivy ile container tarama
        uses: aquasecurity/[email protected]
        with:
          image-ref: ghcr.io/${{ github.repository }}:latest
          format: sarif
          output: trivy-results.sarif
          severity: CRITICAL,HIGH
          exit-code: '1'

      - name: Sonuçları GitHub Security'e yükle
        uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: trivy-results.sarif

      - name: Dependency review
        uses: actions/dependency-review-action@v4
        with:
          fail-on-severity: high

exit-code: '1' parametresi kritik güvenlik açığı bulunduğunda pipeline’ı durduruyor. Bu sayede güvenlik açıklı bir image asla production’a çıkmıyor.

Environment ve Secrets Yönetimi

Marketplace action’ları kullanırken secrets yönetimi kritik öneme sahip. Birkaç önemli nokta:

  • GITHUB_TOKEN otomatik olarak oluşturulur ve çoğu işlem için yeterlidir
  • Hassas bilgileri repository secrets veya environment secrets olarak saklayın
  • Action’lara minimum gerekli permission verin
jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    permissions:
      contents: read      # Sadece okuma
      packages: write     # Package registry için
      id-token: write     # OIDC token için (AWS, Azure)

    steps:
      - name: AWS kimlik doğrulama (OIDC ile - en güvenli yöntem)
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789:role/GitHubActionsRole
          aws-region: eu-west-1

      - name: ECR'e giriş yap
        uses: aws-actions/amazon-ecr-login@v2

      - name: ECS service'i güncelle
        uses: aws-actions/amazon-ecs-deploy-task-definition@v1
        with:
          task-definition: task-definition.json
          service: my-service
          cluster: my-cluster
          wait-for-service-stability: true

OIDC tabanlı authentication statik access key kullanmaktan çok daha güvenlidir. aws-actions/configure-aws-credentials action’ı bu süreci kolaylaştırıyor. Access key’i secrets’a kaydetmek yerine IAM role assume ediyorsunuz, bu hem daha güvenli hem de key rotasyonu derdi ortadan kalkıyor.

Reusable Workflows ile Action Kompozisyonu

Birden fazla projede aynı deployment pattern kullanıyorsanız reusable workflow’lar hayat kurtarır:

# .github/workflows/reusable-deploy.yml
name: Reusable Deploy Workflow

on:
  workflow_call:
    inputs:
      environment:
        required: true
        type: string
      image-tag:
        required: true
        type: string
    secrets:
      EC2_SSH_KEY:
        required: true
      EC2_HOST:
        required: true

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: ${{ inputs.environment }}
    steps:
      - uses: actions/checkout@v4

      - name: Deploy to server
        uses: appleboy/[email protected]
        with:
          host: ${{ secrets.EC2_HOST }}
          username: deploy
          key: ${{ secrets.EC2_SSH_KEY }}
          script: |
            docker pull myapp:${{ inputs.image-tag }}
            docker stop myapp || true
            docker run -d --name myapp 
              --restart unless-stopped 
              -p 3000:3000 
              myapp:${{ inputs.image-tag }}

Bu reusable workflow’u ana workflow’dan şöyle çağırırsınız:

# .github/workflows/main.yml
jobs:
  deploy-staging:
    uses: ./.github/workflows/reusable-deploy.yml
    with:
      environment: staging
      image-tag: ${{ needs.build.outputs.image-tag }}
    secrets:
      EC2_SSH_KEY: ${{ secrets.STAGING_SSH_KEY }}
      EC2_HOST: ${{ secrets.STAGING_HOST }}

Action Yazarken Dikkat Edilmesi Gerekenler

Mevcut action’lar ihtiyacınızı karşılamıyorsa kendiniz yazabilirsiniz. Composite action için basit bir örnek:

# .github/actions/notify-deploy/action.yml
name: 'Deploy Bildirim'
description: 'Deploy durumunu bildirir'
inputs:
  status:
    description: 'Deploy durumu'
    required: true
  environment:
    description: 'Hedef ortam'
    required: true
  slack-webhook:
    description: 'Slack webhook URL'
    required: true

runs:
  using: composite
  steps:
    - name: Slack mesajı gönder
      shell: bash
      run: |
        STATUS_EMOJI=$([[ "${{ inputs.status }}" == "success" ]] && echo "✅" || echo "❌")
        curl -X POST "${{ inputs.slack-webhook }}" 
          -H 'Content-type: application/json' 
          -d "{"text": "${STATUS_EMOJI} ${{ inputs.environment }} deploy: ${{ inputs.status }}"}"

Yaygın Hatalar ve Çözümleri

Marketplace action kullanırken sık karşılaşılan sorunlar şunlar:

  • Versiyon pin’lememek: @main veya @latest kullanmak beklenmedik breaking change’lere yol açar
  • Fazla permission vermek: permissions: write-all koymak yerine sadece gerekli izinleri verin
  • Secrets’ı log’a basmak: echo $SECRET yazmayın, GitHub maskeliyor ama iyi alışkanlık değil
  • Artifact retention süresini atlamak: retention-days belirtmezseniz varsayılan 90 gün ve storage doluyor
  • Cache key çakışması: Farklı branch’ler aynı cache key kullanınca beklenmedik davranışlar oluşabilir

Marketplace Action Güncellemelerini Takip Etmek

Dependabot’u aktifleştirerek action güncelleme PR’larını otomatik alabilirsiniz:

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "github-actions"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      actions:
        patterns:
          - "actions/*"
          - "docker/*"

Bu yapılandırma her hafta action güncellemelerini kontrol edip PR açıyor. Özellikle güvenlik yamalarının hızla uygulanması açısından değerli.

Sonuç

GitHub Actions Marketplace, CI/CD pipeline’larınızı sıfırdan inşa etmek yerine hazır, test edilmiş blokları bir araya getirerek hızlıca kurmanızı sağlıyor. Ancak bu kolaylık beraberinde sorumluluk getiriyor. Her action’ı körü körüne kullanmak yerine kaynak kodunu inceleyin, commit SHA ile sabitleyin ve minimum gerekli izinleri verin.

Pratikte şu yaklaşımı benimseyin: Resmi action’lar için tag sabitleme yeterlidir, üçüncü taraf action’lar için SHA sabitlemeyi tercih edin. OIDC tabanlı cloud authentication’a geçin, statik key’lerden uzak durun. Reusable workflow’larla tekrar eden pattern’leri merkezileştirin.

Marketplace bu kadar zengin bir ekosisteme sahipken tekerleği yeniden icat etmek sadece zaman kaybı. Enerjiinizi uygulama geliştirmeye harcayın, pipeline altyapısını ise topluluk tarafından test edilmiş action’lar üzerine kurun. Güvenli ve hızlı pipeline’lar dilerim.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir