Add dynamic compose for dokuwiki #5404
Conversation
WalkthroughThe pull request introduces updates to the DokuWiki configuration and Docker Compose files. In Changes
Possibly related PRs
Suggested reviewers
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Outside diff range and nitpick comments (2)
apps/dokuwiki/docker-compose.json (2)
15-17: Consider adding recommended environment variables.The linuxserver/dokuwiki image supports additional environment variables that could improve the container's functionality:
"environment": { - "TZ": "${TZ}" + "TZ": "${TZ}", + "PUID": "1000", + "PGID": "1000", + "PHP_MEMORY_LIMIT": "256M" },
25-30: Enhance health check reliability.The current health check can be improved for better reliability:
"healthCheck": { - "test": "curl --fail http://localhost || exit 1", + "test": "curl -sf --max-time 5 --retry 3 http://localhost/doku.php || exit 1", "retries": 3, - "interval": "30s", + "interval": "15s", "timeout": "10s" + "start_period": "30s" }Changes:
- Added
-sfor silent mode and specific endpoint check- Added
--max-timeand--retryflags for better curl behavior- Reduced interval for faster failure detection
- Added start_period to allow for initial setup
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (3)
apps/dokuwiki/config.json(1 hunks)apps/dokuwiki/docker-compose.json(1 hunks)apps/dokuwiki/docker-compose.yml(1 hunks)
🔇 Additional comments (5)
apps/dokuwiki/docker-compose.json (2)
8-14: LGTM! Volume configuration follows best practices.
The volume mapping is correctly configured for data persistence using the appropriate environment variable and necessary write permissions.
18-24: LGTM! Port configuration is appropriate.
The port mapping uses a high port number to avoid conflicts, and TCP is correctly specified for HTTP traffic.
apps/dokuwiki/config.json (2)
7-7: LGTM on dynamic_config addition.
The addition of "dynamic_config": true aligns with the PR objective of implementing dynamic compose for dokuwiki.
Let's verify this is the standard way to enable dynamic compose:
✅ Verification successful
Dynamic config flag usage is consistent with other apps
The "dynamic_config": true setting follows the established pattern used across numerous other applications in the repository (found in 44 other apps including adguard, gitea, homepage, etc.), confirming this is the standard way to enable dynamic compose functionality.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for other apps using dynamic_config to confirm the pattern
rg '"dynamic_config":\s*true' apps/*/config.json
Length of output: 9633
9-9: Please verify the tipi_version bump compatibility.
The major version bump from 2 to 3 could indicate breaking changes. Please ensure:
- All dependent systems are compatible with tipi_version 3
- Migration steps are documented if needed
Let's check other apps' tipi versions:
✅ Verification successful
Let me analyze the tipi_version distribution across apps to verify the compatibility of version 3:
-
There are many apps with tipi_version 3, including: baikal, barrage, chatpad, cloudflare-ddns, codex-docs, deluge, emby, emqx, excalidraw, flightlog, haven, heimdall, hello-world, homeassistant, homer, kapowarr, kasm-workspaces, libreddit, librespeed, mempool, nginx, openbooks, podfetch, send, suwayomi, umami, uptime-kuma, whisparr, write-freely.
-
There are apps with both lower versions (1-2) and higher versions (up to 352), showing that different versions can coexist in the ecosystem.
-
The presence of multiple other apps already using tipi_version 3 indicates it's a stable and compatible version.
The tipi_version 3 bump is compatible with the ecosystem.
- Multiple apps are already running with tipi_version 3 successfully
- The version range (1-352) shows version 3 is well within the supported spectrum
- No evidence of breaking changes or compatibility issues found
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check tipi_version distribution across apps
echo "Distribution of tipi_version values:"
rg -o '"tipi_version":\s*\d+' apps/*/config.json | sort | uniq -c
Length of output: 21787
apps/dokuwiki/docker-compose.yml (1)
4-4:
Consider using a specific version tag instead of latest.
Using the latest tag in production environments can lead to several issues:
- Non-deterministic deployments
- Unexpected breaking changes during updates
- Difficult rollbacks
- Complicated version tracking
Consider pinning to a specific version (e.g., 2022-07-31a-ls158) and implementing a controlled version upgrade strategy.
Let's check the available versions and recent changes:
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
|
Hello @viktor-c, Thank you for your contribution, this one is greatly appreciated. 😊 Can you make some modifications :
|
|
Thank you for your contribution! Unfortunately, we are no longer accepting pull requests from external collaborators due to the high volume of PRs we have to deal with daily. We have reached a point in which it has become too complicated to validate, test and maintain this huge amount of apps resulting in a poor experience for our users. We are working at the moment to implement a new feature to allow you to add multiple app stores to your Runtipi instance, so you can add your own apps without the need to send a PR to our repository. This feature will be available very soon, so stay tuned! In the mean time, if you really need your app in Runtipi, you can add your own repository to your Runtipi instance relevant docs |
|
Thank you for your contribution! Unfortunately, we are no longer accepting pull requests from external collaborators due to the high volume of PRs we have to deal with daily. We have reached a point in which it has become too complicated to validate, test and maintain this huge amount of apps resulting in a poor experience for our users. We are working at the moment to implement a new feature to allow you to add multiple app stores to your Runtipi instance, so you can add your own apps without the need to send a PR to our repository. This feature will be available very soon, so stay tuned! In the mean time, if you really need your app in Runtipi, you can add your own repository to your Runtipi instance relevant docs |
|
@Lancelot-Enguerrand Thank you for your comments, changed the code as wished. |
|
Thank you for your contribution! Unfortunately, we are no longer accepting pull requests from external collaborators due to the high volume of PRs we have to deal with daily. We have reached a point in which it has become too complicated to validate, test and maintain this huge amount of apps resulting in a poor experience for our users. We are working at the moment to implement a new feature to allow you to add multiple app stores to your Runtipi instance, so you can add your own apps without the need to send a PR to our repository. This feature will be available very soon, so stay tuned! In the mean time, if you really need your app in Runtipi, you can add your own repository to your Runtipi instance relevant docs |
There was a problem hiding this comment.
Hello @viktor-c
I may have been unclear on the version to use, my bad.
We prefer using fixed version for apps, to avoid unforseen breaking changes.
Which tag here ?
latest → no
version-2024-02-06b → almost equivalent to latest, so no
2024-02-06b-ls250 → stable, won't change, so yes
I hope to have cleared out any doubt.
Feel free to ask some questions if needed.
We should be ready to merge after this.
PS : CodeRabbit can be very useful but is subject to hallucination as it is an AI.
PS2 : It's not really a rabbit, sadly 😪
|
Thank you for your contribution! Unfortunately, we are no longer accepting pull requests from external collaborators due to the high volume of PRs we have to deal with daily. We have reached a point in which it has become too complicated to validate, test and maintain this huge amount of apps resulting in a poor experience for our users. We are working at the moment to implement a new feature to allow you to add multiple app stores to your Runtipi instance, so you can add your own apps without the need to send a PR to our repository. This feature will be available very soon, so stay tuned! In the mean time, if you really need your app in Runtipi, you can add your own repository to your Runtipi instance relevant docs |
|
I updated my branch https://github.com/viktor-c/runtipi-appstore/tree/dokuwiki-dynamic-compose |
|
Thank you for your contribution! Unfortunately, we are no longer accepting pull requests from external collaborators due to the high volume of PRs we have to deal with daily. We have reached a point in which it has become too complicated to validate, test and maintain this huge amount of apps resulting in a poor experience for our users. We are working at the moment to implement a new feature to allow you to add multiple app stores to your Runtipi instance, so you can add your own apps without the need to send a PR to our repository. This feature will be available very soon, so stay tuned! In the mean time, if you really need your app in Runtipi, you can add your own repository to your Runtipi instance relevant docs |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
apps/dokuwiki/docker-compose.json (1)
18-23: Consider enhancing the health check configurationWhile the current health check is functional, it could be more robust with these improvements:
"healthCheck": { - "test": "curl --fail http://localhost || exit 1", + "test": "curl --fail --silent --show-error --max-time 5 http://localhost || exit 1", "retries": 3, - "interval": "30s", + "interval": "15s", "timeout": "10s" }This change:
- Adds timeout to curl command to prevent hanging
- Makes curl output cleaner with --silent --show-error
- Reduces interval for faster container readiness detection
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
apps/dokuwiki/config.json(2 hunks)apps/dokuwiki/docker-compose.json(1 hunks)apps/dokuwiki/docker-compose.yml(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
- apps/dokuwiki/docker-compose.yml
- apps/dokuwiki/config.json
🔇 Additional comments (5)
apps/dokuwiki/docker-compose.json (5)
1-5: LGTM! Image version is properly pinned
The service configuration follows best practices with a specific version tag rather than using 'latest', which aligns with the requested changes.
6-7: LGTM! Port configuration is correctly implemented
The port configuration correctly uses only internalPort as requested, allowing the host port to be managed through config.json.
8-14: LGTM! Volume configuration is appropriate
The volume configuration correctly maps the config directory with appropriate permissions for DokuWiki's functionality.
15-17: LGTM! Environment configuration is minimal and appropriate
The environment configuration includes only the necessary timezone variable.
26-26: Add a newline at the end of the file
As requested in previous comments, please add a blank line at the end of the file.
]
-}
+}
+
Changed configs to dynamic compose for dokuwiki.
Checked on a fresh install.
Summary by CodeRabbit
New Features
Updates
"2024-02-06b-ls250".These changes enhance configuration flexibility and ensure users benefit from the latest features and improvements.