GitHub Actions CI/CD su Progress OpenEdge: kaip įgyvendinti?

Tikslas

Tikslas – sudaryti sąlygas Progress OpenEdge programų kūrimo ir tikrinimo procesui kontroliuojamoje, konteinerizuotoje aplinkoje GitHub sistemoje.

Naudoti tik privačiose saugyklose.

Kadangi šis metodas reikalauja įkelti OpenEdge diegimą į saugyklą, primygtinai rekomenduojama naudoti privačią saugyklą (private repo). Tai užtikrina, kad nuosavybiniai diegimo paketai nebūtų viešai prieinami. response.ini failas tvarkomas saugiai, jį laikant GitHub Secrets skiltyje.

Diagrama

Įvestys (Inputs)

• naudotojo veiksmai (push, pull, merge request ir t.t.) saugykloje
• suplanuoti, pasikartojantys įvykiai
• rankinis paleidimas (manual dispatch)

Daugiau sužinokite GitHub dokumentacijoje.

Išvestys (Outputs)

• OpenEdge aplinka GitHub Actions sistemoje.

‍

Aprašymas

Kaip parodyta diagramoje aukščiau, naudosime 3 priemones duomenims perkelti: Saugykla (Repository) → Actions Runner → Docker konteineris.

Sukuriame GitHub saugyklą su šiais failais:

‍

oec.yaml

Failas, kuriame aprašyta GitHub Actions darbo eiga (workflow). Šiam atvejui darbo eiga išlaikyta paprasta. Ji sukuria ir paleidžia Docker konteinerį su Progress OpenEdge įrankiais.

Ši darbo eiga turi du paleidiklius (triggers): po push į main šaką (branch) ir per workflow_dispatch, kurį galima paleisti iš GitHub puslapio.

‍

# Trigger settings — define when this workflow runs: 

on:   

  workflow_dispatch:        # Allows manual triggering of the workflow from GitHub UI   

  push:                     # Triggers the workflow automatically on code pushed 

    branches:               # Specify which branches this applies to for pushes   

      - main                # Only run when code is pushed to the `main` branch   

 

jobs: 

  build:                     

    runs-on: ubuntu-latest  # Specifies the virtual environment; here, a Ubuntu runner   

 

    steps:                    

      - name: Check out repository 

        uses: actions/checkout@v4              # Uses the official checkout action, version 4 to get the code from repository 

        with: 

          lfs: true                            # If the repo uses Git LFS (Large File Storage), this ensures LFS files are pulled 

 

      - name: Add response.ini                 # Next step to create or populate a file called response.ini 

        run: 

          echo "${{ secrets.RESPONSE_INI }}" | base64 --decode > response.ini 

 

      - name: Build the Docker image           # Step to build a Docker image 

        run: docker build -t oe-ci . 

 

      - name: Run a container from the image   # Step to run a container using the built image 

        run: docker run oe-ci

install.sh

Scripts aplanke turime install.sh skriptą, kuris paleidžia tylųjį (silent) diegimą ir išveda žurnalo (log) failą.

Šis skriptas yra pasirinktinis, tačiau jis apsaugo nuo to, kad docker build komanda nutrūktų neparodžiusi klaidų iš Progress OpenEdge diegimo proceso.

‍

/install/openedge/proinst -b /install/openedge/response.ini -l /install/install_oe.log -n  

cat /install/install_oe.log 

Dockerfile

Kitas svarbus failas – Dockerfile, naudojamas Progress OpenEdge diegti ir paleisti GitHub Actions runner viduje. Kadangi GitHub riboja runner modifikavimą (galimas tik per Actions Marketplace), naudojame Docker konteinerį, kurį galime laisvai keisti.

FROM ubuntu:24.04 

 

# We copy openjdk installation and set env variables 

ENV JAVA_HOME=/opt/java/openjdk 

COPY --from=eclipse-temurin:17.0.15_6-jdk $JAVA_HOME $JAVA_HOME 

ENV PATH="${JAVA_HOME}/bin:${PATH}" 

 

 

# We Add Progress OE installation and the script and then we write to a file  

# response.ini content that is kept in a secret. 

ADD PROGRESS_OE_12.8_LNX_64.tar.gz /install/openedge/ 

ADD scripts/install.sh /install/install.sh 

COPY response.ini /install/openedge/response.ini 

 

ENV TERM=linux 

 

# Provide permissions for install script. 

RUN chmod +x /install/install.sh 

RUN /install/install.sh 

 

CMD ["/bin/bash"] 

Toliau turime diegimo failus, kuriuos naudosime Progress OpenEdge aplinkai sukonfigūruoti GitHub Runner viduje.

PROGRESS_OE.tar.gz

Yra keletas būdų pridėti Progress OpenEdge įrankius į GitHub Actions aplinką.

• Vienas būdas – sukurti atvaizdą (image) ir naudoti registrą (registry), kad vėliau jį atsisiųstumėte (pull) į GitHub Actions runner (pvz., „Docker Hub“).

Kitas būdas – naudoti Git LFS (Large File Storage), kad įkeltumėte Progress OpenEdge diegimą į privačią GitHub saugyklą ir atsiimtumėte (check out) kartu su kodu. Daugiau sužinokite, kaip pridėti LFS prie GitHub.

response.ini

Šis failas bus naudojamas tyliam Progress OpenEdge diegimui Docker konteinerio viduje.

• Užkoduokite jį naudodami base64.
• Pridėkite failą į GitHub saugyklą kaip paslaptį (secret).
• Eikite į savo saugyklą → Settings → Secrets and variables → Actions → New repository secret.
• Nepamirškite jį iškoduoti naudojant base64 --decode, kai naudojate GitHub Actions viduje.

Taigi, sukonfigūravus viską saugykloje, ko galime tikėtis?

Iššūkiai

• GitHub Actions sistemoje nėra natūvių Progress OpenEdge įrankių, todėl viską kuriame nuo nulio.
• Aplinkos pritaikymas, kad ji palaikytų Progress OpenEdge.
• Licencijos apsauga naudojant Progress OpenEdge įrankius GitHub talpinamuose runner'iuose.

Rezultatai

Infrastruktūra, ant kurios galima toliau plėtoti:

• PCT naudojimas projektams kurti.
• ABLUnit naudojimas testams paleisti.

Kūrimo įrankiai GitHub Action Runner viduje:

• Pro, mpro, bpro.

Kokios išmoktos pamokos?

Pradiniame metode rankiniu būdu įkėlėme Progress OpenEdge diegimo paketą (PROGRESS_OE.tar.gz) ir atsako failą (response.ini) į saugyklą, tuomet naudojome pasirinktinį Dockerfile ir apvalkalo (shell) skriptą, kad atliktume tylųjį diegimą GitHub Actions runner viduje. Nors tai veikia, yra keletas reikšmingų trūkumų:

• Sunkios atvaizdo kūrimo operacijos. Kiekvienas CI paleidimas atkuria visą diegimą iš naujo, o tai žymiai pailgina kūrimo (build) laiką (šiame pavyzdyje vien OE diegimui kūrimo laikas buvo ~1 minutė).
• ‍Dideli failai saugykloje. Diegimo failų įterpimas tiesiogiai į saugyklą (net naudojant Git LFS) žymiai sulėtina git veikimą.

Geresnis būdas – sukurti iš anksto paruoštą (prebuilt) atvaizdą, saugomą privačiame registre (GHCR, Docker Hub ar kitur), su jau įdiegtu Progress OpenEdge. Tokiu būdu atvaizdą galima atsisiųsti ir naudoti kūrimui bei testų paleidimui, nekartojant diegimo kiekvieną kartą paleidžiant CI.

Kodėl tai svarbu?

Šis blogo įrašas parodo, kaip sukonfigūruoti veikiančią Progress OpenEdge aplinką GitHub Actions sistemoje, naudojant Docker ir tylųjį diegimą. Nors jis dar neapima pilnų CI/CD procesų, jis suteikia pagrindą, reikalingą kūrimui, testavimui ir automatizavimui OpenEdge projektuose, naudojant modernią GitHub darbo eigą.

Dažniausiai užduodami klausimai

Kodėl GitHub Actions nepalaiko Progress OpenEdge natūviai?

GitHub Actions neturi integruotų Progress OpenEdge įrankių, todėl visa aplinka turi būti sukurta nuo nulio, naudojant Docker konteinerį, kurį galima laisvai konfigūruoti – kitaip nei standartinį GitHub runner, kurio modifikuoti negalima.

Kodėl rekomenduojama naudoti privačią saugyklą šiam metodui?

Kadangi metodas reikalauja įkelti Progress OpenEdge diegimo paketą į saugyklą, privati saugykla užtikrina, kad nuosavybiniai diegimo failai nebūtų viešai prieinami. response.ini failas papildomai saugomas GitHub Secrets skiltyje.

Kokie pagrindiniai trūkumai naudojant rankinį diegimo metodą kiekviename CI paleidime?

Pagrindiniai trūkumai – ilgas kūrimo (build) laikas, nes kiekvienas CI paleidimas iš naujo atkuria visą diegimą, ir dideli diegimo failai saugykloje, kurie sulėtina git veikimą net naudojant Git LFS.

Koks geresnis būdas nei diegti Progress OpenEdge kiekvieną kartą iš naujo?

Rekomenduojama sukurti iš anksto paruoštą Docker atvaizdą su jau įdiegtu Progress OpenEdge ir saugoti jį privačiame registre (pvz., GHCR ar Docker Hub). Tokį atvaizdą tuomet galima tiesiog atsisiųsti ir naudoti, nekartojant diegimo proceso kiekviename CI paleidime.