Files
ci-emsdk/.circleci/config.yml

374 lines
10 KiB
YAML
Raw Normal View History

version: 2.1
orbs:
win: circleci/windows@5.0
executors:
ubuntu:
docker:
- image: buildpack-deps:jammy
mac_arm64:
environment:
EMSDK_NOTTY: "1"
# Without this, any `brew install` command will result in self-update of
# brew itself which takes more than 4 minutes.
HOMEBREW_NO_AUTO_UPDATE: "1"
macos:
# Corresponds to macOS 12.6.1
# See https://circleci.com/docs/guides/execution-managed/using-macos/#supported-xcode-versions
xcode: "14.0.1"
resource_class: macos.m1.medium.gen1
linux_arm64:
machine:
image: ubuntu-2004:2023.07.1
resource_class: arm.medium
commands:
setup-macos:
steps:
- checkout
- run:
name: Install CMake
command: brew install cmake
test-macos:
steps:
- run:
name: test.sh
command: test/test.sh
- run:
name: test.py
command: |
source emsdk_env.sh
test/test.py
Bazel: Migrate to bzlmod (#1530) This migrates the bazel integration to the new Bazel dependency system "bzlmod". bzlmod is becoming mandatory this year (see second sentence here: https://bazel.build/external/migration). This is a backwards incompatible migration, directly removing the old WORKSPACE based approach. Users will have to change how they depend on bzlmod, however I assume pretty much every user will be happy about it, because they are forced to use bzlmod anyway or add extra flags to continue to build with newer Bazel versions. Given that users normally depend on specific git commits in the old system, they won't be hit with this until they decide to upgrade emsdk. The basic principle here is simple: I took everything that WORKSPACE did and searched an alternative in bzlmod. Some interesting bits: - We have less worries about multiple versions and people depending on emscripten multiple times in different ways. This is resolved by the new system: Bazel first iterates through the MODULE.bazel files recursively, then finds the minimum version needed for each module and then executes the module extensions that define repos exactly once at that version. So no more ifs needed to detect multiple inclusions. - A bunch of nodejs stuff moves to MODULE.bazel, because that is how the nodejs module works now. As their module extension gets executed only once you need to declare everything that you could need before that in the MODULE.bazel file. A side effect of that is that we have to make a fake repository when emscripten doesn't have an arm64 binary for linux, because we can't actually figure that out in MODULE.bazel, so we have to declare that it always exists and then create one in all cases. There is a bunch of autoformatter changes in here as well, I could try to revert them if you prefer. Closes #1509
2025-04-09 23:38:12 +02:00
test-bazel-linux:
steps:
- checkout
- run:
name: install bazelisk
command: |
wget https://github.com/bazelbuild/bazelisk/releases/download/v1.25.0/bazelisk-linux-amd64
chmod +x bazelisk-linux-amd64
mv bazelisk-linux-amd64 /usr/local/bin/bazel
- run: test/test_bazel.sh
test-bazel-mac:
steps:
- checkout
- run:
name: install bazelisk
command: |
brew install bazelisk
- run: test/test_bazel_mac.sh
test-bazel-windows:
steps:
- checkout
- run:
name: Download Bazelisk
shell: powershell.exe
command: |
$ProgressPreference = "SilentlyContinue"
Invoke-WebRequest -Uri https://github.com/bazelbuild/bazelisk/releases/download/v1.10.1/bazelisk-windows-amd64.exe -OutFile ( New-Item -Path "temp\bazel\bazel.exe" -Force )
- run:
name: Run Tests
shell: powershell.exe
command: |
$env:Path += ";C:\Python27amd64;$pwd\temp\bazel"
.\test\test_bazel.ps1
jobs:
2025-12-15 09:57:48 -08:00
lint:
executor: ubuntu
steps:
- checkout
- run:
name: install python deps
command: |
apt-get update -q
apt-get install -q -y python3-pip
- run:
2025-12-15 09:57:48 -08:00
name: python lint
command: |
python3 -m pip install --upgrade pip
2025-12-15 09:57:48 -08:00
python3 -m pip install flake8==7.1.1 ruff==0.14.1
python3 -m flake8 --show-source --statistics --extend-exclude=./scripts
2025-12-15 09:57:48 -08:00
python3 -m ruff check
test-linux:
executor: ubuntu
environment:
EMSDK_NOTTY: "1"
# This is needed because the old gcc-7 that is installed on debian/bionic
# generates warnings about unused variables when doing C++17
# destructuring:
# https://github.com/WebAssembly/binaryen/issues/4353
CXXFLAGS: "-Wno-unused-variable"
# I don't know why circleci VMs pretent to have 36 cores but its a lie.
EMSDK_NUM_CORES: "4"
steps:
- checkout
- run:
name: Install debian packages
command: apt-get update -q && apt-get install -q -y cmake build-essential openjdk-8-jre-headless ksh zsh
- run: test/test_node_path.sh
- run: test/test.sh
- run: test/test_source_env.sh
- run:
name: test.py
command: |
source emsdk_env.sh
test/test.py
test-linux-arm64:
executor: linux_arm64
steps:
- checkout
- run:
name: Install debian packages
command: sudo apt-get update -q && sudo apt-get install -q cmake build-essential openjdk-8-jre-headless
- run: test/test.sh
test-mac-arm64:
executor: mac_arm64
steps:
- setup-macos
- test-macos
test-windows:
executor:
name: win/server-2019
shell: bash.exe
environment:
PYTHONUNBUFFERED: "1"
EMSDK_NOTTY: "1"
steps:
- checkout
- run: where python
- run:
name: Install latest
shell: cmd.exe
command: test\test.bat
- run:
name: test.py
command: |
source emsdk_env.sh
python test/test.py
- run:
name: flagless (process/shell) test
shell: powershell.exe
command: |
test/test_activation.ps1
- run:
name: --permanent test
shell: powershell.exe
command: |
$env:PERMANENT_FLAG="--permanent"
test/test_activation.ps1
- run:
name: --system test
shell: powershell.exe
command: |
$env:SYSTEM_FLAG="--system"
test/test_activation.ps1
- run:
name: Process/Shell PATH preservation test
shell: powershell.exe
command: |
test/test_path_preservation.ps1
- run:
name: User PATH preservation test
shell: powershell.exe
command: |
$env:PERMANENT_FLAG="--permanent"
test/test_path_preservation.ps1
- run:
name: System PATH preservation test
shell: powershell.exe
command: |
$env:SYSTEM_FLAG="--system"
test/test_path_preservation.ps1
build-docker-image-x64:
executor: ubuntu
steps:
- checkout
- run:
name: install docker
command: |
apt-get update -q
apt-get install -q -y ca-certificates curl gnupg lsb-release
mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | tee /etc/apt/sources.list.d/docker.list > /dev/null
apt-get update -q
apt-get install -q -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
- setup_remote_docker
# Build the `latest` version of EMSDK as docker image
- run:
name: build
command: make -C ./docker version=latest build
- run:
name: test
command: make -C ./docker version=latest test
publish-docker-image-x64:
executor: ubuntu
steps:
- checkout
- run:
name: install docker
command: |
apt-get update -q
apt-get install -q -y ca-certificates curl gnupg lsb-release
mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | tee /etc/apt/sources.list.d/docker.list > /dev/null
apt-get update -q
apt-get install -q -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
- setup_remote_docker
- run:
name: build
command: make -C ./docker version=${CIRCLE_TAG} build
- run:
name: test
command: make -C ./docker version=${CIRCLE_TAG} test
- run:
name: push image
command: |
docker login -u "$DOCKER_USER" -p "$DOCKER_PASS"
make -C ./docker version=${CIRCLE_TAG} tag=${CIRCLE_TAG}-x64 push
publish-docker-image-arm64:
executor: linux_arm64
steps:
- checkout
- run:
name: build
command: make -C ./docker version=${CIRCLE_TAG} build
- run:
name: test
command: make -C ./docker version=${CIRCLE_TAG} test
- run:
name: push image
command: |
docker login -u "$DOCKER_USER" -p "$DOCKER_PASS"
make -C ./docker version=${CIRCLE_TAG} tag=${CIRCLE_TAG}-arm64 push
publish-docker-image-multiplatform:
executor: linux_arm64
steps:
- checkout
- run:
name: push image
command: |
docker login -u "$DOCKER_USER" -p "$DOCKER_PASS"
make -C ./docker version=${CIRCLE_TAG} tag=${CIRCLE_TAG} push-multiplatform
make -C ./docker version=${CIRCLE_TAG} tag="latest" push-multiplatform
Bazel: Migrate to bzlmod (#1530) This migrates the bazel integration to the new Bazel dependency system "bzlmod". bzlmod is becoming mandatory this year (see second sentence here: https://bazel.build/external/migration). This is a backwards incompatible migration, directly removing the old WORKSPACE based approach. Users will have to change how they depend on bzlmod, however I assume pretty much every user will be happy about it, because they are forced to use bzlmod anyway or add extra flags to continue to build with newer Bazel versions. Given that users normally depend on specific git commits in the old system, they won't be hit with this until they decide to upgrade emsdk. The basic principle here is simple: I took everything that WORKSPACE did and searched an alternative in bzlmod. Some interesting bits: - We have less worries about multiple versions and people depending on emscripten multiple times in different ways. This is resolved by the new system: Bazel first iterates through the MODULE.bazel files recursively, then finds the minimum version needed for each module and then executes the module extensions that define repos exactly once at that version. So no more ifs needed to detect multiple inclusions. - A bunch of nodejs stuff moves to MODULE.bazel, because that is how the nodejs module works now. As their module extension gets executed only once you need to declare everything that you could need before that in the MODULE.bazel file. A side effect of that is that we have to make a fake repository when emscripten doesn't have an arm64 binary for linux, because we can't actually figure that out in MODULE.bazel, so we have to declare that it always exists and then create one in all cases. There is a bunch of autoformatter changes in here as well, I could try to revert them if you prefer. Closes #1509
2025-04-09 23:38:12 +02:00
test-bazel7-linux:
executor: ubuntu
Bazel: Migrate to bzlmod (#1530) This migrates the bazel integration to the new Bazel dependency system "bzlmod". bzlmod is becoming mandatory this year (see second sentence here: https://bazel.build/external/migration). This is a backwards incompatible migration, directly removing the old WORKSPACE based approach. Users will have to change how they depend on bzlmod, however I assume pretty much every user will be happy about it, because they are forced to use bzlmod anyway or add extra flags to continue to build with newer Bazel versions. Given that users normally depend on specific git commits in the old system, they won't be hit with this until they decide to upgrade emsdk. The basic principle here is simple: I took everything that WORKSPACE did and searched an alternative in bzlmod. Some interesting bits: - We have less worries about multiple versions and people depending on emscripten multiple times in different ways. This is resolved by the new system: Bazel first iterates through the MODULE.bazel files recursively, then finds the minimum version needed for each module and then executes the module extensions that define repos exactly once at that version. So no more ifs needed to detect multiple inclusions. - A bunch of nodejs stuff moves to MODULE.bazel, because that is how the nodejs module works now. As their module extension gets executed only once you need to declare everything that you could need before that in the MODULE.bazel file. A side effect of that is that we have to make a fake repository when emscripten doesn't have an arm64 binary for linux, because we can't actually figure that out in MODULE.bazel, so we have to declare that it always exists and then create one in all cases. There is a bunch of autoformatter changes in here as well, I could try to revert them if you prefer. Closes #1509
2025-04-09 23:38:12 +02:00
environment:
USE_BAZEL_VERSION: "7.x"
2020-09-10 21:42:46 -04:00
steps:
Bazel: Migrate to bzlmod (#1530) This migrates the bazel integration to the new Bazel dependency system "bzlmod". bzlmod is becoming mandatory this year (see second sentence here: https://bazel.build/external/migration). This is a backwards incompatible migration, directly removing the old WORKSPACE based approach. Users will have to change how they depend on bzlmod, however I assume pretty much every user will be happy about it, because they are forced to use bzlmod anyway or add extra flags to continue to build with newer Bazel versions. Given that users normally depend on specific git commits in the old system, they won't be hit with this until they decide to upgrade emsdk. The basic principle here is simple: I took everything that WORKSPACE did and searched an alternative in bzlmod. Some interesting bits: - We have less worries about multiple versions and people depending on emscripten multiple times in different ways. This is resolved by the new system: Bazel first iterates through the MODULE.bazel files recursively, then finds the minimum version needed for each module and then executes the module extensions that define repos exactly once at that version. So no more ifs needed to detect multiple inclusions. - A bunch of nodejs stuff moves to MODULE.bazel, because that is how the nodejs module works now. As their module extension gets executed only once you need to declare everything that you could need before that in the MODULE.bazel file. A side effect of that is that we have to make a fake repository when emscripten doesn't have an arm64 binary for linux, because we can't actually figure that out in MODULE.bazel, so we have to declare that it always exists and then create one in all cases. There is a bunch of autoformatter changes in here as well, I could try to revert them if you prefer. Closes #1509
2025-04-09 23:38:12 +02:00
- test-bazel-linux
2020-09-10 21:42:46 -04:00
Bazel: Migrate to bzlmod (#1530) This migrates the bazel integration to the new Bazel dependency system "bzlmod". bzlmod is becoming mandatory this year (see second sentence here: https://bazel.build/external/migration). This is a backwards incompatible migration, directly removing the old WORKSPACE based approach. Users will have to change how they depend on bzlmod, however I assume pretty much every user will be happy about it, because they are forced to use bzlmod anyway or add extra flags to continue to build with newer Bazel versions. Given that users normally depend on specific git commits in the old system, they won't be hit with this until they decide to upgrade emsdk. The basic principle here is simple: I took everything that WORKSPACE did and searched an alternative in bzlmod. Some interesting bits: - We have less worries about multiple versions and people depending on emscripten multiple times in different ways. This is resolved by the new system: Bazel first iterates through the MODULE.bazel files recursively, then finds the minimum version needed for each module and then executes the module extensions that define repos exactly once at that version. So no more ifs needed to detect multiple inclusions. - A bunch of nodejs stuff moves to MODULE.bazel, because that is how the nodejs module works now. As their module extension gets executed only once you need to declare everything that you could need before that in the MODULE.bazel file. A side effect of that is that we have to make a fake repository when emscripten doesn't have an arm64 binary for linux, because we can't actually figure that out in MODULE.bazel, so we have to declare that it always exists and then create one in all cases. There is a bunch of autoformatter changes in here as well, I could try to revert them if you prefer. Closes #1509
2025-04-09 23:38:12 +02:00
test-bazel-latest-linux:
executor: ubuntu
steps:
- test-bazel-linux
test-bazel7-mac-arm64:
executor: mac_arm64
environment:
Bazel: Migrate to bzlmod (#1530) This migrates the bazel integration to the new Bazel dependency system "bzlmod". bzlmod is becoming mandatory this year (see second sentence here: https://bazel.build/external/migration). This is a backwards incompatible migration, directly removing the old WORKSPACE based approach. Users will have to change how they depend on bzlmod, however I assume pretty much every user will be happy about it, because they are forced to use bzlmod anyway or add extra flags to continue to build with newer Bazel versions. Given that users normally depend on specific git commits in the old system, they won't be hit with this until they decide to upgrade emsdk. The basic principle here is simple: I took everything that WORKSPACE did and searched an alternative in bzlmod. Some interesting bits: - We have less worries about multiple versions and people depending on emscripten multiple times in different ways. This is resolved by the new system: Bazel first iterates through the MODULE.bazel files recursively, then finds the minimum version needed for each module and then executes the module extensions that define repos exactly once at that version. So no more ifs needed to detect multiple inclusions. - A bunch of nodejs stuff moves to MODULE.bazel, because that is how the nodejs module works now. As their module extension gets executed only once you need to declare everything that you could need before that in the MODULE.bazel file. A side effect of that is that we have to make a fake repository when emscripten doesn't have an arm64 binary for linux, because we can't actually figure that out in MODULE.bazel, so we have to declare that it always exists and then create one in all cases. There is a bunch of autoformatter changes in here as well, I could try to revert them if you prefer. Closes #1509
2025-04-09 23:38:12 +02:00
USE_BAZEL_VERSION: "7.x"
steps:
Bazel: Migrate to bzlmod (#1530) This migrates the bazel integration to the new Bazel dependency system "bzlmod". bzlmod is becoming mandatory this year (see second sentence here: https://bazel.build/external/migration). This is a backwards incompatible migration, directly removing the old WORKSPACE based approach. Users will have to change how they depend on bzlmod, however I assume pretty much every user will be happy about it, because they are forced to use bzlmod anyway or add extra flags to continue to build with newer Bazel versions. Given that users normally depend on specific git commits in the old system, they won't be hit with this until they decide to upgrade emsdk. The basic principle here is simple: I took everything that WORKSPACE did and searched an alternative in bzlmod. Some interesting bits: - We have less worries about multiple versions and people depending on emscripten multiple times in different ways. This is resolved by the new system: Bazel first iterates through the MODULE.bazel files recursively, then finds the minimum version needed for each module and then executes the module extensions that define repos exactly once at that version. So no more ifs needed to detect multiple inclusions. - A bunch of nodejs stuff moves to MODULE.bazel, because that is how the nodejs module works now. As their module extension gets executed only once you need to declare everything that you could need before that in the MODULE.bazel file. A side effect of that is that we have to make a fake repository when emscripten doesn't have an arm64 binary for linux, because we can't actually figure that out in MODULE.bazel, so we have to declare that it always exists and then create one in all cases. There is a bunch of autoformatter changes in here as well, I could try to revert them if you prefer. Closes #1509
2025-04-09 23:38:12 +02:00
- test-bazel-mac
Bazel: Migrate to bzlmod (#1530) This migrates the bazel integration to the new Bazel dependency system "bzlmod". bzlmod is becoming mandatory this year (see second sentence here: https://bazel.build/external/migration). This is a backwards incompatible migration, directly removing the old WORKSPACE based approach. Users will have to change how they depend on bzlmod, however I assume pretty much every user will be happy about it, because they are forced to use bzlmod anyway or add extra flags to continue to build with newer Bazel versions. Given that users normally depend on specific git commits in the old system, they won't be hit with this until they decide to upgrade emsdk. The basic principle here is simple: I took everything that WORKSPACE did and searched an alternative in bzlmod. Some interesting bits: - We have less worries about multiple versions and people depending on emscripten multiple times in different ways. This is resolved by the new system: Bazel first iterates through the MODULE.bazel files recursively, then finds the minimum version needed for each module and then executes the module extensions that define repos exactly once at that version. So no more ifs needed to detect multiple inclusions. - A bunch of nodejs stuff moves to MODULE.bazel, because that is how the nodejs module works now. As their module extension gets executed only once you need to declare everything that you could need before that in the MODULE.bazel file. A side effect of that is that we have to make a fake repository when emscripten doesn't have an arm64 binary for linux, because we can't actually figure that out in MODULE.bazel, so we have to declare that it always exists and then create one in all cases. There is a bunch of autoformatter changes in here as well, I could try to revert them if you prefer. Closes #1509
2025-04-09 23:38:12 +02:00
test-bazel-latest-mac-arm64:
executor: mac_arm64
steps:
- test-bazel-mac
test-bazel7-windows:
2021-12-20 11:24:56 -08:00
executor:
name: win/server-2019
2021-12-20 11:24:56 -08:00
shell: powershell.exe -ExecutionPolicy Bypass
environment:
PYTHONUNBUFFERED: "1"
EMSDK_NOTTY: "1"
Bazel: Migrate to bzlmod (#1530) This migrates the bazel integration to the new Bazel dependency system "bzlmod". bzlmod is becoming mandatory this year (see second sentence here: https://bazel.build/external/migration). This is a backwards incompatible migration, directly removing the old WORKSPACE based approach. Users will have to change how they depend on bzlmod, however I assume pretty much every user will be happy about it, because they are forced to use bzlmod anyway or add extra flags to continue to build with newer Bazel versions. Given that users normally depend on specific git commits in the old system, they won't be hit with this until they decide to upgrade emsdk. The basic principle here is simple: I took everything that WORKSPACE did and searched an alternative in bzlmod. Some interesting bits: - We have less worries about multiple versions and people depending on emscripten multiple times in different ways. This is resolved by the new system: Bazel first iterates through the MODULE.bazel files recursively, then finds the minimum version needed for each module and then executes the module extensions that define repos exactly once at that version. So no more ifs needed to detect multiple inclusions. - A bunch of nodejs stuff moves to MODULE.bazel, because that is how the nodejs module works now. As their module extension gets executed only once you need to declare everything that you could need before that in the MODULE.bazel file. A side effect of that is that we have to make a fake repository when emscripten doesn't have an arm64 binary for linux, because we can't actually figure that out in MODULE.bazel, so we have to declare that it always exists and then create one in all cases. There is a bunch of autoformatter changes in here as well, I could try to revert them if you prefer. Closes #1509
2025-04-09 23:38:12 +02:00
# For some reason version resolution with "7.x" does not work on Windows,
# so we have to specify a full version.
USE_BAZEL_VERSION: "7.6.1"
2021-12-20 11:24:56 -08:00
steps:
Bazel: Migrate to bzlmod (#1530) This migrates the bazel integration to the new Bazel dependency system "bzlmod". bzlmod is becoming mandatory this year (see second sentence here: https://bazel.build/external/migration). This is a backwards incompatible migration, directly removing the old WORKSPACE based approach. Users will have to change how they depend on bzlmod, however I assume pretty much every user will be happy about it, because they are forced to use bzlmod anyway or add extra flags to continue to build with newer Bazel versions. Given that users normally depend on specific git commits in the old system, they won't be hit with this until they decide to upgrade emsdk. The basic principle here is simple: I took everything that WORKSPACE did and searched an alternative in bzlmod. Some interesting bits: - We have less worries about multiple versions and people depending on emscripten multiple times in different ways. This is resolved by the new system: Bazel first iterates through the MODULE.bazel files recursively, then finds the minimum version needed for each module and then executes the module extensions that define repos exactly once at that version. So no more ifs needed to detect multiple inclusions. - A bunch of nodejs stuff moves to MODULE.bazel, because that is how the nodejs module works now. As their module extension gets executed only once you need to declare everything that you could need before that in the MODULE.bazel file. A side effect of that is that we have to make a fake repository when emscripten doesn't have an arm64 binary for linux, because we can't actually figure that out in MODULE.bazel, so we have to declare that it always exists and then create one in all cases. There is a bunch of autoformatter changes in here as well, I could try to revert them if you prefer. Closes #1509
2025-04-09 23:38:12 +02:00
- test-bazel-windows
test-bazel-latest-windows:
executor:
name: win/server-2019
shell: powershell.exe -ExecutionPolicy Bypass
environment:
PYTHONUNBUFFERED: "1"
EMSDK_NOTTY: "1"
steps:
- test-bazel-windows
2021-12-20 11:24:56 -08:00
workflows:
2025-12-15 09:57:48 -08:00
lint:
jobs:
2025-12-15 09:57:48 -08:00
- lint
test-linux:
jobs:
- test-linux
test-linux-arm64:
jobs:
- test-linux-arm64
test-mac-arm64:
jobs:
- test-mac-arm64
test-windows:
jobs:
- test-windows
build-docker-image:
jobs:
- build-docker-image-x64
- publish-docker-image-x64:
filters:
branches:
ignore: /.*/
tags:
only: /.*/
- publish-docker-image-arm64:
filters:
branches:
ignore: /.*/
tags:
only: /.*/
- publish-docker-image-multiplatform:
filters:
tags:
only: /.*/
requires:
- publish-docker-image-x64
- publish-docker-image-arm64
Bazel: Migrate to bzlmod (#1530) This migrates the bazel integration to the new Bazel dependency system "bzlmod". bzlmod is becoming mandatory this year (see second sentence here: https://bazel.build/external/migration). This is a backwards incompatible migration, directly removing the old WORKSPACE based approach. Users will have to change how they depend on bzlmod, however I assume pretty much every user will be happy about it, because they are forced to use bzlmod anyway or add extra flags to continue to build with newer Bazel versions. Given that users normally depend on specific git commits in the old system, they won't be hit with this until they decide to upgrade emsdk. The basic principle here is simple: I took everything that WORKSPACE did and searched an alternative in bzlmod. Some interesting bits: - We have less worries about multiple versions and people depending on emscripten multiple times in different ways. This is resolved by the new system: Bazel first iterates through the MODULE.bazel files recursively, then finds the minimum version needed for each module and then executes the module extensions that define repos exactly once at that version. So no more ifs needed to detect multiple inclusions. - A bunch of nodejs stuff moves to MODULE.bazel, because that is how the nodejs module works now. As their module extension gets executed only once you need to declare everything that you could need before that in the MODULE.bazel file. A side effect of that is that we have to make a fake repository when emscripten doesn't have an arm64 binary for linux, because we can't actually figure that out in MODULE.bazel, so we have to declare that it always exists and then create one in all cases. There is a bunch of autoformatter changes in here as well, I could try to revert them if you prefer. Closes #1509
2025-04-09 23:38:12 +02:00
test-bazel7-linux:
jobs:
Bazel: Migrate to bzlmod (#1530) This migrates the bazel integration to the new Bazel dependency system "bzlmod". bzlmod is becoming mandatory this year (see second sentence here: https://bazel.build/external/migration). This is a backwards incompatible migration, directly removing the old WORKSPACE based approach. Users will have to change how they depend on bzlmod, however I assume pretty much every user will be happy about it, because they are forced to use bzlmod anyway or add extra flags to continue to build with newer Bazel versions. Given that users normally depend on specific git commits in the old system, they won't be hit with this until they decide to upgrade emsdk. The basic principle here is simple: I took everything that WORKSPACE did and searched an alternative in bzlmod. Some interesting bits: - We have less worries about multiple versions and people depending on emscripten multiple times in different ways. This is resolved by the new system: Bazel first iterates through the MODULE.bazel files recursively, then finds the minimum version needed for each module and then executes the module extensions that define repos exactly once at that version. So no more ifs needed to detect multiple inclusions. - A bunch of nodejs stuff moves to MODULE.bazel, because that is how the nodejs module works now. As their module extension gets executed only once you need to declare everything that you could need before that in the MODULE.bazel file. A side effect of that is that we have to make a fake repository when emscripten doesn't have an arm64 binary for linux, because we can't actually figure that out in MODULE.bazel, so we have to declare that it always exists and then create one in all cases. There is a bunch of autoformatter changes in here as well, I could try to revert them if you prefer. Closes #1509
2025-04-09 23:38:12 +02:00
- test-bazel7-linux
test-bazel-latest-linux:
2020-09-10 21:42:46 -04:00
jobs:
Bazel: Migrate to bzlmod (#1530) This migrates the bazel integration to the new Bazel dependency system "bzlmod". bzlmod is becoming mandatory this year (see second sentence here: https://bazel.build/external/migration). This is a backwards incompatible migration, directly removing the old WORKSPACE based approach. Users will have to change how they depend on bzlmod, however I assume pretty much every user will be happy about it, because they are forced to use bzlmod anyway or add extra flags to continue to build with newer Bazel versions. Given that users normally depend on specific git commits in the old system, they won't be hit with this until they decide to upgrade emsdk. The basic principle here is simple: I took everything that WORKSPACE did and searched an alternative in bzlmod. Some interesting bits: - We have less worries about multiple versions and people depending on emscripten multiple times in different ways. This is resolved by the new system: Bazel first iterates through the MODULE.bazel files recursively, then finds the minimum version needed for each module and then executes the module extensions that define repos exactly once at that version. So no more ifs needed to detect multiple inclusions. - A bunch of nodejs stuff moves to MODULE.bazel, because that is how the nodejs module works now. As their module extension gets executed only once you need to declare everything that you could need before that in the MODULE.bazel file. A side effect of that is that we have to make a fake repository when emscripten doesn't have an arm64 binary for linux, because we can't actually figure that out in MODULE.bazel, so we have to declare that it always exists and then create one in all cases. There is a bunch of autoformatter changes in here as well, I could try to revert them if you prefer. Closes #1509
2025-04-09 23:38:12 +02:00
- test-bazel-latest-linux
test-bazel7-mac-arm64:
2021-12-20 11:24:56 -08:00
jobs:
Bazel: Migrate to bzlmod (#1530) This migrates the bazel integration to the new Bazel dependency system "bzlmod". bzlmod is becoming mandatory this year (see second sentence here: https://bazel.build/external/migration). This is a backwards incompatible migration, directly removing the old WORKSPACE based approach. Users will have to change how they depend on bzlmod, however I assume pretty much every user will be happy about it, because they are forced to use bzlmod anyway or add extra flags to continue to build with newer Bazel versions. Given that users normally depend on specific git commits in the old system, they won't be hit with this until they decide to upgrade emsdk. The basic principle here is simple: I took everything that WORKSPACE did and searched an alternative in bzlmod. Some interesting bits: - We have less worries about multiple versions and people depending on emscripten multiple times in different ways. This is resolved by the new system: Bazel first iterates through the MODULE.bazel files recursively, then finds the minimum version needed for each module and then executes the module extensions that define repos exactly once at that version. So no more ifs needed to detect multiple inclusions. - A bunch of nodejs stuff moves to MODULE.bazel, because that is how the nodejs module works now. As their module extension gets executed only once you need to declare everything that you could need before that in the MODULE.bazel file. A side effect of that is that we have to make a fake repository when emscripten doesn't have an arm64 binary for linux, because we can't actually figure that out in MODULE.bazel, so we have to declare that it always exists and then create one in all cases. There is a bunch of autoformatter changes in here as well, I could try to revert them if you prefer. Closes #1509
2025-04-09 23:38:12 +02:00
- test-bazel7-mac-arm64
test-bazel-latest-mac-arm64:
jobs:
- test-bazel-latest-mac-arm64
test-bazel7-windows:
jobs:
- test-bazel7-windows
test-bazel-latest-windows:
jobs:
- test-bazel-latest-windows