VBA-Build now focuses only on building and testing VBA-enabled files from source.
Starting with v2.0.0, environment initialization is no longer handled inside this action.
You must run DecimalTurn/setup-vba before VBA-Build.
In previous versions, VBA-Build handled setup tasks like:
- Installing Microsoft Office on the runner
- Initializing Office applications
- Configuring VBA security (VBOM access / macro settings)
In v2.0.0, these responsibilities were removed from VBA-Build and moved to setup-vba.
This is an intentional separation of concerns:
setup-vba= prepare runner/runtimeVBA-Build= build documents from source
jobs:
build:
runs-on: windows-latest
steps:
- uses: actions/checkout@v6
- name: Build VBA
uses: DecimalTurn/VBA-Build@v1
with:
source-dir: ./src
test-framework: rubberduckjobs:
build:
runs-on: windows-2025
steps:
- uses: actions/checkout@v6
- name: Setup VBA runtime
uses: DecimalTurn/setup-vba@75c6ce5e714186234ef9090c1c77537a60bd7339 # v0.1.1
with:
office-apps: "Excel,Word,PowerPoint,Access"
install-office: "true"
- name: Build VBA
uses: DecimalTurn/VBA-Build@v2.0.0
with:
source-dir: ./src
test-framework: rubberduck- Add a
setup-vbastep beforeVBA-Build. - Keep your existing
VBA-Buildinputs (source-dir,test-framework,office-app) as needed. - (Optional) Pin your
setup-vbaversion to a commit SHA (recommended for supply-chain hardening). - Run the workflow once and verify Office setup + build output artifacts.
- If Office is already available on your runner image, set
install-office: "false". - If you only target specific apps, narrow
office-apps(example:"Excel"). - This release is breaking by design to enforce modular setup/build responsibilities.