Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add initial PR for Contributing & Coding Standard #920

Draft
wants to merge 26 commits into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
26 commits
Select commit Hold shift + click to select a range
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 0 additions & 14 deletions .github/CONTRIBUTING.md

This file was deleted.

108 changes: 108 additions & 0 deletions .github/CONTRIBUTOR_GUIDE/CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,108 @@

# Community Scripts Contribution Guide

## **Welcome to the communty-scripts Repository!**
📜 These documents outlines the essential coding standards for all our scripts and JSON files. Adhering to these standards ensures that our codebase remains consistent, readable, and maintainable. By following these guidelines, we can improve collaboration, reduce errors, and enhance the overall quality of our project.

### Why Coding Standards Matter

Coding standards are crucial for several reasons:

1. **Consistency**: Consistent code is easier to read, understand, and maintain. It helps new team members quickly get up to speed and reduces the learning curve.
2. **Readability**: Clear and well-structured code is easier to debug and extend. It allows developers to quickly identify and fix issues.
3. **Maintainability**: Code that follows a standard structure is easier to refactor and update. It ensures that changes can be made with minimal risk of introducing new bugs.
4. **Collaboration**: When everyone follows the same standards, it becomes easier to collaborate on code. It reduces friction and misunderstandings during code reviews and merges.

### Scope of These Documents

These documentes covers the coding standards for the following types of files in our project:

- **`APP-install.sh` Scripts**: These scripts are responsible for the installation of applications and are located in the `/install` directory.
- **`APP.sh` Scripts**: These scripts handle the creation and updating of containers and are found in the `/ct` directory.
- **JSON Files**: These files store structured data and are located in the `/json` directory.

Each section provides detailed guidelines on various aspects of coding, including shebang usage, comments, variable naming, function naming, indentation, error handling, command substitution, quoting, script structure, and logging. Additionally, examples are provided to illustrate the application of these standards.

By following the coding standards outlined in this document, we ensure that our scripts and JSON files are of high quality, making our project more robust and easier to manage. Please refer to this guide whenever you create or update scripts and JSON files to maintain a high standard of code quality across the project. 📚🔍

Let's work together to keep our codebase clean, efficient, and maintainable! 💪🚀


## Getting Started

Before contributing, please ensure that you have the following setup:

1. **Visual Studio Code** (recommended for script development)
2. **Necessary VS Code Extensions:**
- [Shell Syntax](https://marketplace.visualstudio.com/items?itemName=bmalehorn.shell-syntax)
- [ShellCheck](https://marketplace.visualstudio.com/items?itemName=timonwong.shellcheck)
- [Shell Format](https://marketplace.visualstudio.com/items?itemName=foxundermoon.shell-format)

### Important Notes
- Use [AppName.sh](https://github.com/community-scripts/ProxmoxVE/blob/contributor_guide/.github/CONTRIBUTOR_GUIDE/ct/AppName.sh) and [AppName-install.sh](https://github.com/community-scripts/ProxmoxVE/blob/contributor_guide/.github/CONTRIBUTOR_GUIDE/install/AppName-install.sh) as templates when creating new scripts.
- The call to `community-scripts/ProxmoxVE` should be adjusted to reflect the correct fork URL.

---

# 🚀 The Application Script (ct/AppName.sh)

- You can find all Coding standards, as well as the structure for this files [here](https://github.com/community-scripts/ProxmoxVE/blob/contributor_guide/.github/CONTRIBUTOR_GUIDE/ct/AppName.md).
- These Scripts are responsible for Container creataion, setting the necessery varibles and handels the update of the Application.

---

# 🛠 The Installation Script (install/AppName-install.sh)

- You can find all Coding standards, as well as the structure for this files [here](https://github.com/community-scripts/ProxmoxVE/blob/contributor_guide/.github/CONTRIBUTOR_GUIDE/install/AppName-install.md).
- These Scripts are responsible for the installation of the Application.

---

## 🚀 Building Your Own Scripts

Start with the [template script](https://github.com/community-scripts/ProxmoxVE/blob/contributor_guide/.github/CONTRIBUTOR_GUIDE/install/AppName-install.sh)

---

## 🤝 Contribution Process

### 1. Fork the Repository
Fork to your GitHub account

### 2. Clone Your Fork on your Pc
```bash
git clone https://github.com/yourUserName/ForkName
```

### 3. Create a New Branch
```bash
git switch -c your-feature-branch
```

### 4. Change Paths in build.func install.func and AppName.sh
You need to switch `https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main` to `https://raw.githubusercontent.com/[USER]/[REPOSITORY]/refs/head/[BRANCH]` to test your script in your repository. Befor opening a Pull Request change all this back to point to the community-scripts Repository.

### 4. Commit Changes (without build.func and install.func!)
```bash
git commit -m "Your commit message"
```

### 5. Push to Your Fork
```bash
git push origin your-feature-branch
```

### 6. Create a Pull Request
Open a PR from your feature branch to the main repository branch. You may only include your **AppName.sh**, **AppName-install.sh** and **AppName.json** files in the pull request.

---

## 📚 Pages

- [Function-Overview](https://github.com/community-scripts/ProxmoxVE/wiki/Function_Overview)
- [CT Template: AppName.sh](https://github.com/community-scripts/ProxmoxVE/blob/contributor_guide/.github/CONTRIBUTOR_GUIDE/ct/AppName.sh)
- [Install Template: AppName-install.sh](https://github.com/community-scripts/ProxmoxVE/blob/contributor_guide/.github/CONTRIBUTOR_GUIDE/install/AppName-install.sh)
- [JSON Template: AppName.json](https://github.com/community-scripts/ProxmoxVE/blob/contributor_guide/.github/CONTRIBUTOR_GUIDE/json/AppName.json)

---

231 changes: 231 additions & 0 deletions .github/CONTRIBUTOR_GUIDE/ct/AppName.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,231 @@
# **AppName<span></span>.sh Scripts**
`AppName.sh` scripts found in the `/ct` directory. These scripts are responsible for the installation of the desired Application. For this guide we take `/ct/snipeit.sh` as example.


## 1. **File Header**

### 1.1 **Shebang**
- Use `#!/usr/bin/env bash` as the shebang.

```bash
#!/usr/bin/env bash
```
### 1.2 **Import Functions**
- Import the build.func File.
- When developing your own Script, change the link to your own repository.

> [!CAUTION]
> Before opening a Pull Request, change the link to point to the community-scripts repo.

Example for development:
```bash
source <(curl -s https://raw.githubusercontent.com/[USER]/[REPO]/refs/heads/[BRANCH]/misc/build.func)
```

Example for final Script:
```bash
source <(curl -s https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/misc/build.func)
```

### 1.3 **Metadata**
- Add clear comments for script metadata, including author, copyright, and license information.

Example:
```bash
# Copyright (c) 2021-2024 community-scripts ORG
# Author: [YourUserName]
# License: MIT | https://github.com/community-scripts/ProxmoxVE/raw/main/LICENSE
# Source: [SOURCE_URL]
```

> [!NOTE]:
> - Add your username and source URL
> - For existing scripts, add "| Co-Author [YourUserName]" after the current author

---

## 2 **Variables and Function import**
> [!NOTE]
> You need to have all this set in your Script, otherwise it will not work!

### 2.1 **Default Values**
- This sections sets the Default Values for the Container.
- `APP` needs to be set to the Application name and must represent the filenames of your scripts.
- `var_tags`: You can set Tags for the CT wich show up in the Proxmox UI. Don´t overdo it!

>[!NOTE]
>Description for all Default Values
>| Variable | Description | Notes |
>|----------|-------------|-------|
>| `APP` | Application name | Must match ct\AppName.sh |
>| `TAGS` | Proxmox display tags without Spaces, only ; | Limit the number |
>| `var_cpu` | CPU cores | Number of cores |
>| `var_ram` | RAM | In MB |
>| `var_disk` | Disk capacity | In GB |
>| `var_os` | Operating system | alpine, debian, ubuntu |
>| `var_version` | OS version | e.g., 3.20, 11, 12, 20.04 |
>| `var_unprivileged` | Container type | 1 = Unprivileged, 0 = Privileged |

Example:
```bash
APP="SnipeIT"
var_tags="asset-management;foss"
var_cpu="2"
var_ram="2048"
var_disk="4"
var_os="debian"
var_version="12"
var_unprivileged="1"
```

## 2.2 **📋 App Output & Base Settings**

```bash
# App Output & Base Settings
header_info "$APP"
base_settings
```

- `header_info`: Generates ASCII header for APP
- `base_settings`: Allows overwriting variable values

## 2.3 **🛠 Core Functions**

```bash
# Core
variables
color
catch_errors
```

- `variables`: Processes input and prepares variables
- `color`: Sets icons, colors, and formatting
- `catch_errors`: Enables error handling

---

## 3 **Update Function**

### 3.1 **Function Header**
- If applicable write a function wich updates the Application and the OS in the container.
- Each update function starts with a standardised Header:
```bash
function update_script() {
header_info
check_container_storage
check_container_resources
```

### 3.2 **Check APP**
- Befor doing anything updatewise, check if the App is installed in the Container.

Example:
```bash
if [[ ! -d /opt/snipe-it ]]; then
msg_error "No ${APP} Installation Found!"
exit
fi
```
### 3.3 **Check Version**
- Befor updating, check if a new Version exists.
- For this we use the `${APPLICATION}_version.txt` file created in `/opt` during the install.

Example with a Github Release:
```bash
RELEASE=$(curl -fsSL https://api.github.com/repos/snipe/snipe-it/releases/latest | grep "tag_name" | awk '{print substr($2, 3, length($2)-4) }')
if [[ ! -f /opt/${APP}_version.txt ]] || [[ "${RELEASE}" != "$(cat /opt/${APP}_version.txt)" ]]; then
msg_info "Updating ${APP} to v${RELEASE}"
#DO UPDATE
else
msg_ok "No update required. ${APP} is already at v${RELEASE}."
fi
exit
}
```
### 3.4 **Verbosity**
- Use the appropiate flag (**-q** in the examples) for a command to suppres its output.
Example:
```bash
wget -q
unzip -q
```
- If a command dose not come with such a functionality use `&>/dev/null` to suppress its output.

Example:
```bash
php artisan migrate --force &>/dev/null
php artisan config:clear &>/dev/null
```

### 3.5 **Backups**
- Backup userdata if nessesary.
- Move all userdata back in the Directory when the update is finnished.
>[!NOTE]
>This is not meant to be a permantent backup

Example backup:
```bash
mv /opt/snipe-it /opt/snipe-it-backup
```
Example config restore:
```bash
cp /opt/snipe-it-backup/.env /opt/snipe-it/.env
cp -r /opt/snipe-it-backup/public/uploads/ /opt/snipe-it/public/uploads/
cp -r /opt/snipe-it-backup/storage/private_uploads /opt/snipe-it/storage/private_uploads
```

### 3.6 **Cleanup**
- Do not forget to remove any temporary files/folders such as zip-files or temporary backups.
Example:
```bash
rm -rf /opt/v${RELEASE}.zip
rm -rf /opt/snipe-it-backup
```

### 3.7 **No update function**
- In case you can not provide a update function use the following code to provide user feedback.
```bash
function update_script() {
header_info
check_container_storage
check_container_resources
if [[ ! -d /opt/snipeit ]]; then
msg_error "No ${APP} Installation Found!"
exit
fi
msg_error "Ther is currently no automatic update function for ${APP}."
exit
}
```

---

## 4 **End of the Script**
- `start`: Launches Whiptail dialogue
- `build_container`: Collects and integrates user settings
- `description`: Sets LXC container description
- With `echo -e "${TAB}${GATEWAY}${BGN}http://${IP}${CL}"` you can point the user to the IP:PORT/folder needed to access the App.

```bash
start
build_container
description

msg_ok "Completed Successfully!\n"
echo -e "${CREATING}${GN}${APP} setup has been successfully initialized!${CL}"
echo -e "${INFO}${YW} Access it using the following URL:${CL}"
echo -e "${TAB}${GATEWAY}${BGN}http://${IP}${CL}"
```
---

## 5. **Best Practices Checklist**

- [ ] Shebang is correctly set (`#!/usr/bin/env bash`).
- [ ] Correct link to *build.func*
- [ ] Metadata (author, license) is included at the top.
- [ ] Variables follow naming conventions.
- [ ] Update function exists.
- [ ] Update functions checks if App is installed an for new Version.
- [ ] Update function up temporary files.
- [ ] Script ends with a helpfull message for the User to reach the App.

Loading
Loading