Browse Source

package/ci: revert attempts to go with a small CircleCI resource class.

It's just not worth the pain. I have to reduce the parallelism from 24
to 6, and yet it still sometimes gets stuck. And at that point it's
about twice as slow, so there's not really any gain from this costing
half the credits.

This reverts commit 9d61a63553.
This reverts commit 9c4f2ceea2.
This reverts commit 80b7694468.
pull/578/head
Vladimír Vondruš 4 years ago
parent
commit
c475d0b6e7
  1. 68
      package/ci/circleci.yml

68
package/ci/circleci.yml

@ -5,11 +5,9 @@ orbs:
executors:
ubuntu-18_04:
resource_class: small
docker:
- image: ubuntu:bionic-20220427
xcode-11_5:
resource_class: medium # there isn't smaller
# Molten-vk isn't in (non-updated) Homebrew on the 9.4 or 10.0/1/2 image,
# have to use 10.3 instead; since 2021-06-08 it refuses to work on 10.14 so
# have to use 11.2 at least; since 2022-01-20 the oldest 11 image is 11.4.
@ -18,11 +16,9 @@ executors:
macos:
xcode: 11.5
xcode-11_6:
resource_class: medium # there isn't smaller
macos:
xcode: 11.6.0
emscripten1:
resource_class: small
docker:
# 1.39.0 is the oldest on Docker. Anything before 1.39.2 is useless as emar
# randomly asserts: https://github.com/emscripten-core/emscripten/pull/9742
@ -32,7 +28,6 @@ executors:
# https://github.com/emscripten-core/emscripten/pull/10161
- image: emscripten/emsdk:1.39.6-upstream
emscripten2:
resource_class: small
docker:
# Used by the webgl2 job. 2.0.17 is the first version that exposes
# glGetBufferSubData() so GLES3 tests can read buffer data without having
@ -42,13 +37,12 @@ executors:
# mysteriously disappears. See https://github.com/mosra/magnum/issues/507.
- image: emscripten/emsdk:2.0.25
android-29:
resource_class: medium # there isn't smaller
machine:
image: android:202102-01
arm64:
resource_class: arm.medium # there isn't smaller
machine:
image: ubuntu-2004:202101-01
resource_class: arm.medium
commands:
install-base-linux:
@ -84,10 +78,9 @@ commands:
parameters:
count:
type: integer
# It reports 36 cores and ninja goes with 38 currently, RAM on the
# small resource class is 2 GB. Even 20 jobs is too much.
# TODO: revert back to 24 if we go back to medium resource class
default: 10
# It reports 36 cores and ninja goes with 38 currently, RAM fluctuates
# from 3 to 70 GB.
default: 24
steps:
- run:
name: Query CPU cores, default Ninja parallelism and available RAM, cap jobs
@ -283,7 +276,11 @@ jobs:
steps:
- install-base-linux:
extra: libgl1-mesa-dev libsdl2-dev libglfw3-dev libopenal-dev libvulkan-dev
- cap-ninja-jobs
# In this case it gets stuck even with 24 jobs. Only on GCC, usually when
# the huge TradeAbstractImporterTest / TradeMaterialDataTest get involved.
# TODO: revisit when we get rid of more STL
- cap-ninja-jobs:
count: 20
- install-gcc-4_8
- install-cmake:
version: "3.4.3"
@ -317,9 +314,11 @@ jobs:
steps:
- install-base-linux:
extra: cmake libsdl2-dev libglfw3-dev libvulkan-dev wget unzip
# 10 still causes a crash/timeout
- cap-ninja-jobs:
count: 8
# It crashes with the default setting. Only on GCC, usually when the huge
# TradeAbstractImporterTest / TradeMaterialDataTest / TradeSceneDataTest
# get involved.
# TODO: revisit when we get rid of more STL
- cap-ninja-jobs
- install-gcc-4_8
- install-swiftshader-vulkan:
build: ubuntu-18.04
@ -339,9 +338,11 @@ jobs:
steps:
- install-base-linux:
extra: libsdl2-dev libglfw3-dev wget unzip
# 10 still causes a crash/timeout
- cap-ninja-jobs:
count: 8
# It crashes with the default setting. Only on GCC, usually when the huge
# TradeAbstractImporterTest / TradeMaterialDataTest / TradeSceneDataTest
# get involved.
# TODO: revisit when we get rid of more STL
- cap-ninja-jobs
- install-gcc-4_8
- install-cmake:
version: "3.4.3"
@ -363,9 +364,11 @@ jobs:
steps:
- install-base-linux:
extra: libsdl2-dev libglfw3-dev wget unzip
# 10 still causes a crash/timeout
- cap-ninja-jobs:
count: 8
# It crashes with the default setting. Only on GCC, usually when the huge
# TradeAbstractImporterTest / TradeMaterialDataTest / TradeSceneDataTest
# get involved.
# TODO: revisit when we get rid of more STL
- cap-ninja-jobs
- install-gcc-4_8
- install-cmake:
version: "3.4.3"
@ -388,7 +391,10 @@ jobs:
steps:
- install-base-linux:
extra: libgl1-mesa-dev libsdl2-dev libglfw3-dev libopenal-dev libvulkan-dev
- cap-ninja-jobs
# 24 is not enough, unlike the other GCC-based builds
# TODO: revisit when we get rid of more STL
- cap-ninja-jobs:
count: 20
- install-gcc-4_8
- install-cmake:
version: "3.4.3"
@ -408,6 +414,10 @@ jobs:
steps:
- install-base-linux:
extra: libgl1-mesa-dev libsdl2-dev libglfw3-dev libopenal-dev libvulkan-dev
# It crashes with the default setting. Only on GCC, usually when the huge
# TradeAbstractImporterTest / TradeMaterialDataTest / TradeSceneDataTest
# get involved.
# TODO: revisit when we get rid of more STL
- cap-ninja-jobs
- install-gcc-4_8
- install-cmake:
@ -429,9 +439,6 @@ jobs:
steps:
- install-base-linux:
extra: libgl1-mesa-dev libopenal-dev libvulkan-dev
# Clang used to not need that much RAM on the medium resource class so the
# default was fine, but on the small class it's too much.
- cap-ninja-jobs
- install-clang
- install-cmake:
version: "3.4.3"
@ -452,9 +459,6 @@ jobs:
steps:
- install-base-linux:
extra: libgl1-mesa-dev libopenal-dev libvulkan-dev
# Clang used to not need that much RAM on the medium resource class so the
# default was fine, but on the small class it's too much.
- cap-ninja-jobs
- install-clang
- install-cmake:
version: "3.4.3"
@ -532,9 +536,7 @@ jobs:
TARGET_GLES2: "ON"
steps:
- install-base-linux
# 10 still causes a crash/timeout
- cap-ninja-jobs:
count: 8
- cap-ninja-jobs
- build:
script: emscripten.sh
@ -545,9 +547,7 @@ jobs:
TARGET_GLES2: "OFF"
steps:
- install-base-linux
# 10 still causes a crash/timeout
- cap-ninja-jobs:
count: 8
- cap-ninja-jobs
- build:
script: emscripten.sh

Loading…
Cancel
Save