boboko/3dealer
3
0
Fork 0
generated from boboko/starter
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Hotfix: Updatin build, fixing vite error, creating separate entrypoints

Browse Source
This commit is contained in:
Konstantinos Arvanitakis
2026-07-10 12:54:48 +03:00
parent a2caa43bc9
commit 5ecad634e2
7 changed files with 93 additions and 58 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docker/entrypoint.sh
+31 -23
View File
@@ -1,39 +1,47 @@
#!/bin/sh
set -e
# In development, install Composer deps if vendor is not present
if [ "$APP_ENV" != "production" ] && [ ! -f vendor/autoload.php ]; then
# Only the app container runs setup; queue/scheduler use entrypoint-worker.sh instead
# and just wait on the migrated marker this script writes below.
if [ "$APP_ENV" != "production" ]; then
echo "[entrypoint] Installing Composer dependencies..."
git config --global --add safe.directory /var/www/html 2>/dev/null || true
composer install --no-interaction --prefer-dist
fi
# In development, re-resolve all boboko/* packages against their local path-repo
# checkouts on every boot, so editing boboko-core and running `./bin/dc-core.sh up`
# is enough. No-op unless the path repo in `_repositories` has been enabled.
if [ "$APP_ENV" != "production" ] && [ -d /var/www/boboko-core ]; then
echo "[entrypoint] Re-resolving boboko/* packages from local path repos..."
# Re-resolve boboko/* on every boot, whether it's a local path-repo checkout
# (../boboko-core mounted via docker-compose.core-dev.yml) or a VCS tag. Rewrites
# composer.lock, which is committed so prod picks up the resolved version via
# `composer install` alone.
echo "[entrypoint] Re-resolving boboko/* packages..."
composer update "boboko/*" --no-interaction --with-all-dependencies
fi
# In development, the app dir is bind-mounted from a fresh checkout, so package
# assets (which the Dockerfile publishes at build time in production) need to be
# generated here instead. Cheap and idempotent, safe to repeat on every boot.
if [ "$APP_ENV" != "production" ]; then
php artisan vendor:publish --tag=core-assets --force --ansi --quiet
php artisan vendor:publish --tag=public --force --ansi --quiet
php artisan filament:assets --ansi --quiet
fi
# Everything below runs on every boot of app/queue/scheduler, possibly concurrently,
# so it must be idempotent and safe to run from multiple containers at once.
# Migrations, package publishing, and config/route/view caching are deploy-time
# concerns handled once via Envoy, not here.
mkdir -p storage/app/public storage/framework/cache storage/framework/sessions storage/framework/views storage/logs bootstrap/cache
mkdir -p storage/app/public storage/framework/cache storage/framework/sessions storage/framework/views storage/logs storage/framework bootstrap/cache
chown -R www-data:www-data storage bootstrap/cache
chmod -R 775 storage bootstrap/cache
php artisan storage:link --quiet 2>/dev/null || true
if [ "$APP_ENV" != "production" ]; then
# The app dir is bind-mounted from a fresh checkout, so package assets (which the
# Dockerfile publishes at build time in production) need to be generated here
# instead. Cheap and idempotent, safe to repeat on every boot.
php artisan vendor:publish --tag=core-assets --force --ansi --quiet
php artisan vendor:publish --tag=public --force --ansi --quiet
php artisan filament:assets --ansi --quiet
echo "[entrypoint] Running migrations..."
rm -f storage/framework/migrated
php artisan migrate --force
touch storage/framework/migrated
# boboko/core overrides lunar:install to skip the interactive prompts (migrate
# confirm, admin creation, GitHub star) and just seed the idempotent store
# defaults: countries, channel, language, currency, tax zone, attributes,
# product type. queue/scheduler wait on the marker above rather than running
# this themselves, since the country import's check-then-insert isn't safe to
# run concurrently.
php artisan lunar:install --quiet || true
fi
exec "$@"