Age | Commit message (Collapse) | Author |
|
|
|
The Mono builds are with mono_glue=no so they're not usable,
and it would be convenient if the main tools=yes target=release_debug
artifacts could actually be used.
|
|
|
|
|
|
It's normally opt-in as the advanced one (CTL support) is the default,
but we need to build it to catch potential build issues.
|
|
|
|
Applies to javascript files inside the platform library folder, the
exposed Engine code, and any javascript files in modules.
Files ending with ".externs.js" will be ignored, you can create a
".eslintignore" file to specify extra files to be ignored.
|
|
... on all platforms but MSVC, as it still has a number of unsolved warnings
in its `/Wall` level. Some of it might be valid, others might be overkill,
this needs further assessment and fixes. (We could also change the `extra`
level to `/W4` on MSVC if that's more meaningful.)
|
|
No need to waste time downloading all this when it's readily available :)
Also use the official action to setup Java 8.
Also build both architectures (armv7 and arm64v8) and generate the APK,
so we can upload it.
Remove now unused and outdated `misc/ci/android-tools-linux.sh`.
|
|
This keeps their size small and allows to compare size changes on templates
in PRs, as the template size is what is most relevant to users.
For editor builds we keep debug symbols so they can be used to debug crashes.
|
|
It's 1.5 GB, that's maybe a bit overkill.
|
|
|
|
|
|
Set retention-days of all artifacts to 14.
|
|
This can be used to compare impacts on the generated files
and especially their size in PRs.
|
|
Somehow it did not run CI checks so we missed that one.
Also pin `black` version to latest upstream release.
|
|
|
|
|
|
|
|
Nuke all the pre-defined repos, we just need stock Ubuntu.
|
|
Emscripten is a fast-moving target which gets tons of improvements all the time,
but it's not rare that some regressions affect us and make our CI builds fail.
(See e.g. #33728, #35237, #39168, #40563, and #40914.)
Let's pin to a stable version to avoid having external factors impact our CI,
and update this version manually regularly in a PR to ensure that the new
version works well for us.
|
|
|
|
Until https://github.com/psf/black/pull/1328 makes it in a stable release,
we have to use the latest from Git.
Apply new style fixes done by latest black.
|
|
|
|
|
|
Implements exit codes into the engine so tests can return their statuses.
Ideally we don't do this, and we use FIXUP logic to 'begin' and 'end' the engine execution for tests specifically.
Since realistically we're initialising the engine here we don't want to do that, since String should not require an engine startup to test a single header.
This lowers the complexity of running the unit tests and even for
physics should be possible to implement such a fix.
|
|
The base branch is hardcoded as an env variable as I couldn't find a simple
way to just get either `3.2` or `master`. But it's easy to change when we
branch off from `master` to a new stable branch, which doesn't happen often.
(There's `{{github.base_ref}}` but it's probably more verbose like
`ref/heads/master`, and only valid for PRs.)
|
|
|
|
|
|
Mono seems to be preinstalled in the build environment \o/
|
|
Uses mymindstorm/setup-emsdk to install Emscripten and set up
caching for Emscripten's generated system libraries.
|
|
|
|
|
|
These have been replaced by GitHub Actions.
The remaining Travis builds will also be ported eventually.
|
|
|
|
|
|
Otherwise it uses ~/.local/bin which GitHub doesn't include in PATH
|
|
|
|
|
|
This was based on quarmin's initial configuration, we had compile issues with AppVeyor being super slow and GitHub actions will take less time and also manage a full rebuild in 30 minutes.
This adds cache handling and will work with MSVC and scons 4.0, it will build for every PR submitted to the Godot Engine, and also for the branches specified. I have tested the caching and it seems to be working.
I left the 'publish artefacts' disabled until we can request more storage from Microsoft, 5 GB is far to low for us and we would eat this limit very fast. (it is tested and works fine)
Co-authored-by: Rafał Mikrut <mikrutrafal54@gmail.com>
|