Conversation
…and React Bricks CMS Co-authored-by: nexusct <19503275+nexusct@users.noreply.github.com> Agent-Logs-Url: https://github.com/nexusct/1Panel/sessions/1b017fed-a2d6-4ac9-b287-80226f2549de
|
Kilo Code Review could not run — your account is out of credits. Add credits at app.kilo.ai to enable reviews on this change. |
There was a problem hiding this comment.
Pull request overview
Adds new CI-side installer scripts to bootstrap several third-party platforms/CLIs (Odoo, Shopify CLI, Contentful CLI, Strapi, React Bricks) and updates the existing CI helper script to mark these installers as executable.
Changes:
- Added standalone
ci/install_*.shscripts for Odoo, Shopify CLI, Contentful CLI, Strapi, and React Bricks scaffolding/installation. - Updated
ci/script.shtochmod +xthe new installer scripts when present.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 9 comments.
Show a summary per file
| File | Description |
|---|---|
ci/script.sh |
Adds a loop to mark installer scripts executable. |
ci/install_odoo.sh |
New Odoo installer supporting Docker (default) and native package install. |
ci/install_shopify.sh |
New installer for Shopify CLI via global npm install. |
ci/install_contentful.sh |
New installer for Contentful CLI via global npm install. |
ci/install_strapi.sh |
New script to scaffold a Strapi project via npx create-strapi. |
ci/install_react_bricks.sh |
New script to scaffold a React Bricks project via npx create-reactbricks-app. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| check_node() { | ||
| if ! command -v node >/dev/null 2>&1; then | ||
| log_err "Node.js is required but not found. Please install Node.js LTS first." | ||
| return 1 | ||
| fi | ||
| log_ok "Node.js $(node --version) detected." | ||
| } |
There was a problem hiding this comment.
check_node verifies node exists, but the script later calls npm install -g ... without checking that npm is available. In some environments Node may be present without npm/npx, which would make the install fail with a less clear error. Consider explicitly checking command -v npm (and failing with a helpful message) before running the install.
| for installer in \ | ||
| install_ai_tools.sh \ | ||
| install_odoo.sh \ | ||
| install_shopify.sh \ | ||
| install_contentful.sh \ | ||
| install_strapi.sh \ | ||
| install_react_bricks.sh; do |
There was a problem hiding this comment.
ci/script.sh is attempting to chmod install_ai_tools.sh, but that file does not exist anywhere in ci/ on this branch. This makes the installer list misleading; either add the missing script or remove it from the loop to keep the CI script self-consistent.
| dnf install -y odoo | ||
| systemctl enable odoo | ||
| systemctl start odoo | ||
| elif command -v yum >/dev/null 2>&1; then |
There was a problem hiding this comment.
The yum-config-manager command usually requires yum-utils to be installed; otherwise this repo-add step will fail on some systems. Consider ensuring the dependency is installed (or using an alternative method to add the repo) before invoking yum-config-manager.
| elif command -v yum >/dev/null 2>&1; then | |
| elif command -v yum >/dev/null 2>&1; then | |
| if ! command -v yum-config-manager >/dev/null 2>&1; then | |
| yum install -y yum-utils | |
| fi |
| if npx create-reactbricks-app@latest "${REACTBRICKS_PROJECT_NAME}"; then | ||
| log_ok "React Bricks project '${REACTBRICKS_PROJECT_NAME}' created at ${TARGET_DIR}." |
There was a problem hiding this comment.
npx create-reactbricks-app@latest is not reproducible and may change behavior over time, which is risky for CI automation. Consider supporting a pinned version via an env var (and defaulting to a known-good version) so installs remain stable.
|
|
||
| log_ok "Odoo ${ODOO_VERSION} installed and running." | ||
| log_info " Access Odoo at: http://localhost:${ODOO_PORT}" | ||
| log_info " DB User: odoo | DB Password: ${DB_PASSWORD}" |
There was a problem hiding this comment.
The script logs the generated database password to stdout. In CI (or any environment where logs are retained/centralized) this can leak credentials. Consider omitting the password from logs (or only printing it when an explicit SHOW_CREDENTIALS=1 flag is set) and relying on the restricted credentials file instead.
| log_info " DB User: odoo | DB Password: ${DB_PASSWORD}" | |
| if [ "${SHOW_CREDENTIALS:-0}" = "1" ]; then | |
| log_info " DB User: odoo | DB Password: ${DB_PASSWORD}" | |
| else | |
| log_info " DB User: odoo | DB Password: [hidden] (set SHOW_CREDENTIALS=1 to display)" | |
| fi |
| ODOO_VERSION="${ODOO_VERSION:-17}" | ||
| ODOO_PORT="${ODOO_PORT:-8069}" | ||
| DB_PASSWORD="${ODOO_DB_PASSWORD:-$(tr -dc A-Za-z0-9 </dev/urandom | head -c 16)}" | ||
| INSTALL_DIR="${ODOO_INSTALL_DIR:-/opt/odoo}" |
There was a problem hiding this comment.
DB_PASSWORD defaults to a new random value each run. If odoo-db already exists (and you reuse it later in the script), rerunning this installer can start a new odoo container with a different PASSWORD than the existing Postgres container expects, causing connection failures. To make reruns idempotent, load the password from the persisted credentials file when it exists (or require ODOO_DB_PASSWORD when reusing an existing DB container).
| systemctl start odoo | ||
| elif command -v dnf >/dev/null 2>&1; then | ||
| # Fedora/RHEL/CentOS | ||
| dnf config-manager --add-repo="https://nightly.odoo.com/${ODOO_VERSION}.0/nightly/rpm/odoo.repo" |
There was a problem hiding this comment.
The dnf config-manager command typically comes from dnf-plugins-core; on minimal Fedora/RHEL images it may not be installed, causing this branch to fail. Consider installing the required plugin package (or detecting missing dnf config-manager and falling back to writing the repo file directly) before calling it.
| dnf config-manager --add-repo="https://nightly.odoo.com/${ODOO_VERSION}.0/nightly/rpm/odoo.repo" | |
| if dnf config-manager --help >/dev/null 2>&1; then | |
| dnf config-manager --add-repo="https://nightly.odoo.com/${ODOO_VERSION}.0/nightly/rpm/odoo.repo" | |
| else | |
| cat >/etc/yum.repos.d/odoo.repo <<EOF | |
| [odoo] | |
| name=Odoo Nightly ${ODOO_VERSION}.0 | |
| baseurl=https://nightly.odoo.com/${ODOO_VERSION}.0/nightly/rpm/ | |
| enabled=1 | |
| gpgcheck=0 | |
| EOF | |
| fi |
| log_info "Installing Shopify CLI..." | ||
|
|
||
| if command -v shopify >/dev/null 2>&1; then | ||
| log_warn "Shopify CLI already installed ($(shopify version 2>/dev/null || echo 'unknown')). Skipping." | ||
| return 0 | ||
| fi | ||
|
|
||
| if npm install -g @shopify/cli@latest; then | ||
| log_ok "Shopify CLI installed successfully." | ||
| log_info " Run 'shopify' to get started." | ||
| log_info " Docs: https://shopify.dev/docs/api/shopify-cli" | ||
| log_info " GitHub: https://github.com/Shopify/cli" | ||
| else | ||
| log_err "Failed to install Shopify CLI." |
There was a problem hiding this comment.
This installs @shopify/cli@latest, which makes CI runs non-reproducible and increases supply-chain risk (a new upstream release can change behavior or break builds). Consider allowing a pinned version via an environment variable (e.g., SHOPIFY_CLI_VERSION) and defaulting to a known-good version instead of latest.
| log_info "Installing Shopify CLI..." | |
| if command -v shopify >/dev/null 2>&1; then | |
| log_warn "Shopify CLI already installed ($(shopify version 2>/dev/null || echo 'unknown')). Skipping." | |
| return 0 | |
| fi | |
| if npm install -g @shopify/cli@latest; then | |
| log_ok "Shopify CLI installed successfully." | |
| log_info " Run 'shopify' to get started." | |
| log_info " Docs: https://shopify.dev/docs/api/shopify-cli" | |
| log_info " GitHub: https://github.com/Shopify/cli" | |
| else | |
| log_err "Failed to install Shopify CLI." | |
| # Allow overriding the CLI version via SHOPIFY_CLI_VERSION; default to a pinned known-good version. | |
| CLI_VERSION="${SHOPIFY_CLI_VERSION:-"3.69.0"}" | |
| log_info "Installing Shopify CLI (version ${CLI_VERSION})..." | |
| if command -v shopify >/dev/null 2>&1; then | |
| log_warn "Shopify CLI already installed ($(shopify version 2>/dev/null || echo 'unknown')). Skipping." | |
| return 0 | |
| fi | |
| if npm install -g "@shopify/cli@${CLI_VERSION}"; then | |
| log_ok "Shopify CLI installed successfully (version ${CLI_VERSION})." | |
| log_info " Run 'shopify' to get started." | |
| log_info " Docs: https://shopify.dev/docs/api/shopify-cli" | |
| log_info " GitHub: https://github.com/Shopify/cli" | |
| else | |
| log_err "Failed to install Shopify CLI (version ${CLI_VERSION})." |
| # Use --quickstart for SQLite (no extra DB setup needed) | ||
| if npx create-strapi@latest "${STRAPI_PROJECT_NAME}" --quickstart --no-run; then | ||
| log_ok "Strapi project '${STRAPI_PROJECT_NAME}' created at ${TARGET_DIR}." |
There was a problem hiding this comment.
Using npx create-strapi@latest makes scaffolding non-deterministic across runs and can unexpectedly break CI when upstream releases change prompts/defaults. Consider parameterizing the version (e.g., STRAPI_CREATE_VERSION) and defaulting to a pinned version for repeatable installs.
ci/install_odoo.sh(Docker-based default, deb/rpm fallback; Docker network instead of deprecated --link; credentials persisted to file)ci/install_shopify.sh(npm install -g @shopify/cli@latest)ci/install_contentful.sh(npm install -g contentful-cli)ci/install_strapi.sh(npx create-strapi@latest with --quickstart)ci/install_react_bricks.sh(npx create-reactbricks-app@latest)ci/script.shto chmod +x all installer scriptsOriginal prompt
Overview
Add individual installation scripts for 5 applications/platforms to the
ci/directory of the repository:@shopify/clivia npm)contentful-clivia npm)npx create-strapi@latest)npx create-reactbricks-app@latest)Also update
ci/script.shto make all new installer scripts executable.Files to Create
ci/install_odoo.shOdoo is best installed via Docker (official Docker image) or via the official Odoo nightly packages. This script should support both paths, defaulting to Docker.