My_CICD_Side_4_Workflow - itnett/FTD02H-N GitHub Wiki

Når du setter opp workflows i GitHub Actions, har du flere alternativer basert på din tech stack og hva du ønsker å automatisere. Her er en oversikt over de foreslåtte workflows du nevnte, og hvordan du kan bruke dem:

1. Python Package using Anaconda

Formål: Denne workflowen er nyttig hvis du ønsker å bygge og teste et Python-pakkeprosjekt som bruker Anaconda for pakkehåndtering. Dette er spesielt nyttig hvis prosjektet ditt har komplekse avhengigheter som håndteres av Anaconda.

Eksempel på Workflow:

name: Python Package using Anaconda

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: [3.8, 3.9, 3.10]

    steps:
    - name: Checkout code
      uses: actions/checkout@v2

    - name: Set up Anaconda
      uses: conda-incubator/setup-miniconda@v2
      with:
        python-version: ${{ matrix.python-version }}
        activate-environment: myenv
        environment-file: environment.yml

    - name: Install dependencies
      run: conda install --file requirements.txt

    - name: Run tests
      run: pytest

2. Python Application

Formål: Denne workflowen er designet for å opprette og teste en Python-applikasjon. Den kjører en serie av trinn som typisk inkluderer installasjon av avhengigheter, kjøring av tester, og eventuell bygging av applikasjonen.

Eksempel på Workflow:

name: Python Application

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v2

    - name: Set up Python
      uses: actions/setup-python@v2
      with:
        python-version: '3.x'

    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install -r requirements.txt

    - name: Run tests
      run: pytest

3. Python Package

Formål: Denne workflowen er designet for å bygge og teste en Python-pakke på flere Python-versjoner. Dette er nyttig hvis du utvikler en Python-bibliotek eller pakke som skal fungere på forskjellige Python-versjoner.

Eksempel på Workflow:

name: Python Package

on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: [3.7, 3.8, 3.9, 3.10]

    steps:
    - name: Checkout code
      uses: actions/checkout@v2

    - name: Set up Python
      uses: actions/setup-python@v2
      with:
        python-version: ${{ matrix.python-version }}

    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install -r requirements.txt

    - name: Run tests
      run: pytest

Hvordan Bruke Disse Workflows:

  • Velg den som passer best: Velg workflow basert på hva du skal automatisere. For eksempel, hvis du jobber med et Python-prosjekt som bruker Anaconda, er Python Package using Anaconda et godt valg.
  • Sett opp Environment-fil: For Python Package using Anaconda, sørg for at du har en environment.yml-fil i prosjektet ditt som definerer Anaconda-miljøet ditt.
  • Tilpass workflowen: Rediger YAML-filene for å matche ditt prosjekts spesifikasjoner. Dette inkluderer Python-versjoner, pakkeavhengigheter, og eventuelle tilleggssteg du trenger.
  • Monitor CI/CD: Når du har satt opp workflowen, vil den automatisk kjøre hver gang du gjør en commit eller åpner en pull request. Du kan overvåke resultatene i GitHub Actions-seksjonen i repoet ditt.

Disse workflowene vil kjøre på GitHub's egne servere, som betyr at Python-koden din vil bli testet og bygget i et konsistent miljø uten at du trenger å sette opp noe lokalt. Dette gir en pålitelig og skalerbar måte å håndtere testing og bygging av applikasjonen eller pakken din.

Flott, det betyr at alle filene dine nå er lastet opp til ditt private GitHub-repo, https://github.com/itnett/MyFirst_CICD. Dette repoet inneholder nå hele prosjektstrukturen, inkludert .github/workflows-mappen og alle kode-, data- og konfigurasjonsfiler.

Videre steg

Nå som du har hele prosjektet ditt i et privat repo, kan du bruke dette repoet som hovedkontrollpunktet for din CI/CD pipeline. Her er noen forslag til hva du kan gjøre videre:

  1. Overvåke og vedlikeholde pipelines:

    • Du kan nå administrere og overvåke CI/CD pipelines direkte fra GitHub Actions. Gå til https://github.com/itnett/MyFirst_CICD/actions for å se loggene, kjøre jobber på nytt og håndtere eventuelle feil.
  2. Automatisering av kode og wiki-migrering:

    • Når du gjør endringer i https://github.com/itnett/FTD02H-N.wiki.git, kan du sette opp workflows som automatisk kjører migreringsskriptet ditt for å oppdatere både https://github.com/itnett/FTD02N.git og https://github.com/itnett/FTD02N.wiki.git.
  3. Legge til nye funksjoner og integrasjoner:

    • Nå som du har en fungerende CI/CD-pipeline, kan du begynne å legge til nye funksjoner som automatiske tester, sikkerhetsskanninger, bygging av Docker-bilder, eller andre tilpasninger som du ønsker å automatisere.
  4. Beskytte sensitive data:

    • Sørg for at sensitive data som API-nøkler, passord eller andre hemmeligheter ikke er med i dine commits. Bruk GitHub Secrets for å håndtere sensitive data i workflows.
    • Du kan konfigurere GitHub Secrets under repo-innstillingene for å lagre variabler som GITHUB_TOKEN eller API-nøkler. Disse kan du deretter referere til i dine workflows uten å eksponere dem.

Videre bruk av https://github.com/itnett/MyFirst_CICD

  • Forenkle lokal utvikling: Siden hele prosjektet er i Git, kan du enkelt hente prosjektet på en annen maskin eller dele det med kolleger ved å klone repoet.
  • Opprettholde versjonskontroll: GitHub-repoet fungerer nå som en versjonskontroll for hele prosjektet ditt, slik at du kan holde orden på historikk, commits, og rollback om nødvendig.
  • Automatisert drift: Med CI/CD integrert, er du sikret at alt fungerer sømløst fra utvikling til produksjon, og at alle kodeendringer blir testet og implementert automatisk.

Hvis du har flere spørsmål eller ønsker å utvide funksjonaliteten til ditt CI/CD-oppsett, er det bare å spørre!

Det ser ut til at du ønsker å sikre at hele filstrukturen og alle filer i ditt repo også er synlige på forsiden av ditt GitHub-repository, https://github.com/itnett/MyFirst_CICD.

Slik fungerer det:

  1. Hovedfilstrukturen på GitHub:

    • Når du går til https://github.com/itnett/MyFirst_CICD, bør du kunne se alle filene og mappene i root-directoryen (det øverste nivået i prosjektet ditt). Dette inkluderer .github/, git/, og alle andre filer som ligger direkte i root.
  2. Hvis du ikke ser filene:

    • Hvis du ikke ser hele strukturen, kan det være på grunn av noen av følgende grunner:
      • Feil gren (branch): Sjekk om du er på den riktige grenen (branch) på GitHub. Sørg for at du er på master eller hovedgrenen hvor alle filene dine er lastet opp.
      • Manglende filer: Bekreft at alle nødvendige filer faktisk er pushet til repoet.
      • Skjulte filer: GitHub skjuler automatisk noen spesifikke filer eller mapper som kan ha spesielle filtyper eller tegn i navnene (som .).

Slik sørger du for at alt vises korrekt:

  1. Verifiser at alt er pushet:

    • Sørg for at alle filene dine er pushet til GitHub-repoet.
    • Gå til https://github.com/itnett/MyFirst_CICD, og verifiser at alle filer og mapper er synlige der. Du skal kunne navigere gjennom mappene og se innholdet i disse.
  2. Sjekk for skjulte eller uventede problemer:

    • I noen tilfeller kan filer eller mapper være skjult på grunn av konfigurasjon eller spesifikke filtyper.
    • Sørg for at ingenting er lagt til .gitignore som du vil ha synlig.
  3. Se etter README.md:

    • Det kan være nyttig å legge til en README.md-fil i root-directoryen som en velkomstside for repoet ditt. Dette vil automatisk vises på forsiden når noen besøker repoet ditt.

Konklusjon:

Hvis du allerede har pushet alt til https://github.com/itnett/MyFirst_CICD, og du ser alle filer når du navigerer via linken, så er alt i orden. Du kan også legge til eller oppdatere en README.md for å gi en kort forklaring eller oversikt over prosjektet ditt på forsiden av repoet. Hvis det er noe som mangler eller ikke vises, kan du sjekke steg for steg som nevnt ovenfor.