fef128fb7d
* feat: refactor update comparison output for consistency and clarity - Replaced direct echo statements with fn_print functions for uniformity in output formatting across multiple update scripts. - Ensured lockfile creation uses the correct syntax for variable expansion. - Moved lock file to the same location to ensure monitor doesnt reboot at the wrong time - Updated remote build information display to enhance readability and maintain consistency in logging. - Removed unnecessary echo commands to streamline the output process. * Refactor remote build version handling across multiple modules - Updated variable names from 'remotebuildversion' to 'remotebuild' for consistency. - Adjusted logic to check for remote build availability using the new variable name. - Modified output messages to reflect the change in variable naming. - Ensured all modules (update_mc.sh, update_mcb.sh, update_mta.sh, update_pmc.sh, update_ts3.sh, update_ut99.sh, update_vints.sh, update_xnt.sh) are aligned with the new naming convention for better readability and maintainability. * fix(alert): resolve issue with servername not always being listed in title * Moved `info_distro.sh`, `info_game.sh`, and `info_messages.sh` calls to the top of the `fn_alert_log` function for better clarity. * Updated `alerticon` assignment to maintain consistency in alert information handling. * fix(alert_discord): remove "More info" field from Discord alert JSON * Eliminated the "More info" field to streamline the alert message. * This change enhances the clarity of the alert by focusing on essential information. * fix(alert): improve update alert messaging for clarity * Updated alert messages in `fn_alert_update` and `fn_alert_update_failed` for better readability. * Changed alert action from `update-request` to `update-restart-request` in `fn_monitor_check_update_source`. * remove inline * fix(alert): Correct grammar in update alert message * Changed "an LinuxGSM update" to "a LinuxGSM update" for grammatical accuracy. * typo * fix(alert_discord): Add inline property to "Is my Game Server Online?" field * Ensures proper formatting of the Discord alert message. * Improves the display of the server status information. * fix(pd): increase timeout for termbin.com connection * fix(alert_discord): reorder fields in Discord alert JSON * Changed the order of fields in the Discord alert JSON structure. * Updated the "More info" and "Is my Game Server Online?" fields for better clarity. * revert back to factorio.com Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> * Standardizes alert messages across platforms Ensures consistency in alert messages across Discord, NTFY, Pushover, Rocketchat, Slack, and Telegram. Updates Discord alerts to include server hostname and time, removes redundant formatting. Standardizes plain-text alert formatting for NTFY. Refactors Pushover messages to use consistent HTML formatting. Streamlines Rocketchat and Slack messages by removing duplicate server info and adding optional link support. * Removes Hostname from alert messages Removes the Hostname field from various alert messages (Discord, Gotify, IFTTT, ntfy, Pushbullet, Pushover, Rocketchat, Slack, Telegram). The hostname was deemed redundant or unnecessary in the context of these alerts. Relates to #4696 * Configures shellcheckrc filename Configures the Super-Linter action to use `.shellcheckrc` as the BASH_FILE_NAME. This ensures that shellcheck uses the correct configuration file for bash script linting. Fixes #4696 * Disables shellcheck errors and removes variable Disables specific shellcheck errors to allow certain coding patterns and removes an unused variable from the super-linter workflow. This improves the linter's signal-to-noise ratio and reduces unnecessary checks. Relates to #4696 * Fixes and improves server list validation scripts Addresses issues in the server list validation scripts: - Fixes potential issues with parsing curl custom arguments in telegram alerts. - Corrects the shortname array generation. - Implements more robust checks for validating game icons. - Ensures the consistency of server counts across different CSV files. * Fixes glibc check and mod selection logic Corrects glibc version comparison to properly handle version strings. Improves mod installation and removal by validating user input against available options, providing a more robust selection process. This prevents errors caused by invalid mod names and enhances the user experience. Updates arithmetic expression syntax for better compatibility. * Fixes cache control for dev-debug mode Updates the handling of cache control headers in dev-debug mode. The `nocache` variable is changed to an array to correctly pass multiple headers to `curl`. This resolves issues with cached versions of files being used when dev-debug is enabled, ensuring that the latest versions are always fetched. Fixes #4696 * Allows spaces in steamcmdcommand variable Parses steamcmdcommand as an array to allow spaces in the variable. This prevents issues when the user wants to pass arguments with spaces to the steamcmd executable. * Addresses various script improvements Addresses multiple improvements across various scripts: - Fixes Valheim unstripped_corlib override by commenting out the lines in the config files. - Improves process identification for source and goldsrc engines using `pgrep`. - Enhances backup file identification using `find` with `-maxdepth 1` and `-type f`. - Fixes glibc version comparison logic in multiple files. - Improves UT2K4 key installation script by using printf for writing the key to the file. - Corrects the mod info extraction logic to correctly identify mod entries. - Improves amxmodx file installation/removal logic to prevent duplicate entries. - Fixes server info retrieval to handle spaces in the server list. Relates to #4696 * Fixes mono repo install exit code check Corrects the mono repo install exit code check to use the dedicated monorepoexitcode variable, ensuring accurate error detection. Updates the exit trap to preserve the original exit status, preventing potential loss of information when handling script termination. * Refactors and reorders core modules Improves module loading by reordering and refactoring the core modules. This change addresses inconsistencies and improves the overall structure of how core modules are handled within the system. Some fix scripts were renamed to match the module name. * Makes scripts executable Changes file permissions to make shell scripts executable. This ensures that the scripts can be run directly. Addresses a pre-existing issue. Related to #4696 * Adds explicit permissions to workflows Specifies explicit permissions for GitHub Actions workflows to enhance security and control access to resources. This ensures that each workflow only has the necessary permissions, following the principle of least privilege. * Fixes output redirection and URL parsing Corrects output redirection in GitHub Actions workflows by enclosing the $GITHUB_OUTPUT variable in quotes, preventing potential issues with variable expansion. Ensures proper URL parsing in workflows by enclosing the URL within quotes, addressing potential parsing errors. Fixes #4696 * Applies code formatting for consistency Applies Prettier formatting to the codebase for improved readability and consistency. Addresses minor code style inconsistencies across several files. * Fixes minor formatting and logic issues Addresses various minor issues including: - Standardizes indentation in `.editorconfig` for different file types. - Simplifies Prettier configuration. - Updates image links in `README.md`. - Ensures newline character at end of `.csv` files. - Corrects a conditional statement in `command_fastdl.sh`. - Corrects a conditional statement in `info_messages.sh`. - Updates server query protocols in `query_gsquery.py`. * Configures and disables linters Adds YAML linting configuration and disables unnecessary linters to streamline the CI/CD process and reduce noise from irrelevant checks. * Improves documentation and linting Updates documentation links to be enclosed in angle brackets, preventing markdown rendering issues. Configures markdownlint to align with repository standards and avoid common false positives. The updated links in the documentation ensure they are correctly interpreted by markdown parsers, improving user experience. The markdownlint configuration fine-tunes linting rules to better match the project's existing style and conventions, reducing noise from irrelevant warnings. * Fixes typos and improves code consistency Addresses various typos and inconsistencies across multiple files, enhancing code readability and maintainability. Adds codespell and flake8 configurations for linting. Relates to #4696 * Excludes workflow files from Prettier formatting Prevents Prettier from formatting workflow files due to GitHub token restrictions, as the token used by the Prettier auto-commit action lacks permissions to update files within the `.github/workflows/` directory. * chore(prettier): format code * Updates Super-Linter configuration Improves Super-Linter's reliability by switching to linting the entire codebase instead of relying on git history. This change also addresses potential transient fetch failures from GitHub. Additionally, this commit expands the ignored paths in codespell and disables some linters to improve performance and reduce false positives. --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: dgibbs64 <dgibbs64@users.noreply.github.com>
14 KiB
Contributing to LinuxGSM
👍🎉 Thank you for taking the time to contribute! 🎉👍
The following is a set of guidelines for contributing to LinuxGSM, which are hosted in the GameServerManagers Organization on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
Table of Contents
- Table of Contents
- Code of Conduct
- 🎉 Bug/Enhancement Contributions 🐛
- 💻 Code Contributions
- 📘 Document Contributions
- Issue and Pull Request Labels
Code of Conduct
This project and everyone participating in it is governed by the LinuxGSM Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behaviour to daniel.gibbs@linuxgsm.com.
🎉 Bug/Enhancement Contributions 🐛
🐛Reporting Bugs
This section guides you through submitting a bug report for LinuxGSM. Following these guidelines help maintainers and the community understand your report 📝, reproduce the behaviour💻, and find any related reports 🔎.
Before creating bug reports, please check this list as you might find out that you don’t need to create one. When you are creating a bug report, please include as many details as possible. Fill out the required template, the information it asks for helps us resolve issues faster.
Before Submitting A Bug Report
- Check the documentation. You might be able to find the cause of the problem and fix things yourself.
- Check the support page for links to other support options.
- Perform a cursory search to see if the problem has already been reported. If it has and the issue is still open, add a comment to the existing issue and give it a thumbs up instead of opening a new one.
How Do I Submit A (Good) Bug Report?
Bugs are tracked as GitHub issues. Create an issue and provide the following information by filling in the issues form.
- Use a clear and descriptive title for the issue to identify the problem.
- Complete the user story to give a summary of the issue.
- Provide basic info to help us understand the context of the issue.
- Provide further info to give specifics and more detail.
- Give steps to reproduce the issue, allowing developers to follow steps that lead to the issue.
- Explain what you expect to happen, so we know what you think should occur.
🎉Suggesting Features
This section guides you through submitting a feature suggestion for LinuxGSM, including completely new features and minor improvements to existing functionality. Following these guidelines help maintainers and the community understand your suggestion 📝 and find related suggestions 🔎.
Before Submitting An Feature Suggestion
- Check the documentation to confirm that the enhancement doesn’t already exist.
- Check your LinuxGSM version. A newer version of LinuxGSM may already have your enhancement.
- Perform a cursory search to see if the enhancement has already been suggested. If it has and the enhancement is still open, add a comment to the existing issue and give it a thumbs up instead of opening a new one.
How Do I Submit A (Good) Feature Suggestion?
Features are tracked as GitHub issues. Create an issue and provide the following information by filling in the issues form.
- Use a clear and descriptive title for the issue to identify the problem.
- Complete the user story to give a summary of the issue.
- Provide basic info to help us understand the context of the enhancement.
- Provide further info to give specifics and more detail.
- Provide any further reading materials that might assist in developing the enhancement.
🎮 Game Server Requests
This section guides you through submitting a game server request for LinuxGSM, Following these guidelines help maintainers and the community understand your game server request 📝.
Before Submitting a Game Server Request
- Check for existing game server requests to see if the new game server has already been suggested. If it has and if the new game server is still open, give it a thumbs up.
- Check the game server is supported on Linux, this does not include Wine servers which we do not support.
How Do I Submit A (Good) Game Server Request?
- The title should be as follows: [Server Request] Game Name
- Provide Steam App ID if applicable
- Supply any documentation/how-to guides for the game server.
🎮 Game Server Specific Issues
LinuxGSM is a management script that acts as a wrapper around game servers. These game servers are developed by different game developers such as Valve, Epic and Facepunch to name a few.
LinuxGSM has no control over the development and limited knowledge of issues directly relating to the game servers themselves. The same also applies to any mods, add-ons, maps etc.
If there is an issue with a specific game server or mod the best action may be to contact the game/mod developers on their support forums. If it is unclear some community members should be able to help.
A list of known game developer forums is available on the LinuxGSM docs.
💻 Code Contributions
Pull Requests
The process described here has several goals:
- Maintain LinuxGSM quality.
- Fix problems that are important to users.
- Engage the community in working toward the best possible LinuxGSM.
- Enable a sustainable system for LinuxGSM maintainers to review contributions.
Please follow these steps to have your contribution considered by the maintainers:
- Follow all check-list in the template
- Follow the style guides
- After you submit your pull request, verify that all status checks are passing
What if the status checks are failing? If a status check is failing, and you believe that the failure is unrelated to your change, please leave a comment on the pull request explaining why you believe the failure is unrelated. A maintainer will re-run the status check for you. If we conclude that the failure was a false positive, then we will open an issue to track that problem with our status check suite.
While the prerequisites above must be satisfied before having your pull request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted.
Pull Request naming convention
When naming a pull request to ensure that it is following Conventional Commits standards; as your pull request commits will be squashed, with the PR subject becoming the commit that is used for generating the changelog for the next release.
The pull request subject line should always be able to complete the following sentence:
If applied, this commit will your subject line here
For example:
- If applied, this commit will refactor subsystem X for readability
- If applied, this commit will update getting started documentation
- If applied, this commit will remove deprecated methods
- If applied, this commit will release version 1.0.0
- If applied, this commit will merge pull request #123 from user/branch
Notice how this doesn’t work for the other non-imperative forms:
- If applied, this commit will fixed bug with Y
- If applied, this commit will change the behaviour of X
- If applied, this commit will more fixes for broken stuff
- If applied, this commit will sweet new API methods
Below is an example of the subject line for a pull request:
- feat(alerts): add slack support to alerts
- fix(csgoserver): remove SteamCMD auth requirement 32-bit workaround
Testing
Pull Request Status Checks
When a Pull Request is submitted, a series of status check tests are conducted. These tests will assess the code quality, complete CI tests etc. To get your PR merged these status checks must pass.
Test Environment
It is recommended that you have a testing environment available to test your code during development. To test your own code you must change some variables within the linuxgsm.sh file. This will force the use of your own code branch.
## GitHub Branch Select
# Allows for the use of different function files
# from a different repo and/or branch.
githubuser="GameServerManagers"
githubrepo="LinuxGSM"
githubbranch="master"
🍷 Styleguides
Git Commit Messages
LinuxGSM uses the Conventional commits standard to allow other developers to get easy to understand, descriptive commit messages as you develop. While it is recommended that you use this standard for your commits, as your commits will eventually be squashed when your PR is merged following this standard is not strictly enforced for commits, however, it is recommended for more complex commits.
BASH Styleguide
LinuxGSM uses ShellCheck to follow BASH best practices. It is recommended that you make use of linter tools for your text editor such as linter-shellcheck. LinuxGSM uses Codacy to analyse any Pull Requests to give you feedback on code standards.
LinuxGSM also has some of its style standards that should be followed. These are available in the dev docs
📘 Document Contributions
As well as code contributions it is possible to contribute by writing and improving documentation. Documents contributions can be submitted similarly by submitting a Pull Request.
Documentation Styleguide
LinuxGSM has various documentation available to assist users and developers. LinuxGSM primarily uses GitBook which uses the Markdown document standard. LinuxGSM uses Codacy to analyse any Pull Requests to give you feedback on markup standards.
Issue and Pull Request Labels
This section lists the labels we use to help us track and manage issues and pull requests.
GitHub search makes it easy to use labels for finding groups of issues or pull requests you're interested in. There are several categories of labels available:
command Labels Highlights the LinuxGSM command the Issue/PR relates to.
info Labels Labels to help pinpoint what the issue or PR relates to.
variants:
- distro
- engine
- game
- info
outcome Labels Labels that identify why an issue was closed.
status Labels Labels to update people on the status of the issue.
type Labels Labels identifying the type of issue, such as a bug, feature, refactor etc.