setup-msys2 is a JavaScript GitHub Action (GHA) to setup an MSYS2 environment (i.e. MSYS, MINGW32 and/or MINGW64 shells) using the GHA toolkit for automatic caching.
MSYS2 is available by default in windows-latest virtual environment for GitHub Actions, located at C:\msys64. Moreover, there is work in progress for making bash default to MSYS2 (see actions/virtual-environments#1525). However, the default installation has some caveats at the moment (see actions/virtual-environments#1572):
- It is updated every ~10 days.
- It includes a non-negligible set of pre-installed packages. As a result, update time can be up to 10 min.
- Caching of installation packages is not supported.
- MSYS2/MINGW are neither added to the PATH nor available as a custom
shelloption.
setup-msys2 works around those constraints:
- Using option
release: false, the default installation is used, but automatic caching is supported and a custom entrypoint is provided. - By default (
release: true), setup-msys2 downloads and extracts the latest tarball available at repo.msys2.org/distrib/x86_64, a clean and up-to-date environment is set up in a temporary location, and a custom entrypoint (msys2) is provided. Hence, the overhead of updating pre-installed but unnecessary packages is avoided.
Therefore, usage of this Action is recommended to all MSYS2 users of GitHub Actions, since caching and the custom entrypoint are provided regardless of option release.
- uses: msys2/setup-msys2@v2Then, for scripts:
- shell: msys2 {0}
run: |
uname -aIt is also possible to execute specific commands from cmd/powershell scripts/snippets. In order to do so, -c is required:
- shell: powershell
run: msys2 -c 'uname -a' - shell: cmd
run: msys2 -c 'uname -a'In order to reduce verbosity, it is possible to set msys2 as the default shell. For example:
defaults:
run:
shell: msys2 {0}
steps:
- uses: msys2/setup-msys2@v2
with:
update: true
install: base-devel git
#- run: git config --global core.autocrlf input
# shell: bash
- uses: actions/checkout@v2
- run: git describe --dirtyNote that setting autocrlf is required in specific use cases only. See actions/checkout#250.
It is common to test some package/tool on MINGW32 (32 bit) and MINGW64 (64 bit), which typically requires installing different sets of packages through option install. GitHub Actions' strategy and matrix fields allow to do so, as explained in docs.github.com: Configuring a build matrix and docs.github.com: jobs.<job_id>.strategy.matrix. See, for example:
Find further details at #40.
By default, MSYSTEM is set to MINGW64. However, an optional parameter named msystem is supported, which expects MSYS, MINGW64 or MINGW32. For example:
- uses: msys2/setup-msys2@v2
with:
msystem: MSYSFurthermore, the environment variable can be overridden. This is useful when multiple commands need to be executed in different contexts. For example, in order to build a PKGBUILD file and then test the installed artifact:
- uses: msys2/setup-msys2@v2
with:
msystem: MSYS
- shell: msys2 {0}
run: |
makepkg-mingw -sCLfc --noconfirm --noprogressbar
pacman --noconfirm -U mingw-w64-*-any.pkg.tar.xz
- run: |
set MSYSTEM=MINGW64
msys2 -c '<command to test the package>'Defines which parts of the Windows $env:PATH environment variable leak into the MSYS2 environment. Allowed values:
strict: do not inherit anything from$env:PATH.minimal(default): only inherit the default Windows paths from$env:PATH(so thatcmd.exeandpowershell.exeare available for example).inherit: inherit everything; warning: this can lead to interference with other tools installed on the system.
- uses: msys2/setup-msys2@v2
with:
path-type: minimalThis option corresponds to the MSYS2_PATH_TYPE setting in MSYS2; hence it can be set per step through env. See msys2/MSYS2-packages: filesystem/profile for further details about the configuration of each option.
By default (true), retrieve and extract base installation from upstream GitHub Releases. If set to false, the installation available in the virtual environment is used:
- uses: msys2/setup-msys2@v2
with:
release: falseBy default, the installation is not updated; hence package versions are those of the installation tarball. By setting option update to true, the action will try to update the runtime and packages cleanly:
- uses: msys2/setup-msys2@v2
with:
update: trueInstalling additional packages after updating the system is supported through option install. The package or list of packages are installed through pacman --noconfirm -S --needed.
- uses: msys2/setup-msys2@v2
with:
update: true
install: 'git base-devel'The steps to publish a new release are the following:
# Remove/clean dir 'dist'
rm -rf dist
# Package the action with ncc
yarn pkg
# - Copy release artifacts to subdir dir
# - Create a new orphan branch in a new empty repo
# - Push the branch
./release.sh v2.x.x
# Fetch the new branch and checkout it
git fetch --all
git checkout -b tmp origin/v2.x.x
# Reset the 'rolling' tag to the just released branch
git tag -d v2
git tag v2
git push origin +v2
# Remove the temporal branch
git checkout master
git branch -D tmpNOTE: although it feels unidiomatic having 'rolling' tags and/or storing release assets in specific branches, it is the recommended solution. Retrieving assets from GitHub Releases is not supported by GitHub Actions (yet). See actions/javascript-action: Create a release branch, actions/toolkit: docs/action-versioning.md and actions/toolkit#214.
NOTE: tag
tag-for-git-describeis used for testinggit describe --dirty --tagsin CI. See actions/checkout#250.