ric/uptime-kuma
1
0
Fork 0
mirror of https://github.com/louislam/uptime-kuma.git synced 2025-03-30 13:02:20 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions1

Merge 284e3ea159 into 30f82b9cb4

Browse source
This commit is contained in:
GJS 2025-03-26 16:31:48 +00:00 • committed by GitHub
commit 9c2e86e8bf
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
7 changed files with 407 additions and 96 deletions

48
.github/ISSUE_TEMPLATE/ask-for-help.yaml → .github/ISSUE_TEMPLATE/ask_for_help.yml vendored
View file

@ -1,22 +1,38 @@
---
name: "❓ Ask for help"
description: "Submit any question related to Uptime Kuma"
#title: "[Help] "
labels: [help]
labels: ["help", "P3-low"]
body:
- type: "markdown"
attributes:
value: |
## **❗ Important: Please Avoid Unnecessary Pinging of Maintainers**
**We kindly ask users to refrain from pinging maintainers unless absolutely necessary. Pings should be reserved for critical issues or urgent matters that require immediate attention.**
- **Why**: To help maintainers focus on high-priority tasks, we kindly request that unnecessary or repeated pings be minimized. This will help ensure quicker responses for matters that truly need attention.
- **What This Means**: Non-urgent pings may be ignored or addressed later. Please assess the urgency of your request before pinging a maintainer.
- type: checkboxes
id: no-duplicate-issues
attributes:
label: "⚠️ Please verify that this question has NOT been raised before."
description: "Search in the issues sections by clicking [HERE](https://github.com/louislam/uptime-kuma/issues?q=)"
description:
"Search in the issues sections by clicking
[HERE](https://github.com/louislam/uptime-kuma/issues?q=)"
options:
- label: "I checked and didn't find similar issue"
required: true
- type: checkboxes
attributes:
label: "🛡️ Security Policy"
description: Please review the security policy before reporting security related issues/bugs.
description:
Please review the security policy before reporting security related
issues/bugs.
options:
- label: I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy)
- label:
I agree to have read this project [Security
Policy](https://github.com/louislam/uptime-kuma/security/policy)
required: true
- type: textarea
id: steps-to-reproduce
@ -24,7 +40,9 @@ body:
required: true
attributes:
label: "📝 Describe your problem"
description: "Please walk us through it step by step. Include all important details and add screenshots where appropriate"
description:
"Please walk us through it step by step. Include all important details
and add screenshots where appropriate"
placeholder: "Describe what are you asking for..."
- type: textarea
id: error-msg
@ -36,7 +54,9 @@ body:
id: uptime-kuma-version
attributes:
label: "🐻 Uptime-Kuma Version"
description: "Which version of Uptime-Kuma are you running? Please do NOT provide the docker tag such as latest or 1"
description:
"Which version of Uptime-Kuma are you running? Please do NOT provide the
docker tag such as latest or 1"
placeholder: "Ex. 1.10.0"
validations:
required: true
@ -44,7 +64,9 @@ body:
id: operating-system
attributes:
label: "💻 Operating System and Arch"
description: "Which OS is your server/device running on? (For Replit, please do not report this bug)"
description:
"Which OS is your server/device running on? (For Replit, please do not
report this bug)"
placeholder: "Ex. Ubuntu 20.04 x86"
validations:
required: true
@ -52,7 +74,9 @@ body:
id: browser-vendor
attributes:
label: "🌐 Browser"
description: "Which browser are you running on? (For Replit, please do not report this bug)"
description:
"Which browser are you running on? (For Replit, please do not report
this bug)"
placeholder: "Ex. Google Chrome 95.0.4638.69"
validations:
required: true
@ -67,9 +91,9 @@ body:
- **Filesystem used to store the database on**: Windows/ZFS/btrfs/NFSv3 on a SSD/HDD/eMMC
- **number of monitors**: 42
value: |
- Runtime:
- Database:
- Filesystem used to store the database on:
- number of monitors:
- Runtime:
- Database:
- Filesystem used to store the database on:
- number of monitors:
validations:
required: true

54
.github/ISSUE_TEMPLATE/bug_report.yaml → .github/ISSUE_TEMPLATE/bug_report.yml vendored
View file

@ -1,22 +1,42 @@
---
name: "🐛 Bug Report"
description: "Submit a bug report to help us improve"
#title: "[Bug] "
labels: [bug]
labels: ["bug", "P2-medium"]
body:
- type: "markdown"
attributes:
value: |
## **❗ Important: Please Avoid Unnecessary Pinging of Maintainers**
**We kindly ask users to refrain from pinging maintainers unless absolutely necessary. Pings should be reserved for critical issues or urgent matters that require immediate attention.**
- **Why**: To help maintainers focus on high-priority tasks, we kindly request that unnecessary or repeated pings be minimized. This will help ensure quicker responses for matters that truly need attention.
- **What This Means**: Non-urgent pings may be ignored or addressed later. Please assess the urgency of your request before pinging a maintainer.
- type: textarea
id: related-issues
validations:
required: true
attributes:
label: "📑 I have found these related issues/pull requests"
description: "Search related issues by clicking [HERE](https://github.com/louislam/uptime-kuma/issues?q=) and explain what the difference between them or explain that you are unable to find any related issues"
placeholder: "Related to #1 by also touching the ... system. They should not be merged because ..."
description:
"Search related issues by clicking
[HERE](https://github.com/louislam/uptime-kuma/issues?q=) and explain
what the difference between them or explain that you are unable to find
any related issues"
placeholder:
"Related to #1 by also touching the ... system. They should not be
merged because ..."
- type: checkboxes
attributes:
label: "🛡️ Security Policy"
description: Please review the security policy before reporting security related issues/bugs.
description:
Please review the security policy before reporting security related
issues/bugs.
options:
- label: I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy)
- label:
I agree to have read this project [Security
Policy](https://github.com/louislam/uptime-kuma/security/policy)
required: true
- type: textarea
id: description
@ -31,7 +51,9 @@ body:
required: true
attributes:
label: "👟 Reproduction steps"
description: "How do you trigger this bug? Please walk us through it step by step. Include all important details and add screenshots where appropriate"
description:
"How do you trigger this bug? Please walk us through it step by step.
Include all important details and add screenshots where appropriate"
placeholder: "..."
- type: textarea
id: expected-behavior
@ -53,7 +75,9 @@ body:
id: uptime-kuma-version
attributes:
label: "🐻 Uptime-Kuma Version"
description: "Which version of Uptime-Kuma are you running? Please do NOT provide the docker tag such as latest or 1"
description:
"Which version of Uptime-Kuma are you running? Please do NOT provide the
docker tag such as latest or 1"
placeholder: "Ex. 1.10.0"
validations:
required: true
@ -61,7 +85,9 @@ body:
id: operating-system
attributes:
label: "💻 Operating System and Arch"
description: "Which OS is your server/device running on? (For Replit, please do not report this bug)"
description:
"Which OS is your server/device running on? (For Replit, please do not
report this bug)"
placeholder: "Ex. Ubuntu 20.04 x64 "
validations:
required: true
@ -84,17 +110,19 @@ body:
- **Filesystem used to store the database on**: Windows/ZFS/btrfs/NFSv3 on a SSD/HDD/eMMC
- **number of monitors**: 42
value: |
- Runtime:
- Database:
- Filesystem used to store the database on:
- number of monitors:
- Runtime:
- Database:
- Filesystem used to store the database on:
- number of monitors:
validations:
required: true
- type: textarea
id: logs
attributes:
label: "📝 Relevant log output"
description: Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.
description:
Please copy and paste any relevant log output. This will be
automatically formatted into code, so no need for backticks.
render: shell
validations:
required: false

66
.github/ISSUE_TEMPLATE/feature_request.yaml vendored
View file

@ -1,66 +0,0 @@
name: 🚀 Feature Request
description: "Submit a proposal for a new feature"
#title: "[Feature] "
labels: [feature-request]
body:
- type: textarea
id: related-issues
validations:
required: true
attributes:
label: "📑 I have found these related issues/pull requests"
description: "Search related issues by clicking [HERE](https://github.com/louislam/uptime-kuma/issues?q=) and explain what the difference between them or explain that you are unable to find any related issues"
placeholder: "Related to #1 by also touching the ... system. They should not be merged because ..."
- type: dropdown
id: feature-area
attributes:
label: "🏷️ Feature Request Type"
description: "What kind of feature request is this?"
multiple: true
options:
- API / automation options
- New notification-provider
- Change to existing notification-provider
- New monitor
- Change to existing monitor
- Dashboard
- Status-page
- Maintenance
- Deployment
- Certificate expiry
- Settings
- Other
validations:
required: true
- type: textarea
id: feature-description
validations:
required: true
attributes:
label: "🔖 Feature description"
description: "A clear and concise description of what the feature request is."
placeholder: "You should add ..."
- type: textarea
id: solution
validations:
required: true
attributes:
label: "✔️ Solution"
description: "A clear and concise description of what you want to happen."
placeholder: "In my use-case, ..."
- type: textarea
id: alternatives
validations:
required: false
attributes:
label: "❓ Alternatives"
description: "A clear and concise description of any alternative solutions or features you've considered."
placeholder: "I have considered ..."
- type: textarea
id: additional-context
validations:
required: false
attributes:
label: "📝 Additional Context"
description: "Add any other context or screenshots about the feature request here."
placeholder: "..."

96
.github/ISSUE_TEMPLATE/feature_request.yml vendored Normal file
View file

@ -0,0 +1,96 @@
---
name: 🚀 Feature Request
description: "Submit a proposal for a new feature"
# title: "[Feature] "
labels: ["feature-request", "P3-low"]
body:
- type: "markdown"
attributes:
value: |
## **❗ Important: Temporary Delay in Feature Requests and Pull Request Reviews**
**At this time, we may be slower to respond to new feature requests and review pull requests. Existing requests and PRs will remain in the backlog but may not be prioritized immediately.**
- **Reason**: Our current focus is on addressing bugs, improving system performance, and implementing essential updates. This will help stabilize the project and ensure smoother management.
- **Impact**: While no new feature requests or pull requests are being outright rejected, there may be significant delays in reviews. We encourage the community to help by reviewing PRs or assisting other users in the meantime.
- **What You Can Do**: If you're interested in contributing, reviewing open PRs or offering support to other users is greatly appreciated. All feature requests and PRs will be revisited once the suspension period is lifted.
We appreciate your patience and understanding as we continue to improve Uptime Kuma.
## **❗ Important: Please Avoid Unnecessary Pinging of Maintainers**
**We kindly ask users to refrain from pinging maintainers unless absolutely necessary. Pings should be reserved for critical issues or urgent matters that require immediate attention.**
- **Why**: To help maintainers focus on high-priority tasks, we kindly request that unnecessary or repeated pings be minimized. This will help ensure quicker responses for matters that truly need attention.
- **What This Means**: Non-urgent pings may be ignored or addressed later. Please assess the urgency of your request before pinging a maintainer.
- type: textarea
id: related-issues
validations:
required: true
attributes:
label: "📑 I have found these related issues/pull requests"
description:
"Search related issues by clicking
[HERE](https://github.com/louislam/uptime-kuma/issues?q=) and explain
what the difference between them or explain that you are unable to find
any related issues"
placeholder:
"Related to #1 by also touching the ... system. They should not be
merged because ..."
- type: dropdown
id: feature-area
attributes:
label: "🏷️ Feature Request Type"
description: "What kind of feature request is this?"
multiple: true
options:
- API / automation options
- New notification-provider
- Change to existing notification-provider
- New monitor
- Change to existing monitor
- Dashboard
- Status-page
- Maintenance
- Deployment
- Certificate expiry
- Settings
- Other
validations:
required: true
- type: textarea
id: feature-description
validations:
required: true
attributes:
label: "🔖 Feature description"
description:
"A clear and concise description of what the feature request is."
placeholder: "You should add ..."
- type: textarea
id: solution
validations:
required: true
attributes:
label: "✔️ Solution"
description: "A clear and concise description of what you want to happen."
placeholder: "In my use-case, ..."
- type: textarea
id: alternatives
validations:
required: false
attributes:
label: "❓ Alternatives"
description:
"A clear and concise description of any alternative solutions or
features you've considered."
placeholder: "I have considered ..."
- type: textarea
id: additional-context
validations:
required: false
attributes:
label: "📝 Additional Context"
description:
"Add any other context or screenshots about the feature request here."
placeholder: "..."

2
.github/ISSUE_TEMPLATE/security_issue.yml vendored
View file

@ -3,7 +3,7 @@ name: "🛡️ Security Issue"
description: |
Notify Louis Lam about a security concern. Please do NOT include any sensitive details in this issue.
# title: "Security Issue"
labels: [security]
labels: ["security", "P1-high"]
assignees: [louislam]
body:
- type: "markdown"

18
.github/PULL_REQUEST_TEMPLATE.md vendored
View file

@ -1,10 +1,20 @@
⚠️⚠️⚠️ Since we do not accept all types of pull requests and do not want to waste your time. Please be sure that you have read pull request rules:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma
**⚠️ Please Note: We do not accept all types of pull requests, and we want to ensure we don’t waste your time. Before submitting, make sure you have read our pull request guidelines: [Pull Request Rules](https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma)**
Check the box below if you understand [x]:
Tick the checkbox if you understand [x]:
- [ ] I have read and understand the pull request rules.
# Description
## **❗ Important: Temporary Delay in Feature Requests and Pull Request Reviews**
**At this time, we may be slower to respond to new feature requests and review pull requests. Existing requests and PRs will remain in the backlog but may not be prioritized immediately.**
- **Reason**: Our current focus is on addressing bugs, improving system performance, and implementing essential updates. This will help stabilize the project and ensure smoother management.
- **Impact**: While no new feature requests or pull requests are being outright rejected, there may be significant delays in reviews. We encourage the community to help by reviewing PRs or assisting other users in the meantime.
- **What You Can Do**: If you're interested in contributing, reviewing open PRs or offering support to other users is greatly appreciated. All feature requests and PRs will be revisited once the suspension period is lifted.
We appreciate your patience and understanding as we continue to improve Uptime Kuma.
## Description
Fixes #(issue)

219
.github/REVIEW_PROCESS.md vendored Normal file
View file

@ -0,0 +1,219 @@
# Review Process for Uptime Kuma
**Note:** This Review Process document is a work in progress. Updates and
improvements are being made, so please check back regularly for the latest
version.
## Preparation for Reviewing a PR
### Read the PR description carefully
Make sure you understand what the PR is trying to solve or implement. This could
be a bug fix, a new feature, or a refactor.
### Check the linked issues
If the PR has a linked issue, read it to better understand the context and the
reason for the change.
### Check the test coverage
Make sure relevant tests have been added or modified. If the PR adds new
functionality, there should be tests covering the change.
## General Review
### Code formatting and style
Check if the code adheres to the agreed style guidelines of the project (e.g.,
PEP8 for Python, Airbnb style for JavaScript, etc.). Make sure there are no
unused imports, variables, or code fragments in the PR.
- [Project Style](https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#project-styles)
- [Coding Style](https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md#coding-styles)
### Readability and maintainability
Is the code understandable to other developers? Ensure that complex parts are
well-documented with comments. Are variables and functions clearly named, and
does the code follow a consistent naming convention? Additionally, check if the
code is maintainable:
- Is it unnecessarily complex? Could it be simplified?
- Does it follow the **[Single Responsibility Principle (SRP)]**?
[Single Responsibility Principle (SRP)]: https://www.geeksforgeeks.org/single-responsibility-in-solid-design-principle/
### Documentation
Is the PR well documented? Check if the descriptions of functions, parameters,
and return values are present. Are there any changes needed to the README or
other documentation, for example, if new features or configurations are
introduced?
## Functional Review
### Testing
Ensure that the new code is properly tested. This includes unit tests,
integration tests, and if necessary, end-to-end tests.
### Test results
Did all tests pass in the CI pipeline (e.g., GitHub Actions, Travis, CircleCI)?
### Testing in different environments
If the changes depend on certain environments or configurations, verify that the
code has been tested in various environments (e.g., local development, staging,
production).
- [How to test Pull Requests](https://github.com/louislam/uptime-kuma/wiki/Test-Pull-Requests)
### Edge cases and regressions
- Are there test cases for possible edge cases?
- Could this change introduce regressions in other parts of the system?
## Security
### Security issues
Check for potential security problems, such as SQL injection, XSS attacks, or
unsafe API calls. Are there passwords, tokens, or other sensitive data left in
the code by mistake?
### Authentication and authorization
Is access to sensitive data or functionality properly secured? Check that the
correct authorization and authentication mechanisms are in place.
### Security Best Practices
- Ensure that the code is free from common vulnerabilities like **SQL
injection**, **XSS attacks**, and **insecure API calls**.
- Check for proper encryption of sensitive data, and ensure that **passwords**
or **API tokens** are not hardcoded in the code.
## Performance
### Performance impact
Check if the changes negatively impact performance. This can include factors
like load times, memory usage, or other performance aspects.
### Use of external libraries
- Have the right libraries been chosen?
- Are there unnecessary dependencies that might reduce performance or increase
code complexity?
- Are these dependencies actively maintained and free of known vulnerabilities?
### Performance Best Practices
- **Measure performance** using tools like Lighthouse or profiling libraries.
- **Avoid unnecessary dependencies** that may bloat the codebase.
- Ensure that the **code does not degrade the user experience** (e.g., by
increasing load times or memory consumption).
## Compliance and Integration
### Alignment with the project
Are the changes consistent with the project goals and requirements? Ensure the
PR aligns with the architecture and design principles of the project.
### Integration
If the PR depends on other PRs or changes, verify that they integrate well with
the rest of the project. Ensure the code does not cause conflicts with other
active PRs.
### Backward compatibility
Does the change break compatibility with older versions of the software or
dependencies? If so, is there a migration plan in place?
## Logging and Error Handling
### Proper error handling
- Are errors properly caught and handled instead of being silently ignored?
- Are exceptions used appropriately?
### Logging
- Is sufficient logging included for debugging and monitoring?
- Is there excessive logging that could affect performance?
## Accessibility (for UI-related changes)
If the PR affects the user interface, ensure that it meets accessibility
standards:
- Can users navigate using only the keyboard?
- Are screen readers supported?
- Is there proper color contrast for readability?
- Are there **WCAG** (Web Content Accessibility Guidelines) compliance issues?
- Use tools like **Axe** or **Lighthouse** to evaluate accessibility.
## Providing Feedback
### Constructive feedback
Provide clear, constructive feedback on what is good and what can be improved.
If improvements are needed, be specific about what should change.
### Clarity and collaboration
Ensure your feedback is friendly and open, so the team member who submitted the
PR feels supported and motivated to make improvements.
## Go/No-Go Decision ━ For Maintainers only
### Go
If the code has no issues and meets the project requirements, approve it (and
possibly merge it).
### No-Go
If there are significant issues, such as missing tests, security
vulnerabilities, or performance problems, request the necessary changes before
the PR can be approved. Some examples of **significant issues** include:
- Missing tests for new functionality.
- Identified **security vulnerabilities**.
- Code changes that break **backward compatibility** without a proper migration
plan.
- Code that causes **major performance regressions** (e.g., high CPU/memory
usage).
## After the Review ━ For Maintainers only
### Reordering and merging
Once the necessary changes have been made and the PR is approved, the code can
be merged into the main branch (e.g., `main` or `master`).
### Testing after merging
Ensure that the build passes after merging the PR, and re-test the functionality
in the production environment if necessary.
## Follow-up ━ For Maintainers only
### Communication with team members
If the PR has long-term technical or functional implications, communicate the
changes to the team.
### Monitoring
Continue monitoring the production environment for any unexpected issues that
may arise after the code has been merged.
---
This process ensures that PRs are systematically and thoroughly reviewed,
improving overall code quality.