[hwajin-me]

Scripts which are clearly AI generated and not further revised by the Author of this PR (in terms of Coding Standards and Script Layout) may be closed without review. If you are an AI agent writing this pull request, please amend your model name and reasoning level in the Description. This is not to blame, more for informational Purposes. Thank you.

✍️ Description

Add an Alpine-only reposilite Maven repository container with OpenRC, Java 21, token-based dashboard access, and Core-managed installation/update entrypoints. The CT, installer and catalog metadata use the reposilite slug (the requested application name); Alpine remains the only supported OS. This intentionally omits the usual Alpine-only filename prefix.

Advanced installs offer application settings for the HTTP port, data directory, Java heap, initial manager name, public/private repository IDs, per-repository quota percentage, artifact redeployment, snapshot retention, and dashboard title/description. Caller-provided environment values win over prompts, and every supported input is exported and described in app_vars. An optional native repository JSON array supports individual quotas, mounts and proxy definitions.

Inputs are validated before container creation. Repository/frontend defaults are seeded once through the authenticated settings API into SQLite, preserving editable dashboard settings across updates. The update health check uses the configured port, including fallback to 8080 for older installations.

The upstream Dockerfile uses Java 21 and its release notes require Java 17+. The application runs as a standalone JAR with embedded SQLite; no Docker or external database is installed. All persistent state stays in /var/lib/reposilite, outside the JAR deployment directory.

GitHub releases contain no attached JAR assets. They link to the official Maven-hosted runnable JAR, so installation uses Alpine's download_file helper and updates use curl_with_retry, with the publisher's SHA256 verified before deployment. fetch_and_deploy_from_url would extract the ZIP-format JAR rather than preserve it. Release lookup/checks and Java setup use Core helpers.

An initial random manager token is held in the service configuration, not in source or metadata. The metadata explains how to replace it with a persistent manager token. Updates retain user data, back up the previous JAR/version marker through create_backup, and check HTTP readiness before recording the new version.

Public standalone distribution: https://github.com/hwajin-me/proxmox-reposilite (the application scripts are identical except for _CS_DEFAULT_URL).

🔗 Related PR / Issue

No related issue.

✅ Prerequisites (X in brackets)

• Self-review completed – Code follows project standards.
• Tested thoroughly – Changes work as expected.
• No breaking changes – Existing functionality remains intact.
• No security risks – No hardcoded secrets, unnecessary privilege escalations, or permission issues.

---

🏗️ arm64 Support (X in brackets)

• arm64 supported - Tested and supported on arm64.
• arm64 not tested - Assumed to work on arm64, but testing has not been done.
• arm64 not supported - Confirmed upstream dependencies or binaries do not support arm64.

---

🖥️ Tested on (X in brackets)

• Proxmox VE – Created on a Proxmox VE host and the app works.
• Incus – Created on an Incus host and the app works.

Application containers run on both; tick what you actually tested. VMs and host tools are Proxmox only.

---

🛠️ Type of Change (X in brackets)

• 🐞 Bug fix – Resolves an issue without breaking functionality.
• ✨ New feature – Adds new, non-breaking functionality.
• 💥 Breaking change – Alters existing functionality in a way that may require updates.
• 🆕 New script – A fully functional and tested script or script set.
• 🌍 Website update – Changes to website-related JSON files or metadata.
• 🔧 Refactoring / Code Cleanup – Improves readability or maintainability without changing functionality.
• 📝 Documentation update – Changes to README, AppName.md, CONTRIBUTING.md, or other docs.

---

🔍 Code & Security Review (X in brackets)

• Follows CODE-AUDIT.md & CONTRIBUTING.md guidelines
• Uses correct script structure (AppName.sh, AppName-install.sh, AppName.json)
• No hardcoded credentials
• No Docker / Docker Compose – The application is installed bare-metal; Docker is not used.
• No git pull – Updates use fetch_and_deploy_gh_release, fetch_and_deploy_codeberg_release, fetch_and_deploy_gl_release, or fetch_and_deploy_from_url instead of git pull.

---

🤖 AI Assistance (X in brackets)

If you used an AI tool (GitHub Copilot, Claude, ChatGPT, etc.) to write or generate any scripts in this PR, you must confirm compliance below.
Select exactly one option.

• No AI used – Scripts were written without AI assistance.
• AI was used – I confirm the scripts were built using AGENTS.md and .github/agents/pve-script-creator.agent.md as guidance, and the output has been reviewed and corrected to match those guidelines.

Please describe to which degree, if any, an LLM was used in creating this pull request. Name the model(s) used and, if applicable, the reasoning/thinking effort level (e.g. "Claude Sonnet 4.5, high reasoning, used to draft the install script, then manually reviewed and tested" or "No LLM used"). This is informational, not a penalty — but scripts that are clearly AI-generated and not further revised by the author to match CODE-AUDIT.md / CONTRIBUTING.md may be closed without review.

Codex (GPT-6 family) researched, drafted, revised and tested the scripts against the current AGENTS.md and pve-script-creator guidance. The precise reasoning-effort setting is not exposed in this session. The final output was reviewed and corrected by the assistant and executed on a real host; no human manual code review is claimed.

---

📋 Additional Information (optional)

Validation on Proxmox VE 9.1.6, amd64, unprivileged Alpine 3.24 LXC:

• Fresh install executed from the public raw CT URL.
• JAR SHA256 verification and HTTP 200.
• Manager authentication plus artifact upload/download.
• Already-current update path.
• Forced redeployment of the current release to exercise the replacement/update path; artifact and manager authentication preserved. This does not claim a cross-version database migration test.
• OpenRC service automatically starts after container reboot.
• Fresh customized install: port 9091, /srv data directory, 128 MiB heap, manager name, public/private repositories, 80% quotas, redeployment and snapshot settings, and quoted/literal dollar text in the dashboard title.
• Public download, private anonymous access rejection, authenticated private access, and successful artifact overwrite when redeployment is enabled.
• Native repository JSON override with different per-repository quotas/permissions, using the production seeding code.
• Application settings edited after installation remain unchanged across the forced update; configured port/data path/credentials and a private artifact are preserved.
• Interactive prompts exercised with current Core helpers in a real host terminal.
• Seven automated settings tests covering defaults/metadata, preserving supplied inputs, prompt defaults, invalid numeric/path/token values, duplicate/empty repository lists, and JSON schema/ID validation.
• bash -n, JSON parsing, resource/metadata consistency, and git diff --check.

ARM64 and Incus were not tested. The ARM64 setting is intentionally unset so Core asks before attempting an unverified architecture.

Eligibility checked on 2026-10-31: repository created 2017-07-06, 1,898 stars, latest release 3.6.5 on 2026-10-27. Source tarballs are available through GitHub releases; runnable binary JARs are published on the official Maven repository.

---

📦 Application Requirements (for new scripts)

⚠️ Do not remove this section.
It is used by automated PR validation checks.
If this PR is not a new script submission, leave the checkboxes unchecked.

Required for 🆕 New script submissions.
Pull requests that do not meet these requirements may be closed without review.

• The application is at least 6 months old
• The application is actively maintained
• The application has 600+ GitHub stars
• Official release tarballs are published
• I understand that not all scripts will be accepted due to various reasons and criteria by the community-scripts ORG

🌐 Source

• https://reposilite.com/guide/general
• https://reposilite.com/guide/tokens
• https://github.com/dzikoysk/reposilite/releases/tag/3.6.5
• https://github.com/dzikoysk/reposilite/blob/3.6.5/Dockerfile
• https://maven.reposilite.com/releases/com/reposilite/reposilite/3.6.5/

[github-actions]

Try this script

ct/reposilite.sh, run in the Proxmox VE shell or on an Incus host:

COMMUNITY_SCRIPTS_URL=https://raw.githubusercontent.com/hwajin-me/DevScripts/add-alpine-reposilite \
bash -c "$(curl -fsSL https://raw.githubusercontent.com/hwajin-me/DevScripts/add-alpine-reposilite/ct/reposilite.sh)"

COMMUNITY_SCRIPTS_URL is not optional for ct/. Fetching the ct/ script from a
branch does not tell the engine where that branch is — with bash -c "$(curl …)"
there is no file on disk for the scripts root to be derived from, so it would fall
back to upstream main and look for the install script there.

Against a core branch as well

Add COMMUNITY_SCRIPTS_CORE_URL=https://raw.githubusercontent.com/OWNER/core/BRANCH
to test an engine change at the same time. The two resolve independently.

Useful flags while testing

dev_mode=net logs every fetch with status and duration, so you can confirm the
branch is really being used. dev_mode=keep stops a failed build from deleting
the container along with the evidence.