GitHub Actions CI/CD with Progress OpenEdge

 
CI/CD is a core practice in software development. However, GitHub Actions lacks native support for Progress OpenEdge. Using Docker, a silent OE installation, and GitHub Actions workflows, we can build and validate OpenEdge applications in a repeatable, containerised environment alongside other modern stacks.  

It enables teams to automate builds, run tests, and integrate OpenEdge applications into modern CI/CD pipelines without manual setup. This blog post explains how to implement GitHub actions CI/CD with Progress OpenEdge. 

Objective 

The goal is to enable the build and validation process for Progress OpenEdge applications within a controlled containerised environment in GitHub. 

Only use in private repositories.  

Because this method requires uploading the OpenEdge installation into the repository, using a private repo is strongly recommended. This ensures that proprietary installation packages are not exposed publicly. The response.ini file is handled securely by storing it in GitHub Secrets. 

Diagram 

Inputs 

• User actions (push, pull, merge request,..) on repository. 

• Timed, recurring events. 

• Manual dispatch. 

• Learn more at GitHub Docs 

Outputs 

• OpenEdge environment in GitHub Actions. 

Description 

As in the diagram above, we will use 3 mediums to transfer data from Repository → Actions Runner → Docker container. 

We create a GitHub repository with these files: 

oec.yaml 

File that contains the GitHub Actions workflow. For this use case, the workflow is kept simple. It builds and starts the Docker container with Progress OpenEdge tools. 

 
This workflow has two triggers: on push to the main branch, and on manual_dispatch which can be triggered from the GitHub page. 

# 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 

In the scripts directory, we have an install.sh script that runs a silent installation and outputs the log file. 

 
This script is optional but prevents the docker build command from terminating without showing errors from the Progress OpenEdge installation process. 

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

Dockerfile 

Another crucial file is the Dockerfile, used to install and run Progress OpenEdge inside the GitHub Actions runner. Since GitHub restricts runner modification (available only via the Actions Marketplace), we rely on a Docker container that we can freely modify. 

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"] 

Then we have installation files that we will use to setup Progress OpenEdge environment inside GitHub Runner. 

PROGRESS_OE.tar.gz 

We can use couple of ways to add Progress OpenEdge tools into our GitHub actions environment. 

• One way is to build the image and use a registry to later pull it into GitHub Actions runner (“Docker Hub”). 

• Another way is to use Git LFS (Large File Storage) to upload the Progress OpenEdge installation into a private GitHub repository and check it out alongside the code. Read more on how to add LFS to GitHub 

response.ini 

This file will be used to silently install Progress OpenEdge inside the Docker container. 

• Encode it with base64. 

• Add the file inside the GitHub repository as a secret. 

• Go to your repository → Settings → Secrets and variables → Actions → New repository secret. 

• Remember to decode it with base64 –decode when using it inside GitHub Actions. 

So after setting up everything inside the repository, what can we expect? 

Challenges 

• No native Progress OpenEdge tools are inside the GitHub Actions, so we build everything from the ground up. 

• Tailoring the environment to run Progress OpenEdge.

• Securing your license while using Progress OpenEdge tools inside GitHub-hosted runners. 

Results 

• Infrastructure to continue building on: 

• Using PCT to build projects. 

• Using ABLUnit to run tests. 

• Development tools inside GitHub Action Runner: 

• Pro, mpro, bpro . 

Lessons Learned 

In the initial approach, we manually uploaded the Progress OpenEdge installer (PROGRESS_OE.tar.gz) and response file (response.ini) into the repository, then used a custom Dockerfile and shell script to perform a silent installation inside the GitHub Actions runner. While this works, it has a few major drawbacks: 

• Heavy image builds. Each CI run rebuilds the full installation, which increases build times significantly (In this example the built time was ~1 minute only for the OE install). 

• Large files inside repo. Embedding installer files directly into the repo (even via Git LFS) slows down git significantly. 

A better approach is to create a prebuilt image stored in a private registry (GHCR, Docker Hub, or others), with Progress OpenEdge already installed. This way, the image can be pulled and used to build and run tests without repeating the installation in every CI run. 

Why It Matters 

This blog post walks through setting up a working Progress OpenEdge environment inside GitHub Actions using Docker and silent installation. While it does not yet cover full CI/CD pipelines, it gives you the foundation needed to run builds, tests, and automation for OpenEdge projects in a modern GitHub workflow.