What to Do When a CasaOS or ZimaOS App Store Submission Is Still Pending

Key conclusion: a green CI pipeline proves that the automated checks passed; it does not mean an App Store pull request has been approved. If a CasaOS/ZimaOS app submission has been open for months, stop rechecking the same badges and determine which layer is still pending: repository validation, reviewer feedback, merge requirements, or maintainer review.

The real-world example behind this page was unusually well prepared: the app had been migrated to the v2 format, checks were green, Docker tags were pinned, metadata was filled in, and the contributor was asking one simple question—“Is there anything blocking the merge, or any changes needed from my side?”

First verify the checks that actually matter to the current App Store repository

The current App Store contribution flow asks contributors to fork the repository, make and test changes, then open a pull request explaining what changed and how it was validated.

For local validation, the repository specifically asks contributors to run:

./scripts/build_dist.sh

A healthy result is more specific than “my compose file looks fine.” The build should complete without errors, produce dist/index.json, and generate the changed app under dist/apps/<app-id>/.

The repository's App Store CI checks run compose validation and a full v2 build check on pull requests. Invalid YAML, missing required app metadata, missing referenced assets, or architecture mismatches can fail the build.

Green CI is necessary, but it is not the merge decision

This is the point many contributors miss. A successful automated check only reports that the commit met the conditions tested by that check. GitHub status checks are separate from review and merge decisions.

A pull request can still remain open because it needs:

• a maintainer or code-owner review;
• requested changes to be addressed;
• the branch to be brought up to date;
• a merge conflict to be resolved;
• repository-specific acceptance or curation decisions that CI cannot make.

GitHub merge requirements treat reviews, status checks, and branch rules as separate merge conditions.

Use the PR itself to identify the blocker

Before posting another “any update?” comment, check four places:

1. Checks: confirm the latest commit—not an older SHA—has passed the required workflows.
2. Conversation: look for unresolved maintainer comments or requests for changes.
3. Files changed: confirm your v2 migration did not leave legacy metadata in the wrong location.
4. Merge box: GitHub normally tells you whether a review, status check, conflict resolution, or branch update is still required.

If CI is green and the merge box shows no contributor-fixable blocker, the remaining step is likely human review rather than another code change.

For v2 submissions, validate the source contract—not just the Docker container

A working container is not automatically a valid App Store entry. The current v2 protocol expects the source app definition to contain standard Docker Compose runtime configuration plus a top-level x-casaos metadata block. The x-casaos metadata schema defines fields such as id, main, index, port_map, icon, title, category, architecture, and version metadata.

So when a submission says “CI passed,” the useful follow-up is not “did SonarQube pass?” but:

• Does ./scripts/build_dist.sh pass on the latest branch?
• Does the app generate the expected v2 output?
• Are all referenced icons, thumbnails, and screenshots reachable?
• Does the declared architecture match the image?
• Are version and release metadata current?
• Have all review comments been resolved?

How to follow up without creating noise

If the submission has been quiet for a long time, post one compact status update instead of repeating the full original pitch. A useful follow-up looks like this:

PR: #888
Latest commit: <SHA>
v2 build: passes ./scripts/build_dist.sh
GitHub Actions: green on latest commit
Open review comments: none
What I need: confirmation of any remaining maintainer-side blocker

That gives a maintainer the answerable question immediately.

If official-store review is slow, a third-party store is a valid distribution path

The v2 ecosystem is not limited to one repository. ZimaOS also documents third-party store setup for compatible repositories. If an app needs community distribution before an official merge, publishing through a maintained third-party store can be a practical alternative while the original PR remains open.

For users rather than contributors, the ZimaOS App Store explains the one-click app model and third-party store concept. The ZimaOS app platform gives the current ecosystem overview. If you are building a compact host for Docker-heavy app testing, ZimaBoard 2 is a relevant x86 test platform, not a requirement for submitting an app.

FAQ

Does passing CI mean my app should already be merged?

No. CI proves only what the automated workflows validate. Human review, repository rules, unresolved comments, conflicts, and maintainer decisions are separate.

What is the most useful local validation command for the current App Store?

The repository's contributing guide points to ./scripts/build_dist.sh. Confirm that it finishes cleanly and produces the expected v2 files.

Should I keep changing code if every check is green?

Not without a specific reason. First inspect the merge box and review comments. If there is no contributor-fixable blocker, ask for the remaining review decision instead of making speculative changes.

Can I publish the app outside the official store?

Yes. The current v2 documentation explicitly supports third-party ZimaOS-compatible stores, so an external store can be a legitimate distribution path.