Introduce armbian-config config file to store app wide variables

[igorpecovnik]

Description

Purpose of this configuration file is to have a storage for common app wide variables such as DOMAIN name used in SWAG reverse proxy. If domain is enabled, URL to apps is changed from IP to domain name with https enabled.

Implementation Details

Storing variables in /etc/armbian-config

Testing Procedure

• [x] Store and read while installing SWAG

Checklist

• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my code
• [x] I have ensured that my changes do not introduce new warnings or errors
• [x] No new external dependencies are included
• [x] Changes have been tested and verified

[coderabbitai[bot]]

Walkthrough

• Added Armbian config integration in set_runtime_variables.sh: defines CONFIG_FILE="/etc/armbian-config", ensures it exists, and sources it if present.
• Introduced set_config_var(key, value, file) to upsert key=value pairs in a config file.
• Updated module_swag.sh to use $DIALOG for the URL prompt, default the input to ${DOMAIN}, and persist the chosen domain by calling set_config_var "DOMAIN" "${SWAG_URL}" "$CONFIG_FILE" after successful input.
• Existing control flow for SWAG setup remains unchanged aside from these additions.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

✨ Finishing Touches

• [ ] 📝 Generate Docstrings

🧪 Generate unit tests

• [ ] Create PR with unit tests
• [ ] Post copyable unit tests in a comment
• [ ] Commit unit tests in branch configfile

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Support

Need help? Create a ticket on our support page for assistance with any issues or questions.

CodeRabbit Commands (Invoked using PR/Issue comments)

Type @coderabbitai help to get the list of available commands.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Status, Documentation and Community

• Visit our Status Page to check the current availability of CodeRabbit.
• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[Tearran]

Hi @igorpecovnik,

I noticed your PR introducing the armbian-config configuration file for app-wide variables. I've actually been working on a similar solution, https://github.com/Tearran/configng-tools-v2/blob/main/src/core/initialize/init_vars.sh which implements variable management with source-able output and comprehensive system information gathering.

My implementation includes: (AI generated list may be off a little)

• Organized variable categories (project identity, paths, system info, network details)
• Proper sourcing support with . <(init_vars show) syntax
• Comprehensive detection of network, system, and OS information
• Clear documentation and usage examples

Thanks, Tearran

[igorpecovnik]

I want to improve current operations of some modules. Diving into the v2 code would take me a lot of time ... I barely find time to fix a bugs here and there for what we have now. That's the problem. No doubt about v2 is much better. We need to come up with some strategy how to deal with this (big) change.

[Tearran]

Thanks for the feedback, and sorry if my intention was misunderstood.

I’m not proposing to push a new tool or force v2 work here. I’m only trying to document and standardize which environment variables are (a) already discoverable from the system and (b) should be considered “canonical” for configng modules to reuse.

Goals:

• Identify the existing, known variables (from /etc/os-release, optional /etc/armbian-release, uname, network introspection).
• Agree on which ones we actually want to expose.
• Make them easy to consume (source one script) and easy to document (consistent names).