Option to skip Iconify icon cache warmup in production builds

[jvancoillie]

Referencing #2493

I can no longer disable Iconify because I need it enabled in production.
This causes asset-map:compile to fail during builds due to the icon cache warmup step.

It would be very useful to have an option to skip the warmup, allowing production builds to succeed without internet access.

#18 [php_apache_prod 7/7] RUN php bin/console asset-map:compile
#18 0.297 Warming the icon cache...
#18 0.359 
#18 0.360 In ErrorChunk.php line 73:
#18 0.360                                                                                
#18 0.360   Received HTTP code 403 from proxy after CONNECT for "https://api.iconify.de/  
#18 0.360   sign/collections".                                                           
#18 0.360                                                                                
#18 0.360 
#18 0.361 In CurlResponse.php line 336:
#18 0.361                                                                                
#18 0.361   Received HTTP code 403 from proxy after CONNECT for "https://api.iconify.de/  
#18 0.361   sign/collections".                                                           
#18 0.361                                                                                
#18 0.361 
#18 0.361 asset-map:compile
#18 0.361 
#18 ERROR: process "/bin/sh -c php bin/console asset-map:compile" did not complete successfully: exit code: 1

[smnandre]

Not sure to follow here: you want no cache warm but after you would like iconify to be enabled ?

I’d say you may play with some env/config var probably to disable iconify before warm up only.

Elsewhen how would you see this: an option to disable cache warm ?

Genuinely curious here, AssetMapper does not need internet during your build? I imagine you install deps before.. maybe the same thing could be done for the Icons then ?

Or… you also can warm your cache sooner and ignore icons not found ?

[jvancoillie]

Hi @smnandre 👋

You’re right that it looks strange: we allow external access for AssetMapper/Composer dependencies but not for Iconify.
Unfortunately, this is a limitation of our company GitLab environment where outbound calls are heavily restricted.
So the situation is a bit inconsistent on our side.

I understand my request may look odd.

I actually tried working around this by controlling Iconify with an env variable, for example:

iconify:
  enabled: '%env(bool:ICONIFY_ENABLED)%'

The idea would be to have it default to false in the .env and activate it only at deploy time.
However, the problem is that using %env(bool:ICONIFY_ENABLE)% does not work as expected:
Symfony only resolves environment variables when they are actually injected into a service or used in the container configuration.
In the current implementation, the iconify.enabled value is never directly used during the container compilation
(see: https://github.com/symfony/ux/blob/2.x/src/Icons/src/DependencyInjection/UXIconsExtension.php#L176), so Symfony cannot resolve it at build time.

Also, I don’t actually need to warm up icons at image build time in our CI because the icons used are already locked.
However, we do have a feature that allows adding new icons from the back office, which means some icons are not known in advance.

It would be really useful if the iconify.enabled configuration could be fully resolved during compile time.
This would allow us to control Iconify via an environment variable (e.g., disabled during CI builds) without needing a separate option to skip the icon cache warmup, while keeping Iconify fully enabled in production.

[smnandre]

Ho so you never need the warmup ? And skipping it would be enough to solve all problems ?

[jvancoillie]

I can’t say I never need the warmup, but here’s the current behavior:

• With iconify.enabled: true, asset-map:compile triggers Iconify API calls - 403 errors in CI.
• With iconify.enabled: false, warmup runs without API calls - build succeeds.

Goal: Keep Iconify fully enabled in production, but skip API calls during CI builds.

Currently, using %env(bool:ICONIFY_ENABLED)% isn’t possible because iconify.enabled is only read at runtime, so the env var is considered unused at container compile time

Current workaround (works fine):

# Removed from CI Docker build
# RUN php bin/console asset-map:compile

# Run at container startup instead (entrypoint)
php bin/console asset-map:compile

I think that if it were possible to control the iconify.enabled configuration via an environment variable, it might solve my problem. What do you think?

[smnandre]

skip API calls during CI builds.

API Calls beeing only the cache warmer right ?

I think that if it were possible to control the iconify.enabled configuration via an environment variable

Did you try the following ?

In your existing (or new) config/packages/ux_icons.yaml

parameters:
    env(APP_ICONIFY): true

ux_icons:
    iconify:
        enabled: '%env(bool:resolve:default::APP_ICONIFY)%'

 APP_ICONIFY=1 sf debug:config ux_icons --resolve-env

[smnandre]

Been playing a bit and ... it's the fact this warmer is called inconditionnaly when AssetMapper compile ... I think the easiest and cleanest way here could simply to give you a way to "not" register the cache warmer as an AssetMapper listener.

Or maybe even simply catch there the exceptions ?

in WarmIconCacheOnAssetCompileListener.php

[jvancoillie]

I tried what you suggested:

APP_ICONIFY=1 bin/console debug:config ux_icons --resolve-env

In PhpDumper.php line 403:
                                                                                                                
  Environment variables "bool:resolve:default::APP_ICONIFY" are never used. Please, check your container's con  
  figuration.                                                                                                         

Regarding WarmIconCacheOnAssetCompileListener, I agree that disabling the listener could be a useful option.
Alternatively, catching exceptions in the listener could also help avoid build failures, unless this has been addressed in a more recent version. This would also cover cases like those already reported in #2493, where the warmup attempts incoherent HTTP calls to "cache" items that are not real icons.