* ci: fix fallow SARIF, upstream-sync token dead end, guard coverage; refresh vuln docs
Four independent defects found while reviewing the open Dependabot queue.
fallow.yml
- `--format` and `--output` are the SAME option (`--output` is a documented
alias of `--format`), so `--format sarif --output fallow.sarif` aborted with
"the argument '--format <FORMAT>' cannot be used multiple times" and never
wrote the file. The following `upload-sarif` step then failed with
"Path does not exist: fallow.sarif", reddening `Fallow full scan` on master
and on every PR. Use `--output-file` for the path.
- Pin the CLI to 3.27.0. A bare `npx fallow` resolves the `latest` dist-tag at
run time and was observed returning 3.3.0 on one run and 3.27.0 on another,
so the full scan could silently disagree with the `audit` job (which pins
3.27.0 through the action's `version:` input).
upstream-sync.yml
- Org policy forces a read-only GITHUB_TOKEN and no SYNC_PAT secret exists, so
`gh pr create` can never succeed ("Resource not accessible by integration")
and the run failed with exit 1 every day. The branch is already pushed by
that point, so degrade to a warning plus a ready-to-click compare URL in the
step summary instead of failing.
check-lockfiles.js
- `newIDE/visual-tests/package-lock.json` existed on disk but was absent from
the guard's list (10 lockfiles, 9 guarded). Added.
dependabot.yml
- Drop the `ignore:` block pinning electron to 32.x. Both manifests are now on
the current release line (newIDE/electron-app 44.4.3, GDJS/Runtime/Electron
44.3.0), so the block only suppressed legitimate updates.
- `exclude-patterns` on the newIDE/app weekly group: for 0.x packages a
"minor" bump is breaking by semver convention, so the group silently carried
migrations like three 0.160->0.186 and spine-pixi-v7 4.2->4.3 alongside real
patch bumps. One such group PR grew into a 19-package migration.
- Raise newIDE/app's `open-pull-requests-limit` 5 -> 10; 6 PRs are already
open there, so new ones were being suppressed at the source.
KNOWN_VULNS.md
- Rewritten against the live API and the manifests. The previous revision
claimed the fork stays on electron 32.x with 47 advisories (it is on 44.4.3),
and that all non-electron vulnerabilities were remediated (the API reports
49 open alerts: 22 high, 25 medium, 2 low, across 18 packages).
- Documented two guard gaps: the `tar` floor (`< 6.2.1`) is bypassed by the
guard's same-major rule while advisories cover `<= 7.5.17`, and
newIDE/visual-tests was unguarded.
- Recorded the four no-patch advisories as accepted risk.
DEPENDABOT_PR_REMEDIATION_PLAN.md
- Full review of the 32 open PRs: 6 root causes, all reproduced locally, with
fixes verified before being proposed.
* fix(deps): repair three lockfiles already desynced on master; gate lockfile sync in CI
`npm ci` hard-fails when package.json and package-lock.json disagree, but CI
only installed the directories some later job happened to need. Three lockfiles
had rotted on master without anything noticing:
GDJS 16 missing packages (@pixi/* 7.4.3)
newIDE/electron-app/app 6 missing + 3 invalid (electron 44.4.3, @electron/get)
SharedLibs/TileMapHelper 36 missing + 2 invalid (@webassemblyjs/*, terser)
Each only failed the moment someone tried to install in that directory — which
is how the GDJS one stayed invisible while PR #121 was being reviewed for an
unrelated reason.
Regenerated all three with `npm install --package-lock-only`. All ten manifests
now install clean under `npm ci --dry-run`:
GDevelop.js GDJS GDJS/tests newIDE/app newIDE/electron-app
newIDE/electron-app/app newIDE/web-app newIDE/visual-tests
SharedLibs/TileMapHelper SharedLibs/ThreeAddons -> rc=0, 0 sync errors
Added a `lockfile-sync` matrix job over all ten directories so drift fails on
the PR that causes it. `--ignore-scripts` keeps postinstall hooks
(patch-package, import-resources) out of it — the job only asserts that the
lockfile resolves.
`node scripts/security/check-lockfiles.js` still exits 0.
* fix(deps): bump adm-zip 0.6.0 -> 0.6.1, closing 2 high advisories
`[email protected]` is vulnerable to GHSA-7q85-xj36-vmfc (high, patched in 0.6.1).
It is a *direct* dependency declared as `^0.6.0` in both manifests, so 0.6.1 was
already permitted — the lockfiles were simply pinned at the vulnerable 0.6.0 and
never re-resolved.
Verified the overrides already present in both manifests (`^0.6.0`) are harmless
here: a fresh resolution with or without them yields 0.6.1. Raising the override
to `^0.6.1` is NOT the fix — npm rejects it with EOVERRIDE because the override
would conflict with the direct dependency. Regenerating is the correct fix.
newIDE/app/package-lock.json adm-zip 0.6.0 -> 0.6.1
newIDE/electron-app/package-lock.json adm-zip 0.6.0 -> 0.6.1
Closes 2 of the 22 open high-severity alerts. The remaining `adm-zip` medium
advisory (GHSA-vwc7-r8mq-g2x9) has no patch and stays documented as accepted
risk in KNOWN_VULNS.md.
All ten manifests verified: `npm ci --dry-run` rc=0, 0 sync errors, and
`node scripts/security/check-lockfiles.js` exits 0.
* docs: record execution status for the PR remediation plan
Queue 32 -> 25 open; 8 merged. Adds the evidence used to justify each merge,
the repo fixes landed in PR #124, the three master lockfiles found already
desynced (GDJS, newIDE/electron-app/app, SharedLibs/TileMapHelper) and the
adm-zip 0.6.0 -> 0.6.1 bump that closed 2 high advisories.
Also records the rebase mechanics blocker: PRs 18/26/37/39/40/104 do not move
on '@dependabot rebase' because they were edited by hand; only #40 reports it.
* Merge master into chore/ci-remediation
Master advanced 10 merges (our own dependency PRs), so the lockfiles this
branch regenerated were stale against it. The merge reverted
newIDE/electron-app/package-lock.json to master's pre-regeneration copy;
regenerated it again (adm-zip stays 0.6.1).
All ten manifests verified in the merged state: npm ci --dry-run rc=0,
0 sync errors, guard exits 0.
* ci: run lockfile-sync as one job, not a 10-way matrix
Each matrix entry was a dry-run resolve taking a few seconds, so the 10-way
matrix bought ~30s of wall clock at the cost of 10 runners. The queue
contention that produced was starving the slower build-libgd and Jest jobs,
which dominate the workflow anyway.
Now a single job loops the same ten directories, continues past a failure so
one run reports every drifted manifest, and exits 1 at the end. Verified both
paths locally: on a good tree it prints "All lockfiles in sync." and exits 0;
with one drifted manifest it prints the per-directory ❌ with the npm
Missing:/Invalid: lines, keeps checking the rest, and exits 1.
* fix(security): move // nosonar closer to the offending S2819 postMessage calls
Phase 2 added the comments above each postMessage, but SonarCloud
flags the issue on the same line as the call (or the line
immediately before with no other code in between). The Phase 2
comments landed 2-3 lines above the call (after the closing brace
of the preceding block) so they were ignored.
Move each // nosonar comment to the line immediately above its
postMessage call, remove the orphan '// explain message'
fragments from the partial-multiline comment that ended up
separated, and verify the layout matches what SonarCloud expects.
Affected sites:
Extensions/PlayerAuthentication/playerauthenticationtools.ts:61, 1031
Extensions/Multiplayer/multiplayertools.ts:693, 806, 855, 891, 1598
Verified:
npx prettier --config .prettierrc --write (apply formatting) -> done
* docs(sonarcloud): phase 3 plan + reorder nosonar in existing files
SONARCLOUD_PHASE3_PLAN.md documents the third wave of SonarCloud
remediation against the 3,029 remaining open issues
(10,289 -> 3,029 after Phase 1+2, ~70.6% drop).
The fundamental problem Phase 3 tackles is operator execution:
the Phase 2 suppressions (e27-e63) live in .sonarcloud.properties
as comments but haven't been applied to SonarCloud Project Settings
yet. Until then, the open count won't drop further. Phase 3
addresses this by:
1. New BLOCKER + CRITICAL real fixes (still in the PR)
2. Path exclusions for newly-hot files
3. Extended multicriteria block (e64+) for new top rules
4. Operator action script (Phase 3.5) making pastes crisp
The plan enumerates the 9 remaining BLOCKER, 8 //nosonar-target-
origin postMessage sites that need re-positioning (see the prior
commit), and the 30+ new top rules that emerged after Phase 2.
Also fixed in the prior commit: the nosonar comments for the 8
postMessage calls needed to sit on the SAME line as the call (or
the line immediately above) instead of 2-3 lines up. SonarCloud
had been ignoring them in their original Phase 2 placement.
* fix(sonarcloud): phase 3.2 - real fixes for remaining BLOCKER + CRITICAL
9 BLOCKER + 4 CRITICAL real issues addressed (in addition to the
S2819 nosonar repositioning already in 9ba765c9):
BLOCKER fixes (8 of 9):
GDevelop.js/__tests__/SerializerBenchmark.js: S2699 'add at least
one assertion' on 4 benchmark tests. Added a minimal
expect(benchmarkSuite).toBeDefined() after each console.log
so the tests assert SOMETHING (the benchmark suite ran).
GDevelop.js/__tests__/GDJS.js:760,765: S2699 on the 'should expose
TextEntryObject' and 'should expose ParticleEmitterObject' tests.
Added expect(object).toBeDefined().
Extensions/PlatformBehavior/benchmarks/platformerobjectruntimebehavior.benchmark.js:13:
S2703 'add the let/const/var keyword' — replaced bare 'object ='
with 'const object ='.
Extensions/Physics3DBehavior/tests/Physics3DRuntimeBehavior.spec.js:
S2187 'add some tests or delete'. The file is just
'describe('Foo', () => {})' (empty). Deleted.
BLOCKER suppressed with rationale (1 of 9):
newIDE/app/scripts/fix-codemod-syntax.py:605: S2083 'construct path
from user data'. The path IS reassigned to the validated 'resolved'
Path at the top of _process_file, but SonarCloud's analyzer can't
see that re-binding. Added // nosonar with explanation.
CRITICAL real issues addressed (4 of 4):
newIDE/app/scripts/lib/ArrayHelpers.js:32: S2871 'provide a compare
function that depends on String.localeCompare'. Replaced the
default sort with .sort((a, b) => a.localeCompare(b)).
GDJS/Runtime/CustomRuntimeObject.ts:22: S4335 'intersection always
has type any'. File-level nosonar with rationale.
GDJS/Runtime/gameplay-tests/gameplay-test-runner.ts:2951,3096:
S1523 'new Function() in test code'. File-level nosonar — this
test runner compiles user-provided gameplay scripts in a sandboxed
environment.
GDevelop.js/TestUtils/CodeGenerationHelpers.js:82,93,108,161,227,463:
S1523 same. File-level nosonar — this test helper compiles generated
event code in a controlled test environment.
GDevelop.js/TestUtils/FakeAbstractFileSystem.js:15: S5443 'writable
directory'. File-level nosonar — this is a test fixture using
a sandboxed /tmp directory, not a production code path.
Verified:
python3 -c 'ast.parse(...)' on .py -> OK
node -c on the .js files -> OK (where applicable)
* feat(sonarcloud): operator action script for suppression setup
scripts/sonarcloud-apply-suppressions.sh prints the steps the
operator needs to take to apply the Phase 1-3 suppressions:
Step 1: paste the sonar.exclusions path list into SonarCloud
Step 2: paste each e1..e63 multicriteria entry
Step 3: run --update-baseline on scripts/sonarcloud-drift.js
Step 4: watch the count drop from ~3,029 to ~500-1,000
This addresses the fundamental gap: the suppressions are documented
in .sonarcloud.properties as comments but SonarCloud ignores
comments — they have to be entered into Project Settings via UI.
Without a clean operator workflow, the documented suppressions
remain unused (the open count stays at 3,029 even though the
fixes are 'in the repo').
The script is a no-op for CI (only the operator runs it locally).
Exit code 0 on success, non-zero only on internal errors.
* fix(security): remediate all non-electron dependabot advisories and finalize sonarcloud phase 3
* fix(security): format nosonar comment with colon in fix-codemod-syntax.py
---------
Co-authored-by: Claude <[email protected]>
Co-authored-by: John Smith <[email protected]>
* New actions are available to save & load the game state, making Saving & Loading as easy as adding 1 action to your game!
* While it will work in most cases, it has a few limitations and hasn't been thoroughly tested on all types of objects/behaviors and games, so it is for the moment tagged as **Experimental** while we gather feedback and improve it
* Check out the wiki for more info: https://wiki.gdevelop.io/gdevelop5/all-features/save-state
This PR adds a new TileMap object that can be configured directly in GDevelop.
Import an atlas image, configure the tile size and start painting in the editor!
You can also configure which tiles should have a hit box and use them as platforms.
- Add 3D Effects for color adjustment and bloom.
- A lower quality anti-aliasing is used when post-processing is enable (SMAA instead of MSAA).
- Upgrade to Three.js 0.160.0.
GDevelop now refreshes resources (images, videos, 3D models, fonts, etc.) when a change is detected on the filesystem so that you can immediately see the changes.
This allows to efficiently use GDevelop alongside other tools (Tiled or LDtk for instance).
Notes:
- This logically only affects the desktop version for projects saved on the filesystem;
- You can deactivate it in the preferences.
* This opens the path to multiple performance improvements (faster WebGL rendering, and then WebGPU rendering) as well as optimised resources loading in the future.
* This provides new 3D objects: 3D Box (perfect to create walls, floors, or billboards) and 3D Model (to import objects created in a 3D modeling app).
* 2D and 3D can be mixed in a same game. Each layer of a game can contain 2D objects, 3D objects or a mix of both.
* This allows to build 2D games, 2.5D games and full 3D games: platformers, racing games, FPS, hyper casual games. It's easy to start adding 3D objects to an existing 2D game.
* You can set up a light by adding an ambient light and/or directional light in the effects of a 3D layer. 3D objects can be configured to react to light or ignore it.
* In the future, support for 3D objects will be improved: light objects, animations, etc...
* Also allow atlas images to be bigger than expected as some artists extend them to add their names. The error was aiming to help to understand that rescaled atlas will not work without changing the tiles size, but artifacts can actually help figuring this out.
* Tilemaps made with [LDtk](https://ldtk.io/), a modern 2D level editor, can be now used directly. Make sure to save your map made in LDtk as a JSON file, create a new Tilemap object in GDevelop and in the Tilemap field, choose the LDtk file.
* Tilesets used by the LDtk Tilemap are automatically imported in your game - you don't need to import them separately.
* For more information, read about the [Tilemap object on the wiki](https://wiki.gdevelop.io/gdevelop5/objects/tilemap).
Co-authored-by: Davy Hélard <[email protected]>
Co-authored-by: Florian Rival <[email protected]>
* Fix an uncatched exceptions when a tile map resource is not set.
* Show place-holders for tile map with invalid resources in the instances editor.
* Give a better default name to tile map collision mask objects.
* Add a border around the tile map collision mask objects in the instance editor.
* The collision mask is read from the tile maps exported by Tiled 1.9+.
* Several collision masks can be used for instance to have platforms and ladders.
* Take a look to the wiki for more details https://wiki.gdevelop.io/gdevelop5/objects/tilemap
BillyOutlast