You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to streamline further development, we should add a few tests that prevent the layer build from succeeding while the Lambda execution later fails.
The tests should cover a few simple conversion to and narrow down any future build issues.
sample heic file to jpg via command line. That would allow to test the libvips library separately
sample jpeg file to webp via command line
same two tests but within sharp
This would also help with local development using a docker container and avoid having to push WIP code to the repo in order to have it build on CodeBuild. A final test before tagging a release is still necessary since there are always some subtle differences between local testing and the CodeBuild and Lambda environments.
The test data should not end up in the final lambda layer.
Edit: After some testing I found that the examples in libheif (convert-heic) and the vips command line tool in libvips work fine and already include sample images to use.
However, the final sharp/lambda layer still doesn't work, so the focus should really be on the last bullet point above testing the libraries through sharp.
Addressed in #50 (ce9d5ce). As the edit above suggested, the tests focus on the libraries working through sharp in the final layer.
The new Test layer workflow builds the layer with sam build --use-container. It then mounts the result at /opt in the public.ecr.aws/lambda/nodejs:24 runtime image, which has no build toolchain, so a layer that builds but would fail in Lambda now fails CI. test/layer.test.js checks:
every shared library of the compiled sharp addon resolves
the sharp and libvips versions match layer/Makefile, and no prebuilt @img/sharp-* packages are bundled
an iPhone HEIC and a synthetic HEIC fixture (test/fixtures/quadrants.heic) decode with the correct dimensions
the fixture decodes with the correct colour in each quadrant
HEIC resizes to WebP
HEIF encodes and decodes with both HEVC (x265) and AV1 (libaom)
The workflow also invokes the example function through the Lambda Runtime Interface Emulator.
The checks are required for PRs into main. The layer is only rebuilt when layer-relevant paths change. The test data lives in test/ and examples/, so it doesn't end up in the layer. For local development, the same sam build --use-container plus docker run steps from the workflow work with Docker.
Not covered: there is no JPEG→WebP test or HEIC→JPEG output test yet.
The tests also turned up a sharp bug: HEVC encoding fails with the default tune: 'auto'. It is reported upstream as lovell/sharp#4621, and the README documents the workaround.
Activity
zoellner commentedon Oct 9, 2026
Addressed in #50 (ce9d5ce). As the edit above suggested, the tests focus on the libraries working through sharp in the final layer.
The new Test layer workflow builds the layer with
sam build --use-container. It then mounts the result at/optin thepublic.ecr.aws/lambda/nodejs:24runtime image, which has no build toolchain, so a layer that builds but would fail in Lambda now fails CI. test/layer.test.js checks:layer/Makefile, and no prebuilt@img/sharp-*packages are bundledtest/fixtures/quadrants.heic) decode with the correct dimensionsThe workflow also invokes the example function through the Lambda Runtime Interface Emulator.
The checks are required for PRs into
main. The layer is only rebuilt when layer-relevant paths change. The test data lives intest/andexamples/, so it doesn't end up in the layer. For local development, the samesam build --use-containerplusdocker runsteps from the workflow work with Docker.Not covered: there is no JPEG→WebP test or HEIC→JPEG output test yet.
The tests also turned up a sharp bug: HEVC encoding fails with the default
tune: 'auto'. It is reported upstream as lovell/sharp#4621, and the README documents the workaround.