mirror of
https://github.com/louislam/uptime-kuma.git
synced 2025-04-06 12:53:59 -04:00
Merge branch 'master' into websocket_test
This commit is contained in:
Frank Elsinga
GitHub
commit
1f058cb654
75
.github/ISSUE_TEMPLATE/ask-for-help.yaml
vendored
75
.github/ISSUE_TEMPLATE/ask-for-help.yaml
vendored
@ -1,75 +0,0 @@
|
||||
name: "❓ Ask for help"
|
||||
description: "Submit any question related to Uptime Kuma"
|
||||
#title: "[Help] "
|
||||
labels: [help]
|
||||
body:
|
||||
- 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=)"
|
||||
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.
|
||||
options:
|
||||
- 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
|
||||
validations:
|
||||
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"
|
||||
placeholder: "Describe what are you asking for..."
|
||||
- type: textarea
|
||||
id: error-msg
|
||||
validations:
|
||||
required: false
|
||||
attributes:
|
||||
label: "📝 Error Message(s) or Log"
|
||||
- type: input
|
||||
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"
|
||||
placeholder: "Ex. 1.10.0"
|
||||
validations:
|
||||
required: true
|
||||
- type: input
|
||||
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)"
|
||||
placeholder: "Ex. Ubuntu 20.04 x86"
|
||||
validations:
|
||||
required: true
|
||||
- type: input
|
||||
id: browser-vendor
|
||||
attributes:
|
||||
label: "🌐 Browser"
|
||||
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
|
||||
- type: textarea
|
||||
id: deployment-info
|
||||
attributes:
|
||||
label: "🖥️ Deployment Environment"
|
||||
description: |
|
||||
examples:
|
||||
- **Runtime**: Docker 20.10.9 / nodejs 14.18.0 / K8S via ... v1.3.3 / ..
|
||||
- **Database**: sqlite/embedded mariadb/external mariadb
|
||||
- **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:
|
||||
validations:
|
||||
required: true
|
||||
120
.github/ISSUE_TEMPLATE/ask_for_help.yml
vendored
Normal file
120
.github/ISSUE_TEMPLATE/ask_for_help.yml
vendored
Normal file
@ -0,0 +1,120 @@
|
||||
---
|
||||
name: ❓ Ask for help
|
||||
description: |
|
||||
Submit any question related to Uptime Kuma
|
||||
#title: "[Help]"
|
||||
labels: ["help", "P3-low"]
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
🚫 **We kindly ask you to refrain from pinging maintainers unless absolutely necessary. Pings are reserved for critical/urgent issues that require immediate attention.**
|
||||
|
||||
**Why**: Reserving pings for urgent matters ensures maintainers can prioritize critical tasks effectively
|
||||
|
||||
- type: checkboxes
|
||||
id: no-duplicate-question
|
||||
attributes:
|
||||
label: ⚠️ Please verify that your question has not already been reported
|
||||
description: |
|
||||
To avoid duplicate reports, please search for any existing issues before submitting a new one. You can find the list of existing issues **[HERE](https://github.com/louislam/uptime-kuma/issues?q=is%3Aissue%20sort%3Acreated-desc%20)**.
|
||||
options:
|
||||
- label: |
|
||||
I have searched the [existing issues](https://github.com/louislam/uptime-kuma/issues?q=is%3Aissue%20sort%3Acreated-desc%20) and found no similar reports.
|
||||
required: true
|
||||
|
||||
- type: checkboxes
|
||||
id: security-policy
|
||||
attributes:
|
||||
label: 🛡️ Security Policy
|
||||
description: |
|
||||
Please review and acknowledge the Security Policy before reporting any security-related issues or bugs. You can find the full Security Policy **[HERE](https://github.com/louislam/uptime-kuma/security/policy)**.
|
||||
options:
|
||||
- label: |
|
||||
I have read and agree to Uptime Kuma's [Security Policy](https://github.com/louislam/uptime-kuma/security/policy).
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: steps-to-reproduce
|
||||
validations:
|
||||
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
|
||||
placeholder: |
|
||||
Describe what are you asking for ...
|
||||
|
||||
- type: textarea
|
||||
id: error-msg
|
||||
attributes:
|
||||
label: 📝 Error Message(s) or Log
|
||||
description: |
|
||||
Please copy and paste any relevant log output. This will be automatically formatted into code, so no need for backticks.
|
||||
render: bash session
|
||||
validations:
|
||||
required: false
|
||||
|
||||
- type: input
|
||||
id: uptime-kuma-version
|
||||
attributes:
|
||||
label: 🐻 Uptime-Kuma Version
|
||||
description: |
|
||||
What version of Uptime-Kuma are you running? Please do not provide Docker tags like `latest` or `1`.
|
||||
placeholder: |
|
||||
e.g., 1.23.16 or 2.0.0-beta.2
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: input
|
||||
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)
|
||||
placeholder: |
|
||||
e.g., Ubuntu Server 24.04.2 LTS (GNU/Linux 6.8.0-55-generic x86_64)
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: input
|
||||
id: browser-vendor
|
||||
attributes:
|
||||
label: 🌐 Browser
|
||||
description: |
|
||||
Which browser are you running on? (For Replit, please do not report this bug)
|
||||
placeholder: |
|
||||
e.g., Google Chrome 134.0.6998.183 (Official Build) (64-bit)
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: deployment-info
|
||||
attributes:
|
||||
label: 🖥️ Deployment Environment
|
||||
description: |
|
||||
Provide details about the deployment environment, including runtime components, databases, and storage configurations. This will
|
||||
help assess the infrastructure and identify any potential compatibility requirements.
|
||||
|
||||
**Remove any fields that do not apply to your setup.**
|
||||
value: |
|
||||
- **Runtime Environment**:
|
||||
- Docker: Version `X.X.X` (Build `Y.Y.Y`)
|
||||
- Docker Compose: Version `X.X.X`
|
||||
- Portainer (BE/CE): Version `X.X.X` (LTS: Yes/No)
|
||||
- MariaDB: Version `X.X.X` (LTS: Yes/No)
|
||||
- Node.js: Version `X.X.X` (LTS: Yes/No)
|
||||
- Kubernetes (K3S/K8S): Version `X.X.X` (LTS: Yes/No, via `[method/tool]`)
|
||||
- **Database**:
|
||||
- SQLite: Embedded
|
||||
- MariaDB: Embedded/External
|
||||
- **Database Storage**:
|
||||
- **Filesystem**:
|
||||
- Linux: ext4/XFS/Btrfs/ZFS/F2FS
|
||||
- macOS: APFS/ HFS+
|
||||
- Windows: NTFS/ReFS
|
||||
- **Storage Medium**: HDD/eMMC/SSD/NVMe
|
||||
- **Uptime Kuma Setup**:
|
||||
- Number of monitors: `X`
|
||||
validations:
|
||||
required: true
|
||||
100
.github/ISSUE_TEMPLATE/bug_report.yaml
vendored
100
.github/ISSUE_TEMPLATE/bug_report.yaml
vendored
@ -1,100 +0,0 @@
|
||||
name: "🐛 Bug Report"
|
||||
description: "Submit a bug report to help us improve"
|
||||
#title: "[Bug] "
|
||||
labels: [bug]
|
||||
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: checkboxes
|
||||
attributes:
|
||||
label: "🛡️ Security Policy"
|
||||
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)
|
||||
required: true
|
||||
- type: textarea
|
||||
id: description
|
||||
validations:
|
||||
required: false
|
||||
attributes:
|
||||
label: "Description"
|
||||
description: "You could also upload screenshots"
|
||||
- type: textarea
|
||||
id: steps-to-reproduce
|
||||
validations:
|
||||
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"
|
||||
placeholder: "..."
|
||||
- type: textarea
|
||||
id: expected-behavior
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: "👀 Expected behavior"
|
||||
description: "What did you think would happen?"
|
||||
placeholder: "..."
|
||||
- type: textarea
|
||||
id: actual-behavior
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: "😓 Actual Behavior"
|
||||
description: "What actually happen?"
|
||||
placeholder: "..."
|
||||
- type: input
|
||||
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"
|
||||
placeholder: "Ex. 1.10.0"
|
||||
validations:
|
||||
required: true
|
||||
- type: input
|
||||
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)"
|
||||
placeholder: "Ex. Ubuntu 20.04 x64 "
|
||||
validations:
|
||||
required: true
|
||||
- type: input
|
||||
id: browser-vendor
|
||||
attributes:
|
||||
label: "🌐 Browser"
|
||||
description: "Which browser are you running on?"
|
||||
placeholder: "Ex. Google Chrome 95.0.4638.69"
|
||||
validations:
|
||||
required: true
|
||||
- type: textarea
|
||||
id: deployment-info
|
||||
attributes:
|
||||
label: "🖥️ Deployment Environment"
|
||||
description: |
|
||||
examples:
|
||||
- **Runtime**: Docker 20.10.9 / nodejs 18.17.1 / K8S via ... v1.3.3 / ..
|
||||
- **Database**: sqlite/embedded mariadb/external mariadb
|
||||
- **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:
|
||||
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.
|
||||
render: shell
|
||||
validations:
|
||||
required: false
|
||||
154
.github/ISSUE_TEMPLATE/bug_report.yml
vendored
Normal file
154
.github/ISSUE_TEMPLATE/bug_report.yml
vendored
Normal file
@ -0,0 +1,154 @@
|
||||
---
|
||||
name: 🐛 Bug Report
|
||||
description: |
|
||||
Submit a bug report to help us improve
|
||||
#title: "[Bug]"
|
||||
labels: ["bug", "P2-medium"]
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
🚫 **We kindly ask you to refrain from pinging maintainers unless absolutely necessary. Pings are reserved for critical/urgent issues that require immediate attention.**
|
||||
|
||||
**Why**: Reserving pings for urgent matters ensures maintainers can prioritize critical tasks effectively
|
||||
|
||||
- type: textarea
|
||||
id: related-issues
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: 📑 I have found these related issues/pull requests
|
||||
description: |
|
||||
Please search for related **[ISSUES](https://github.com/louislam/uptime-kuma/issues?q=is%3Aissue%20sort%3Acreated-desc)**
|
||||
and **[PULL REQUESTS](https://github.com/louislam/uptime-kuma/pulls?q=is%3Apr+sort%3Acreated-desc+)**.
|
||||
Explain the differences between them or clarify if you were unable to find any related issues/pull requests.
|
||||
placeholder: |
|
||||
Example: This relates to issue #1, which also affects the ... system. It should not be merged because ...
|
||||
|
||||
- type: checkboxes
|
||||
id: security-policy
|
||||
attributes:
|
||||
label: 🛡️ Security Policy
|
||||
description: |
|
||||
Please review and acknowledge the Security Policy before reporting any security-related issues or bugs. You can find the full Security Policy **[HERE](https://github.com/louislam/uptime-kuma/security/policy)**.
|
||||
options:
|
||||
- label: |
|
||||
I have read and agree to Uptime Kuma's [Security Policy](https://github.com/louislam/uptime-kuma/security/policy).
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: description
|
||||
validations:
|
||||
required: false
|
||||
attributes:
|
||||
label: 📝 Description
|
||||
description: |
|
||||
You could also upload screenshots
|
||||
|
||||
- type: textarea
|
||||
id: steps-to-reproduce
|
||||
validations:
|
||||
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
|
||||
placeholder: |
|
||||
...
|
||||
|
||||
- type: textarea
|
||||
id: expected-behavior
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: 👀 Expected behavior
|
||||
description: |
|
||||
What did you think would happen?
|
||||
placeholder: |
|
||||
...
|
||||
|
||||
- type: textarea
|
||||
id: actual-behavior
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: 😓 Actual Behavior
|
||||
description: |
|
||||
What actually happen?
|
||||
placeholder: |
|
||||
...
|
||||
|
||||
- type: input
|
||||
id: uptime-kuma-version
|
||||
attributes:
|
||||
label: 🐻 Uptime-Kuma Version
|
||||
description: |
|
||||
What version of Uptime-Kuma are you running? Please do not provide Docker tags like `latest` or `1`.
|
||||
placeholder: |
|
||||
e.g., 1.23.16 or 2.0.0-beta.2
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: input
|
||||
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)
|
||||
placeholder: |
|
||||
e.g., Ubuntu Server 24.04.2 LTS (GNU/Linux 6.8.0-55-generic x86_64)
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: input
|
||||
id: browser-vendor
|
||||
attributes:
|
||||
label: 🌐 Browser
|
||||
description: |
|
||||
Which browser are you running on?
|
||||
placeholder: |
|
||||
e.g., Google Chrome 134.0.6998.183 (Official Build) (64-bit)
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: deployment-info
|
||||
attributes:
|
||||
label: 🖥️ Deployment Environment
|
||||
description: |
|
||||
Provide details about the deployment environment, including runtime components, databases, and storage configurations. This will
|
||||
help assess the infrastructure and identify any potential compatibility requirements.
|
||||
|
||||
**Remove any fields that do not apply to your setup.**
|
||||
value: |
|
||||
- **Runtime Environment**:
|
||||
- Docker: Version `X.X.X` (Build `Y.Y.Y`)
|
||||
- Docker Compose: Version `X.X.X`
|
||||
- Portainer (BE/CE): Version `X.X.X` (LTS: Yes/No)
|
||||
- MariaDB: Version `X.X.X` (LTS: Yes/No)
|
||||
- Node.js: Version `X.X.X` (LTS: Yes/No)
|
||||
- Kubernetes (K3S/K8S): Version `X.X.X` (LTS: Yes/No, via `[method/tool]`)
|
||||
- **Database**:
|
||||
- SQLite: Embedded
|
||||
- MariaDB: Embedded/External
|
||||
- **Database Storage**:
|
||||
- **Filesystem**:
|
||||
- Linux: ext4/XFS/Btrfs/ZFS/F2FS
|
||||
- macOS: APFS/ HFS+
|
||||
- Windows: NTFS/ReFS
|
||||
- **Storage Medium**: HDD/eMMC/SSD/NVMe
|
||||
- **Uptime Kuma Setup**:
|
||||
- Number of monitors: `X`
|
||||
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.
|
||||
render: bash session
|
||||
validations:
|
||||
required: false
|
||||
66
.github/ISSUE_TEMPLATE/feature_request.yaml
vendored
66
.github/ISSUE_TEMPLATE/feature_request.yaml
vendored
@ -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: "..."
|
||||
106
.github/ISSUE_TEMPLATE/feature_request.yml
vendored
Normal file
106
.github/ISSUE_TEMPLATE/feature_request.yml
vendored
Normal file
@ -0,0 +1,106 @@
|
||||
---
|
||||
name: 🚀 Feature Request
|
||||
description: |
|
||||
Submit a proposal for a new feature
|
||||
# title: "[Feature]"
|
||||
labels: ["feature-request", "P3-low"]
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
## ❗Important Announcement
|
||||
|
||||
### 🚧 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 by following our [Review Guidelines](../REVIEW_GUIDELINES.md) or offering help 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.
|
||||
|
||||
### 🚫 Please Avoid Unnecessary Pinging of Maintainers
|
||||
|
||||
**We kindly ask you to refrain from pinging maintainers unless absolutely necessary. Pings are reserved for critical/urgent pull requests that require immediate attention.**
|
||||
|
||||
**Why**: Reserving pings for urgent matters ensures maintainers can prioritize critical tasks effectively.
|
||||
- type: textarea
|
||||
id: related-issues
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: 📑 I have found these related issues/pull requests
|
||||
description: |
|
||||
Please search for related **[ISSUES](https://github.com/louislam/uptime-kuma/issues?q=is%3Aissue%20sort%3Acreated-desc)**
|
||||
and **[PULL REQUESTS](https://github.com/louislam/uptime-kuma/pulls?q=is%3Apr+sort%3Acreated-desc+)**.
|
||||
Explain the differences between them or clarify if you were unable to find any related issues/pull requests.
|
||||
placeholder: |
|
||||
Example: This relates to issue #1, which also affects the ... system. It 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: |
|
||||
...
|
||||
16
.github/ISSUE_TEMPLATE/security_issue.yml
vendored
16
.github/ISSUE_TEMPLATE/security_issue.yml
vendored
@ -1,19 +1,19 @@
|
||||
---
|
||||
name: "🛡️ Security Issue"
|
||||
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"
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
## **⚠️ Report a Security Vulnerability**
|
||||
## ❗ IMPORTANT: DO NOT SHARE VULNERABILITY DETAILS HERE
|
||||
|
||||
### **IMPORTANT: DO NOT SHARE VULNERABILITY DETAILS HERE**
|
||||
### ⚠️ Report a Security Vulnerability
|
||||
|
||||
If you have discovered a security vulnerability, please report it securely using the GitHub Security Advisory.
|
||||
**If you have discovered a security vulnerability, please report it securely using the GitHub Security Advisory.**
|
||||
|
||||
**Note**: This issue is only for notifying the maintainers of the repository, as the GitHub Security Advisory does not automatically send notifications.
|
||||
|
||||
@ -34,12 +34,12 @@ body:
|
||||
|
||||
Once you've created your advisory, please share the URL below. This will notify Louis Lam and enable them to take the appropriate action.
|
||||
|
||||
- type: "textarea"
|
||||
- type: textarea
|
||||
id: github-advisory-url
|
||||
validations:
|
||||
required: true
|
||||
attributes:
|
||||
label: "GitHub Advisory URL for @louislam"
|
||||
label: GitHub Advisory URL for @louislam
|
||||
placeholder: |
|
||||
Please paste the GitHub Advisory URL here. Only the URL is required.
|
||||
Example: https://github.com/louislam/uptime-kuma/security/advisories/GHSA-8h5r-7t6l-q3kz
|
||||
|
||||
135
.github/PULL_REQUEST_TEMPLATE.md
vendored
135
.github/PULL_REQUEST_TEMPLATE.md
vendored
@ -1,33 +1,122 @@
|
||||
⚠️⚠️⚠️ 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](../CONTRIBUTING.md#can-i-create-a-pull-request-for-uptime-kuma)**
|
||||
|
||||
Tick the checkbox if you understand [x]:
|
||||
- [ ] I have read and understand the pull request rules.
|
||||
## ❗ Important Announcement
|
||||
|
||||
# Description
|
||||
<details><summary>Click here for more details:</summary>
|
||||
</p>
|
||||
|
||||
Fixes #(issue)
|
||||
### 🚧 Temporary Delay in Feature Requests and Pull Request Reviews
|
||||
|
||||
## Type of change
|
||||
**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.**
|
||||
|
||||
Please delete any options that are not relevant.
|
||||
- **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 by following our [Review Guidelines](REVIEW_GUIDELINES.md) or offering support to other users is greatly appreciated. All feature requests and PRs will be revisited once the suspension period is lifted.
|
||||
|
||||
- Bug fix (non-breaking change which fixes an issue)
|
||||
- User interface (UI)
|
||||
- New feature (non-breaking change which adds functionality)
|
||||
- Breaking change (a fix or feature that would cause existing functionality to not work as expected)
|
||||
- Other
|
||||
- This change requires a documentation update
|
||||
We appreciate your patience and understanding as we continue to improve Uptime Kuma.
|
||||
|
||||
## Checklist
|
||||
### 🚫 Please Avoid Unnecessary Pinging of Maintainers
|
||||
|
||||
- [ ] My code follows the style guidelines of this project
|
||||
- [ ] I ran ESLint and other linters for modified files
|
||||
- [ ] I have performed a self-review of my own code and tested it
|
||||
- [ ] I have commented my code, particularly in hard-to-understand areas (including JSDoc for methods)
|
||||
- [ ] My changes generates no new warnings
|
||||
- [ ] My code needed automated testing. I have added them (this is optional task)
|
||||
**We kindly ask you to refrain from pinging maintainers unless absolutely necessary. Pings are reserved for critical/urgent pull requests that require immediate attention.**
|
||||
|
||||
## Screenshots (if any)
|
||||
**Why**: Reserving pings for urgent matters ensures maintainers can prioritize critical tasks effectively.
|
||||
|
||||
Please do not use any external image service. Instead, just paste in or drag and drop the image here, and it will be uploaded automatically.
|
||||
</p>
|
||||
</details>
|
||||
|
||||
## 📋 Overview
|
||||
|
||||
Provide a clear summary of the purpose and scope of this pull request:
|
||||
|
||||
- **What problem does this pull request address?**
|
||||
|
||||
- Please provide a detailed explanation here.
|
||||
|
||||
- **What features or functionality does this pull request introduce or enhance?**
|
||||
|
||||
- Please provide a detailed explanation here.
|
||||
|
||||
## 🔄 Changes
|
||||
|
||||
### 🛠️ Type of change
|
||||
|
||||
<!-- Please select all options that apply -->
|
||||
|
||||
- [ ] 🐛 Bugfix (a non-breaking change that resolves an issue)
|
||||
- [ ] ✨ New feature (a non-breaking change that adds new functionality)
|
||||
- [ ] ⚠️ Breaking change (a fix or feature that alters existing functionality in a way that could cause issues)
|
||||
- [ ] 🎨 User Interface (UI) updates
|
||||
- [ ] 📄 New Documentation (addition of new documentation)
|
||||
- [ ] 📄 Documentation Update (modification of existing documentation)
|
||||
- [ ] 📄 Documentation Update Required (the change requires updates to related documentation)
|
||||
- [ ] 🔧 Other (please specify):
|
||||
- Provide additional details here.
|
||||
|
||||
## 🔗 Related Issues
|
||||
|
||||
<!--
|
||||
Please link any GitHub issues or tasks that this pull request addresses. Use the appropriate issue numbers or links.
|
||||
|
||||
**Note**: Include only issues directly related to this PR. Remove any irrelevant reference.
|
||||
-->
|
||||
|
||||
- Relates to #issue-number
|
||||
- Resolves #issue-number
|
||||
- Fixes #issue-number
|
||||
|
||||
## 📄 Checklist *
|
||||
|
||||
<!-- Please select all options that apply -->
|
||||
|
||||
- [ ] 🔍 My code adheres to the style guidelines of this project.
|
||||
- [ ] ✅ I ran ESLint and other code linters for modified files.
|
||||
- [ ] 🛠️ I have reviewed and tested my code.
|
||||
- [ ] 📝 I have commented my code, especially in hard-to-understand areas (e.g., using JSDoc for methods).
|
||||
- [ ] ⚠️ My changes generate no new warnings.
|
||||
- [ ] 🤖 My code needed automated testing. I have added them (this is an optional task).
|
||||
- [ ] 📄 Documentation updates are included (if applicable).
|
||||
- [ ] 🔒 I have considered potential security impacts and mitigated risks.
|
||||
- [ ] 🧰 Dependency updates are listed and explained.
|
||||
- [ ] 📚 I have read and understood the [Pull Request guidelines](../CONTRIBUTING.md#recommended-pull-request-guideline).
|
||||
|
||||
## 📷 Screenshots or Visual Changes
|
||||
|
||||
<!--
|
||||
Please upload the image directly here by pasting it or dragging and dropping. Avoid using external image services as the image will be uploaded automatically.
|
||||
|
||||
If this pull request introduces visual changes, please provide the following details.
|
||||
If not, remove this section.
|
||||
-->
|
||||
|
||||
- **UI Modifications**: Highlight any changes made to the user interface.
|
||||
- **Before & After**: Include screenshots or comparisons (if applicable).
|
||||
|
||||
| Event | Before | After |
|
||||
| ------------------ | --------------------- | -------------------- |
|
||||
| `UP` |  |  |
|
||||
| `DOWN` |  |  |
|
||||
| Certificate-expiry |  |  |
|
||||
| Testing |  |  |
|
||||
|
||||
## ℹ️ Additional Context
|
||||
|
||||
Provide any relevant details to assist reviewers in understanding the changes.
|
||||
|
||||
<details><summary>Click here for more details:</summary>
|
||||
</p>
|
||||
|
||||
**Key Considerations**:
|
||||
|
||||
- **Design decisions** – Key choices or trade-offs made during development.
|
||||
- **Alternative solutions** – Approaches considered but not implemented, along with reasons.
|
||||
- **Relevant links** – Specifications, discussions, or resources that provide context.
|
||||
- **Dependencies** – Related pull requests or issues that must be resolved before merging.
|
||||
- **Additional context** – Any other details that may help reviewers understand the changes.
|
||||
|
||||
Provide details here
|
||||
|
||||
## 💬 Requested Feedback
|
||||
|
||||
<!-- If a part of our docs is unclear, you are unsure how to do something/.. this is where we would appreciate your feedback -->
|
||||
|
||||
- `Mention documents needing feedback here`
|
||||
|
||||
224
.github/REVIEW_GUIDELINES.md
vendored
Normal file
224
.github/REVIEW_GUIDELINES.md
vendored
Normal file
@ -0,0 +1,224 @@
|
||||
# Uptime Kuma Review Guidelines
|
||||
|
||||
> [!NOTE]
|
||||
> These review guidelines are a work in progress, and are frequently
|
||||
> updated and improved, so please check back frequently for the latest version.
|
||||
|
||||
## Preparing for a PR Review
|
||||
|
||||
### 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 style guidelines of the project. Make sure
|
||||
there are no unused imports, variables, `console.log` for debugging in the PR.
|
||||
|
||||
- [Project Style](../CONTRIBUTING.md#project-styles)
|
||||
- [Coding Style](../CONTRIBUTING.md#coding-styles)
|
||||
|
||||
### Readability and maintainability
|
||||
|
||||
Is the code easy to understand for other developers? Make sure complex parts are
|
||||
explained with comments about **_why_** something is done, and use clear names
|
||||
to show **_how_**. Are variables and functions well-named, and is there a
|
||||
consistent naming style? Also, 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.
|
||||
|
||||
<details><summary><b>For Maintainers only</b> (click to expand)</summary>
|
||||
<p>
|
||||
|
||||
## Go/No-Go Decision
|
||||
|
||||
### 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
|
||||
|
||||
### 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
|
||||
|
||||
### 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.
|
||||
|
||||
</p>
|
||||
</details>
|
||||
|
||||
---
|
||||
|
||||
This process ensures that PRs are systematically and thoroughly reviewed,
|
||||
improving overall code quality.
|
||||
@ -6,8 +6,8 @@ We as members, contributors, and leaders pledge to make participation in our
|
||||
community a harassment-free experience for everyone, regardless of age, body
|
||||
size, visible or invisible disability, ethnicity, sex characteristics, gender
|
||||
identity and expression, level of experience, education, socio-economic status,
|
||||
nationality, personal appearance, race, religion, or sexual identity
|
||||
and orientation.
|
||||
nationality, personal appearance, race, caste, color, religion, or sexual
|
||||
identity and orientation.
|
||||
|
||||
We pledge to act and interact in ways that contribute to an open, welcoming,
|
||||
diverse, inclusive, and healthy community.
|
||||
@ -17,23 +17,23 @@ diverse, inclusive, and healthy community.
|
||||
Examples of behavior that contributes to a positive environment for our
|
||||
community include:
|
||||
|
||||
* Demonstrating empathy and kindness toward other people
|
||||
* Being respectful of differing opinions, viewpoints, and experiences
|
||||
* Giving and gracefully accepting constructive feedback
|
||||
* Accepting responsibility and apologizing to those affected by our mistakes,
|
||||
- Demonstrating empathy and kindness toward other people
|
||||
- Being respectful of differing opinions, viewpoints, and experiences
|
||||
- Giving and gracefully accepting constructive feedback
|
||||
- Accepting responsibility and apologizing to those affected by our mistakes,
|
||||
and learning from the experience
|
||||
* Focusing on what is best not just for us as individuals, but for the
|
||||
overall community
|
||||
- Focusing on what is best not just for us as individuals, but for the overall
|
||||
community
|
||||
|
||||
Examples of unacceptable behavior include:
|
||||
|
||||
* The use of sexualized language or imagery, and sexual attention or
|
||||
advances of any kind
|
||||
* Trolling, insulting or derogatory comments, and personal or political attacks
|
||||
* Public or private harassment
|
||||
* Publishing others' private information, such as a physical or email
|
||||
address, without their explicit permission
|
||||
* Other conduct which could reasonably be considered inappropriate in a
|
||||
- The use of sexualized language or imagery, and sexual attention or advances of
|
||||
any kind
|
||||
- Trolling, insulting or derogatory comments, and personal or political attacks
|
||||
- Public or private harassment
|
||||
- Publishing others' private information, such as a physical or email address,
|
||||
without their explicit permission
|
||||
- Other conduct which could reasonably be considered inappropriate in a
|
||||
professional setting
|
||||
|
||||
## Enforcement Responsibilities
|
||||
@ -52,7 +52,7 @@ decisions when appropriate.
|
||||
|
||||
This Code of Conduct applies within all community spaces, and also applies when
|
||||
an individual is officially representing the community in public spaces.
|
||||
Examples of representing our community include using an official e-mail address,
|
||||
Examples of representing our community include using an official email address,
|
||||
posting via an official social media account, or acting as an appointed
|
||||
representative at an online or offline event.
|
||||
|
||||
@ -60,8 +60,8 @@ representative at an online or offline event.
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be
|
||||
reported to the community leaders responsible for enforcement at
|
||||
uptime@kuma.pet.
|
||||
All complaints will be reviewed and investigated promptly and fairly.
|
||||
<uptime@kuma.pet>. All complaints will be reviewed and investigated promptly and
|
||||
fairly.
|
||||
|
||||
All community leaders are obligated to respect the privacy and security of the
|
||||
reporter of any incident.
|
||||
@ -82,15 +82,15 @@ behavior was inappropriate. A public apology may be requested.
|
||||
|
||||
### 2. Warning
|
||||
|
||||
**Community Impact**: A violation through a single incident or series
|
||||
of actions.
|
||||
**Community Impact**: A violation through a single incident or series of
|
||||
actions.
|
||||
|
||||
**Consequence**: A warning with consequences for continued behavior. No
|
||||
interaction with the people involved, including unsolicited interaction with
|
||||
those enforcing the Code of Conduct, for a specified period of time. This
|
||||
includes avoiding interactions in community spaces as well as external channels
|
||||
like social media. Violating these terms may lead to a temporary or
|
||||
permanent ban.
|
||||
like social media. Violating these terms may lead to a temporary or permanent
|
||||
ban.
|
||||
|
||||
### 3. Temporary Ban
|
||||
|
||||
@ -109,20 +109,24 @@ Violating these terms may lead to a permanent ban.
|
||||
standards, including sustained inappropriate behavior, harassment of an
|
||||
individual, or aggression toward or disparagement of classes of individuals.
|
||||
|
||||
**Consequence**: A permanent ban from any sort of public interaction within
|
||||
the community.
|
||||
**Consequence**: A permanent ban from any sort of public interaction within the
|
||||
community.
|
||||
|
||||
## Attribution
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
|
||||
version 2.0, available at
|
||||
https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
|
||||
version 2.1, available at
|
||||
[https://www.contributor-covenant.org/version/2/1/code_of_conduct.html][v2.1].
|
||||
|
||||
Community Impact Guidelines were inspired by [Mozilla's code of conduct
|
||||
enforcement ladder](https://github.com/mozilla/diversity).
|
||||
|
||||
[homepage]: https://www.contributor-covenant.org
|
||||
enforcement ladder][Mozilla CoC].
|
||||
|
||||
For answers to common questions about this code of conduct, see the FAQ at
|
||||
https://www.contributor-covenant.org/faq. Translations are available at
|
||||
https://www.contributor-covenant.org/translations.
|
||||
[https://www.contributor-covenant.org/faq][FAQ]. Translations are available at
|
||||
[https://www.contributor-covenant.org/translations][translations].
|
||||
|
||||
[homepage]: https://www.contributor-covenant.org
|
||||
[v2.1]: https://www.contributor-covenant.org/version/2/1/code_of_conduct.html
|
||||
[Mozilla CoC]: https://github.com/mozilla/diversity
|
||||
[FAQ]: https://www.contributor-covenant.org/faq
|
||||
[translations]: https://www.contributor-covenant.org/translations
|
||||
|
||||
704
CONTRIBUTING.md
704
CONTRIBUTING.md
@ -1,16 +1,18 @@
|
||||
# Project Info
|
||||
|
||||
First of all, I want to thank everyone who has submitted issues or shared pull requests for Uptime Kuma.
|
||||
I never thought the GitHub community would be so nice!
|
||||
Because of this, I also never thought that other people would actually read and edit my code.
|
||||
Parts of the code are not very well-structured or commented, sorry about that.
|
||||
First of all, I want to thank everyone who has submitted issues or shared pull
|
||||
requests for Uptime Kuma. I never thought the GitHub community would be so nice!
|
||||
Because of this, I also never thought that other people would actually read and
|
||||
edit my code. Parts of the code are not very well-structured or commented, sorry
|
||||
about that.
|
||||
|
||||
The project was created with `vite.js` and is written in `vue3`.
|
||||
Our backend lives in the `server`-directory and mostly communicates via websockets.
|
||||
Both frontend and backend share the same `package.json`.
|
||||
The project was created with `vite.js` and is written in `vue3`. Our backend
|
||||
lives in the `server`-directory and mostly communicates via websockets. Both
|
||||
frontend and backend share the same `package.json`.
|
||||
|
||||
For production, the frontend is built into the `dist`-directory and the server (`express.js`) exposes the `dist` directory as the root of the endpoint.
|
||||
For development, we run vite in development mode on another port.
|
||||
For production, the frontend is built into the `dist`-directory and the server
|
||||
(`express.js`) exposes the `dist` directory as the root of the endpoint. For
|
||||
development, we run vite in development mode on another port.
|
||||
|
||||
## Directories
|
||||
|
||||
@ -25,193 +27,437 @@ For development, we run vite in development mode on another port.
|
||||
- `src` (Frontend source code)
|
||||
- `test` (unit test)
|
||||
|
||||
## Can I create a pull request for Uptime Kuma?
|
||||
## Can I Create a Pull Request for Uptime Kuma?
|
||||
|
||||
Yes or no, it depends on what you will try to do.
|
||||
Both yours and our maintainers' time is precious, and we don't want to waste either.
|
||||
Whether or not you can create a pull request depends on the nature of your
|
||||
contribution. We value both your time and our maintainers' time, so we want to
|
||||
make sure it's spent efficiently.
|
||||
|
||||
If you have any questions about any process/.. is not clear, you are likely not alone => please ask them ^^
|
||||
If you're unsure about any process or step, you're probably not the only one
|
||||
with that question—please feel free to ask. We're happy to help!
|
||||
|
||||
Different guidelines exist for different types of pull requests (PRs):
|
||||
- <details><summary><b>security fixes</b></summary>
|
||||
Different types of pull requests (PRs) may have different guidelines, so be sure
|
||||
to review the appropriate one for your contribution.
|
||||
|
||||
- <details><summary><b>Security Fixes</b> (click to expand)</summary>
|
||||
<p>
|
||||
|
||||
|
||||
Submitting security fixes is something that may put the community at risk.
|
||||
Please read through our [security policy](SECURITY.md) and submit vulnerabilities via an [advisory](https://github.com/louislam/uptime-kuma/security/advisories/new) + [issue](https://github.com/louislam/uptime-kuma/issues/new?assignees=&labels=help&template=security.md) instead.
|
||||
We encourage you to submit how to fix a vulnerability if you know how to, this is not required.
|
||||
Following the security policy allows us to properly test, fix bugs.
|
||||
This review allows us to notice, if there are any changes necessary to unrelated parts like the documentation.
|
||||
Please read through our [security policy](SECURITY.md) and submit
|
||||
vulnerabilities via an [advisory] + [issue] instead. We encourage you to
|
||||
submit how to fix a vulnerability if you know how to, this is not required.
|
||||
Following the security policy allows us to properly test, fix bugs. This
|
||||
review allows us to notice, if there are any changes necessary to unrelated
|
||||
parts like the documentation.
|
||||
[**PLEASE SEE OUR SECURITY POLICY.**](SECURITY.md)
|
||||
|
||||
|
||||
[advisory]: https://github.com/louislam/uptime-kuma/security/advisories/new
|
||||
[issue]:
|
||||
https://github.com/louislam/uptime-kuma/issues/new?template=security_issue.yml
|
||||
|
||||
</p>
|
||||
</details>
|
||||
- <details><summary><b>small, non-breaking bug fixes</b></summary>
|
||||
|
||||
- <details><summary><b>Small, Non-Breaking Bug Fixes</b> (click to expand)</summary>
|
||||
<p>
|
||||
|
||||
|
||||
If you come across a bug and think you can solve, we appreciate your work.
|
||||
Please make sure that you follow these rules:
|
||||
- keep the PR as small as possible, fix only one thing at a time => keeping it reviewable
|
||||
- test that your code does what you claim it does.
|
||||
|
||||
<sub>Because maintainer time is precious, junior maintainers may merge uncontroversial PRs in this area.</sub>
|
||||
</p>
|
||||
</details>
|
||||
- <details><summary><b>translations / internationalisation (i18n)</b></summary>
|
||||
<p>
|
||||
|
||||
We use weblate to localise this project into many languages.
|
||||
If you are unhappy with a translation this is the best start.
|
||||
On how to translate using weblate, please see [these instructions](https://github.com/louislam/uptime-kuma/blob/master/src/lang/README.md).
|
||||
|
||||
There are two cases in which a change cannot be done in weblate and requires a PR:
|
||||
- A text may not be currently localisable. In this case, **adding a new language key** via `$t("languageKey")` might be nessesary
|
||||
- language keys need to be **added to `en.json`** to be visible in weblate. If this has not happened, a PR is appreciated.
|
||||
- **Adding a new language** requires a new file see [these instructions](https://github.com/louislam/uptime-kuma/blob/master/src/lang/README.md)
|
||||
|
||||
<sub>Because maintainer time is precious, junior maintainers may merge uncontroversial PRs in this area.</sub>
|
||||
</p>
|
||||
</details>
|
||||
- <details><summary><b>new notification providers</b></summary>
|
||||
<p>
|
||||
|
||||
To set up a new notification provider these files need to be modified/created:
|
||||
- `server/notification-providers/PROVIDER_NAME.js` is where the heart of the notification provider lives.
|
||||
- Both `monitorJSON` and `heartbeatJSON` can be `null` for some events.
|
||||
If both are `null`, this is a general testing message, but if just `heartbeatJSON` is `null` this is a certificate expiry.
|
||||
- Please wrap the axios call into a
|
||||
```js
|
||||
try {
|
||||
let result = await axios.post(...);
|
||||
if (result.status === ...) ...
|
||||
} catch (error) {
|
||||
this.throwGeneralAxiosError(error);
|
||||
}
|
||||
```
|
||||
- `server/notification.js` is where the backend of the notification provider needs to be registered.
|
||||
*If you have an idea how we can skip this step, we would love to hear about it ^^*
|
||||
- `src/components/NotificationDialog.vue` you need to decide if the provider is a regional or a global one and add it with a name to the respective list
|
||||
- `src/components/notifications/PROVIDER_NAME.vue` is where the frontend of each provider lives.
|
||||
Please make sure that you have:
|
||||
- used `HiddenInput` for secret credentials
|
||||
- included all the necessary helptexts/placeholder/.. to make sure the notification provider is simple to setup for new users.
|
||||
- include all translations (`{{ $t("Translation key") }}`, [`i18n-t keypath="Translation key">`](https://vue-i18n.intlify.dev/guide/advanced/component.html)) in `src/lang/en.json` to enable our translators to translate this
|
||||
- `src/components/notifications/index.js` is where the frontend of the provider needs to be registered.
|
||||
*If you have an idea how we can skip this step, we would love to hear about it ^^*
|
||||
|
||||
Offering notifications is close to the core of what we are as an uptime monitor.
|
||||
Therefore, making sure that they work is also really important.
|
||||
Because testing notification providers is quite time intensive, we mostly offload this onto the person contributing a notification provider.
|
||||
|
||||
To make sure you have tested the notification provider, please include screenshots of the following events in the pull-request description:
|
||||
- `UP`/`DOWN`
|
||||
- Certificate Expiry via https://expired.badssl.com/
|
||||
- Testing (the test button on the notification provider setup page)
|
||||
|
||||
Using the following way to format this is encouraged:
|
||||
```md
|
||||
| Event | Before | After |
|
||||
------------------
|
||||
| `UP` | paste-image-here | paste-image-here |
|
||||
| `DOWN` | paste-image-here | paste-image-here |
|
||||
| Certificate-expiry | paste-image-here | paste-image-here |
|
||||
| Testing | paste-image-here | paste-image-here |
|
||||
- keep the PR as small as possible, fix only one thing at a time => keeping it
|
||||
reviewable
|
||||
- test that your code does what you claim it does.
|
||||
|
||||
<sub>Because maintainer time is precious, junior maintainers may merge
|
||||
uncontroversial PRs in this area.</sub>
|
||||
|
||||
</p>
|
||||
</details>
|
||||
|
||||
- <details><summary><b>Translations / Internationalisation (i18n)</b> (click to expand)</summary>
|
||||
<p>
|
||||
|
||||
We use weblate to localise this project into many languages. If you are
|
||||
unhappy with a translation this is the best start. On how to translate using
|
||||
weblate, please see
|
||||
[these instructions](https://github.com/louislam/uptime-kuma/blob/master/src/lang/README.md).
|
||||
|
||||
There are two cases in which a change cannot be done in weblate and requires a
|
||||
PR:
|
||||
|
||||
- A text may not be currently localisable. In this case, **adding a new
|
||||
language key** via `$t("languageKey")` might be nessesary
|
||||
- language keys need to be **added to `en.json`** to be visible in weblate. If
|
||||
this has not happened, a PR is appreciated.
|
||||
- **Adding a new language** requires a new file see
|
||||
[these instructions](https://github.com/louislam/uptime-kuma/blob/master/src/lang/README.md)
|
||||
|
||||
<sub>Because maintainer time is precious, junior maintainers may merge
|
||||
uncontroversial PRs in this area.</sub>
|
||||
|
||||
</p>
|
||||
</details>
|
||||
|
||||
- <details><summary><b>New Notification Providers</b> (click to expand)</summary>
|
||||
<p>
|
||||
|
||||
To set up a new notification provider these files need to be modified/created:
|
||||
|
||||
- `server/notification-providers/PROVIDER_NAME.js` is where the heart of the
|
||||
notification provider lives.
|
||||
|
||||
- Both `monitorJSON` and `heartbeatJSON` can be `null` for some events. If
|
||||
|
||||
both are `null`, this is a general testing message, but if just
|
||||
`heartbeatJSON` is `null` this is a certificate expiry.
|
||||
|
||||
- Please wrap the axios call into a
|
||||
|
||||
```js
|
||||
try {
|
||||
let result = await axios.post(...);
|
||||
if (result.status === ...) ...
|
||||
} catch (error) {
|
||||
this.throwGeneralAxiosError(error);
|
||||
}
|
||||
```
|
||||
|
||||
<sub>Because maintainer time is precious, junior maintainers may merge uncontroversial PRs in this area.</sub>
|
||||
- `server/notification.js` is where the backend of the notification provider
|
||||
needs to be registered. _If you have an idea how we can skip this step, we
|
||||
would love to hear about it ^^_
|
||||
|
||||
- `src/components/NotificationDialog.vue` you need to decide if the provider
|
||||
is a regional or a global one and add it with a name to the respective list
|
||||
|
||||
- `src/components/notifications/PROVIDER_NAME.vue` is where the frontend of
|
||||
each provider lives. Please make sure that you have:
|
||||
|
||||
- used `HiddenInput` for secret credentials
|
||||
- included all the necessary helptexts/placeholder/.. to make sure the
|
||||
|
||||
notification provider is simple to setup for new users. - include all
|
||||
translations (`{{ $t("Translation key") }}`,
|
||||
[`i18n-t keypath="Translation key">`](https://vue-i18n.intlify.dev/guide/advanced/component.html))
|
||||
in `src/lang/en.json` to enable our translators to translate this
|
||||
|
||||
- `src/components/notifications/index.js` is where the frontend of the
|
||||
provider needs to be registered. _If you have an idea how we can skip this
|
||||
step, we would love to hear about it ^^_
|
||||
|
||||
Offering notifications is close to the core of what we are as an uptime
|
||||
monitor. Therefore, making sure that they work is also really important.
|
||||
Because testing notification providers is quite time intensive, we mostly
|
||||
offload this onto the person contributing a notification provider.
|
||||
|
||||
To make sure you have tested the notification provider, please include
|
||||
screenshots of the following events in the pull-request description:
|
||||
|
||||
- `UP`/`DOWN`
|
||||
- Certificate Expiry via <https://expired.badssl.com/>
|
||||
- Testing (the test button on the notification provider setup page)
|
||||
|
||||
<br/>
|
||||
|
||||
Using the following way to format this is encouraged:
|
||||
|
||||
```md
|
||||
| Event | Before | After |
|
||||
| ------------------ | --------------------- | -------------------- |
|
||||
| `UP` |  |  |
|
||||
| `DOWN` |  |  |
|
||||
| Certificate-expiry |  |  |
|
||||
| Testing |  |  |
|
||||
```
|
||||
|
||||
<sub>Because maintainer time is precious, junior maintainers may merge
|
||||
uncontroversial PRs in this area.</sub>
|
||||
|
||||
</p>
|
||||
</details>
|
||||
- <details><summary><b>new monitoring types</b></summary>
|
||||
|
||||
- <details><summary><b>New Monitoring Types</b> (click to expand)</summary>
|
||||
<p>
|
||||
|
||||
To set up a new notification provider these files need to be modified/created:
|
||||
- `server/monitor-types/MONITORING_TYPE.js` is the core of each monitor.
|
||||
the `async check(...)`-function should:
|
||||
- throw an error for each fault that is detected with an actionable error message
|
||||
- in the happy-path, you should set `heartbeat.msg` to a successful message and set `heartbeat.status = UP`
|
||||
- `server/uptime-kuma-server.js` is where the monitoring backend needs to be registered.
|
||||
*If you have an idea how we can skip this step, we would love to hear about it ^^*
|
||||
|
||||
- `server/monitor-types/MONITORING_TYPE.js` is the core of each monitor. the
|
||||
`async check(...)`-function should:
|
||||
|
||||
- throw an error for each fault that is detected with an actionable error
|
||||
|
||||
message - in the happy-path, you should set `heartbeat.msg` to a successful
|
||||
message and set `heartbeat.status = UP`
|
||||
|
||||
- `server/uptime-kuma-server.js` is where the monitoring backend needs to be
|
||||
registered. _If you have an idea how we can skip this step, we would love to
|
||||
hear about it ^^_
|
||||
|
||||
- `src/pages/EditMonitor.vue` is the shared frontend users interact with.
|
||||
Please make sure that you have:
|
||||
- used `HiddenInput` for secret credentials
|
||||
- included all the necessary helptexts/placeholder/.. to make sure the notification provider is simple to setup for new users.
|
||||
- include all translations (`{{ $t("Translation key") }}`, [`i18n-t keypath="Translation key">`](https://vue-i18n.intlify.dev/guide/advanced/component.html)) in `src/lang/en.json` to enable our translators to translate this
|
||||
-
|
||||
Please make sure that you have: - used `HiddenInput` for secret
|
||||
credentials - included all the necessary helptexts/placeholder/.. to make
|
||||
sure the notification provider is simple to setup for new users. - include
|
||||
all translations (`{{ $t("Translation key") }}`,
|
||||
[`i18n-t keypath="Translation key">`](https://vue-i18n.intlify.dev/guide/advanced/component.html))
|
||||
in `src/lang/en.json` to enable our translators to translate this
|
||||
|
||||
<sub>Because maintainer time is precious, junior maintainers may merge
|
||||
uncontroversial PRs in this area.</sub>
|
||||
|
||||
<sub>Because maintainer time is precious, junior maintainers may merge uncontroversial PRs in this area.</sub>
|
||||
</p>
|
||||
</details>
|
||||
- <details><summary><b>new features/ major changes / breaking bugfixes</b></summary>
|
||||
<p>
|
||||
|
||||
be sure to **create an empty draft pull request or open an issue, so we can have a discussion first**.
|
||||
This is especially important for a large pull request or when you don't know if it will be merged or not.
|
||||
|
||||
<sub>Because of the large impact of this work, only senior maintainers may merge PRs in this area.</sub>
|
||||
</p>
|
||||
</details>
|
||||
|
||||
The following rules are essential for making your PR mergable:
|
||||
- Merging multiple issues by a huge PR is more difficult to review and causes conflicts with other PRs. Please
|
||||
- <details><summary><b>New Features / Major Changes / Breaking Bugfixes</b> (click to expand)</summary>
|
||||
<p>
|
||||
|
||||
be sure to **create an empty draft pull request or open an issue, so we can
|
||||
have a discussion first**. This is especially important for a large pull
|
||||
request or when you don't know if it will be merged or not.
|
||||
|
||||
<sub>Because of the large impact of this work, only senior maintainers may
|
||||
merge PRs in this area. </sub>
|
||||
|
||||
</p>
|
||||
</details>
|
||||
|
||||
- <details><summary><b>Pull Request Guidelines</b> (click to expand)</summary>
|
||||
<p>
|
||||
|
||||
## Steps to Submit a Pull Request
|
||||
|
||||
1. **Fork** the [Uptime-Kuma repository].
|
||||
|
||||
[Uptime-Kuma repository]: https://github.com/louislam/uptime-kuma/
|
||||
|
||||
2. **Clone** your forked repository to your local machine.
|
||||
3. **Create a new branch** for your changes (e.g.,
|
||||
`feature/add-new-notification-provider-signal`).
|
||||
4. **Initiate a discussion before making major changes** by creating an empty
|
||||
commit:
|
||||
|
||||
```sh
|
||||
git commit -m "<YOUR TASK NAME>" --allow-empty
|
||||
```
|
||||
|
||||
5. **Push** your branch to your forked repository.
|
||||
6. **Open a pull request** using this link: [Compare & Pull Request].
|
||||
|
||||
[Compare & Pull Request]: https://github.com/louislam/uptime-kuma/compare/
|
||||
|
||||
7. **Select the correct source and target branches**.
|
||||
8. **Link to related issues** for context.
|
||||
9. **Provide a clear and concise description** explaining the changes and
|
||||
their purpose.
|
||||
|
||||
- **Type of changes**
|
||||
|
||||
- Bugfix (a non-breaking change that resolves an issue)
|
||||
- New feature (a non-breaking change that adds new functionality)
|
||||
- Breaking change (a fix or feature that alters existing functionality in a
|
||||
way that could cause issues)
|
||||
- User Interface (UI) updates
|
||||
- New Documentation (addition of new documentation)
|
||||
- Documentation Update (modification of existing documentation)
|
||||
- Documentation Update Required (the change requires updates to related
|
||||
documentation)
|
||||
- Other (please specify):
|
||||
- Provide additional details here.
|
||||
|
||||
- **Checklist**
|
||||
|
||||
- My code adheres to the style guidelines of this project.
|
||||
- I ran ESLint and other code linters for modified files.
|
||||
- I have reviewed and tested my code.
|
||||
- I have commented my code, especially in hard-to-understand areas (e.g.,
|
||||
using JSDoc for methods).
|
||||
- My changes generate no new warnings.
|
||||
- My code needed automated testing. I have added them (this is an optional
|
||||
task).
|
||||
- Documentation updates are included (if applicable).
|
||||
- I have considered potential security impacts and mitigated risks.
|
||||
- Dependency updates are listed and explained.
|
||||
- I have read and understood the
|
||||
[Pull Request guidelines](#recommended-pull-request-guideline).
|
||||
|
||||
10. **When publishing your PR, set it as a** `Draft pull request` **to allow
|
||||
for review and prevent automatic merging.**
|
||||
11. **Maintainers will assign relevant labels** (e.g., `A:maintenance`,
|
||||
`A:notifications`).
|
||||
12. **Complete the PR checklist**, ensuring that:
|
||||
|
||||
- Documentation is updated if necessary.
|
||||
- Tests are written or updated.
|
||||
- CI/CD checks pass successfully.
|
||||
|
||||
13. **Request feedback** from team members to refine your changes before the
|
||||
final review.
|
||||
|
||||
## When Can You Change the PR Status to "Ready for Review"?
|
||||
|
||||
A PR should remain in **draft status** until all tasks are completed. Only
|
||||
change the status to **Ready for Review** when:
|
||||
|
||||
- You have implemented all planned changes.
|
||||
- You have addressed all feedback.
|
||||
- Your code is fully tested and ready for integration.
|
||||
- You have updated or created the necessary tests.
|
||||
- You have verified that CI/CD checks pass successfully.
|
||||
|
||||
<br />
|
||||
|
||||
A **work-in-progress (WIP) PR** must stay in **draft status** until everything
|
||||
is finalized.
|
||||
|
||||
<sub>Since maintainer time is valuable, junior maintainers may merge
|
||||
uncontroversial PRs.</sub>
|
||||
|
||||
</p>
|
||||
</details>
|
||||
|
||||
## The following rules are essential for making your PR mergable
|
||||
|
||||
- Merging multiple issues by a huge PR is more difficult to review and causes
|
||||
conflicts with other PRs. Please
|
||||
|
||||
- (if possible) **create one PR for one issue** or
|
||||
- (if not possible) **explain which issues a PR addresses and why this PR should not be broken apart**
|
||||
- Make sure your **PR passes our continuous integration**.
|
||||
PRs will not be merged unless all CI-Checks are green.
|
||||
- **Breaking changes** (unless for a good reason and discussed beforehand) will not get merged / not get merged quickly.
|
||||
Such changes require a major version release.
|
||||
- **Test your code** before submitting a PR.
|
||||
Buggy PRs will not be merged.
|
||||
- (if not possible) **explain which issues a PR addresses and why this PR
|
||||
should not be broken apart**
|
||||
|
||||
- Make sure your **PR passes our continuous integration**. PRs will not be
|
||||
merged unless all CI-Checks are green.
|
||||
- **Breaking changes** (unless for a good reason and discussed beforehand) will
|
||||
not get merged / not get merged quickly. Such changes require a major version
|
||||
release.
|
||||
- **Test your code** before submitting a PR. Buggy PRs will not be merged.
|
||||
- Make sure the **UI/UX is close to Uptime Kuma**.
|
||||
- **Think about the maintainability**:
|
||||
Don't add functionality that is completely **out of scope**.
|
||||
Keep in mind that we need to be able to maintain the functionality.
|
||||
- **Think about the maintainability**: Don't add functionality that is
|
||||
completely **out of scope**. Keep in mind that we need to be able to maintain
|
||||
the functionality.
|
||||
- Don't modify or delete existing logic without a valid reason.
|
||||
- Don't convert existing code into other programming languages for no reason.
|
||||
|
||||
I ([@louislam](https://github.com/louislam)) have the final say.
|
||||
If your pull request does not meet my expectations, I will reject it, no matter how much time you spent on it.
|
||||
Therefore, it is essential to have a discussion beforehand.
|
||||
I ([@louislam](https://github.com/louislam)) have the final say. If your pull
|
||||
request does not meet my expectations, I will reject it, no matter how much time
|
||||
you spent on it. Therefore, it is essential to have a discussion beforehand.
|
||||
|
||||
I will assign your pull request to a [milestone](https://github.com/louislam/uptime-kuma/milestones), if I plan to review and merge it.
|
||||
I will assign your pull request to a [milestone], if I plan to review and merge
|
||||
it.
|
||||
|
||||
Please don't rush or ask for an ETA.
|
||||
We have to understand the pull request, make sure it has no breaking changes and stick to the vision of this project, especially for large pull requests.
|
||||
[milestone]: https://github.com/louislam/uptime-kuma/milestones
|
||||
|
||||
Please don't rush or ask for an ETA. We have to understand the pull request,
|
||||
make sure it has no breaking changes and stick to the vision of this project,
|
||||
especially for large pull requests.
|
||||
|
||||
## I'd like to work on an issue. How do I do that?
|
||||
## I'd Like to Work on an Issue. How Do I Do That?
|
||||
|
||||
We have found that assigning people to issues is management-overhead that we don't need.
|
||||
A short comment that you want to try your hand at this issue is appreciated to save other devs time.
|
||||
If you come across any problem during development, feel free to leave a comment with what you are stuck on.
|
||||
We have found that assigning people to issues is unnecessary management
|
||||
overhead. Instead, a short comment stating that you want to work on an issue is
|
||||
appreciated, as it saves time for other developers. If you encounter any
|
||||
problems during development, feel free to leave a comment describing what you
|
||||
are stuck on.
|
||||
|
||||
### Recommended Pull Request Guideline
|
||||
|
||||
Before diving deep into coding, having a discussion first by creating an empty pull request for discussion is preferred.
|
||||
The rationale behind this is that we can align the direction and scope of the feature to eliminate any conflicts with existing and planned work, and can help by pointing out any potential pitfalls.
|
||||
Before jumping into coding, it's recommended to initiate a discussion by
|
||||
creating an empty pull request. This approach allows us to align on the
|
||||
direction and scope of the feature, ensuring it doesn't conflict with existing
|
||||
or planned work. It also provides an opportunity to identify potential pitfalls
|
||||
early on, helping to avoid issues down the line.
|
||||
|
||||
1. Fork the project
|
||||
2. Clone your fork repo to local
|
||||
3. Create a new branch
|
||||
4. Create an empty commit: `git commit -m "<YOUR TASK NAME>" --allow-empty`
|
||||
5. Push to your fork repo
|
||||
6. Prepare a pull request: https://github.com/louislam/uptime-kuma/compare
|
||||
7. Write a proper description. You can mention @louislam in it, so @louislam will get the notification.
|
||||
8. Create your pull request as a Draft
|
||||
9. Wait for the discussion
|
||||
1. **Fork** the [Uptime-Kuma repository].
|
||||
2. **Clone** your forked repository to your local machine.
|
||||
3. **Create a new branch** for your changes (e.g.,
|
||||
`feature/add-new-notification-provider-signal`).
|
||||
4. **Initiate a discussion before making major changes** by creating an empty
|
||||
commit:
|
||||
|
||||
```sh
|
||||
git commit -m "<YOUR TASK NAME>" --allow-empty
|
||||
```
|
||||
|
||||
5. **Push** your branch to your forked repository.
|
||||
6. **Open a pull request** using this link: [Compare & Pull Request].
|
||||
7. **Select the correct source and target branches**.
|
||||
8. **Link to related issues** for context.
|
||||
9. **Provide a clear and concise description** explaining the changes and their
|
||||
purpose.
|
||||
|
||||
- **Type of changes**
|
||||
|
||||
- Bugfix (a non-breaking change that resolves an issue)
|
||||
- New feature (a non-breaking change that adds new functionality)
|
||||
- Breaking change (a fix or feature that alters existing functionality in a
|
||||
way that could cause issues)
|
||||
- User Interface (UI) updates
|
||||
- New Documentation (addition of new documentation)
|
||||
- Documentation Update (modification of existing documentation)
|
||||
- Documentation Update Required (the change requires updates to related
|
||||
documentation)
|
||||
- Other (please specify):
|
||||
- Provide additional details here.
|
||||
|
||||
- **Checklist**
|
||||
|
||||
- My code adheres to the style guidelines of this project.
|
||||
- I ran ESLint and other code linters for modified files.
|
||||
- I have reviewed and tested my code.
|
||||
- I have commented my code, especially in hard-to-understand areas (e.g.,
|
||||
using JSDoc for methods).
|
||||
- My changes generate no new warnings.
|
||||
- My code needed automated testing. I have added them (this is an optional
|
||||
task).
|
||||
- Documentation updates are included (if applicable).
|
||||
- I have considered potential security impacts and mitigated risks.
|
||||
- Dependency updates are listed and explained.
|
||||
- I have read and understood the
|
||||
[Pull Request guidelines](#recommended-pull-request-guideline).
|
||||
|
||||
10. **When publishing your PR, set it as a** `Draft pull request` **to allow for
|
||||
review and prevent automatic merging.**
|
||||
11. **Maintainers will assign relevant labels** (e.g., `A:maintenance`,
|
||||
`A:notifications`).
|
||||
12. **Complete the PR checklist**, ensuring that:
|
||||
|
||||
- Documentation is updated if necessary.
|
||||
- Tests are written or updated.
|
||||
- CI/CD checks pass successfully.
|
||||
|
||||
13. **Request feedback** from team members to refine your changes before the
|
||||
final review.
|
||||
|
||||
### When Can You Change the PR Status to "Ready for Review"?
|
||||
|
||||
A PR should remain in **draft status** until all tasks are completed. Only
|
||||
change the status to **Ready for Review** when:
|
||||
|
||||
- You have implemented all planned changes.
|
||||
- You have addressed all feedback.
|
||||
- Your code is fully tested and ready for integration.
|
||||
- You have updated or created the necessary tests.
|
||||
- You have verified that CI/CD checks pass successfully.
|
||||
|
||||
A **work-in-progress (WIP) PR** must stay in **draft status** until everything
|
||||
is finalized.
|
||||
|
||||
## Project Styles
|
||||
|
||||
I personally do not like something that requires a lot of configuration before you can finally start the app.
|
||||
The goal is to make the Uptime Kuma installation as easy as installing a mobile app.
|
||||
I personally do not like something that requires a lot of configuration before
|
||||
you can finally start the app. The goal is to make the Uptime Kuma installation
|
||||
as easy as installing a mobile app.
|
||||
|
||||
- Easy to install for non-Docker users
|
||||
|
||||
- no native build dependency is needed (for `x86_64`/`armv7`/`arm64`)
|
||||
- no extra configuration and
|
||||
- no extra effort required to get it running
|
||||
|
||||
- Single container for Docker users
|
||||
|
||||
- no complex docker-compose file
|
||||
- mapping the volume and exposing the port should be the only requirements
|
||||
- Settings should be configurable in the frontend. Environment variables are discouraged, unless it is related to startup such as `DATA_DIR`
|
||||
|
||||
- Settings should be configurable in the frontend. Environment variables are
|
||||
discouraged, unless it is related to startup such as `DATA_DIR`
|
||||
- Easy to use
|
||||
- The web UI styling should be consistent and nice
|
||||
|
||||
@ -233,13 +479,18 @@ The goal is to make the Uptime Kuma installation as easy as installing a mobile
|
||||
- [`Node.js`](https://nodejs.org/) >= 18
|
||||
- [`npm`](https://www.npmjs.com/) >= 9.3
|
||||
- [`git`](https://git-scm.com/)
|
||||
- IDE that supports [`ESLint`](https://eslint.org/) and EditorConfig (I am using [`IntelliJ IDEA`](https://www.jetbrains.com/idea/))
|
||||
- A SQLite GUI tool (f.ex. [`SQLite Expert Personal`](https://www.sqliteexpert.com/download.html) or [`DBeaver Community`](https://dbeaver.io/download/))
|
||||
- IDE that supports [`ESLint`](https://eslint.org/) and EditorConfig (I am using
|
||||
[`IntelliJ IDEA`](https://www.jetbrains.com/idea/))
|
||||
- A SQLite GUI tool (f.ex.
|
||||
[`SQLite Expert Personal`](https://www.sqliteexpert.com/download.html) or
|
||||
[`DBeaver Community`](https://dbeaver.io/download/))
|
||||
|
||||
## Git Branches
|
||||
|
||||
- `master`: 2.X.X development. If you want to add a new feature, your pull request should base on this.
|
||||
- `1.23.X`: 1.23.X development. If you want to fix a bug for v1 and v2, your pull request should base on this.
|
||||
- `master`: 2.X.X development. If you want to add a new feature, your pull
|
||||
request should base on this.
|
||||
- `1.23.X`: 1.23.X development. If you want to fix a bug for v1 and v2, your
|
||||
pull request should base on this.
|
||||
- All other branches are unused, outdated or for dev.
|
||||
|
||||
## Install Dependencies for Development
|
||||
@ -260,7 +511,8 @@ Port `3000` and port `3001` will be used.
|
||||
npm run dev
|
||||
```
|
||||
|
||||
But sometimes you may want to restart the server without restarting the frontend. In that case, you can run these commands in two terminals:
|
||||
But sometimes you may want to restart the server without restarting the
|
||||
frontend. In that case, you can run these commands in two terminals:
|
||||
|
||||
```bash
|
||||
npm run start-frontend-dev
|
||||
@ -271,9 +523,9 @@ npm run start-server-dev
|
||||
|
||||
It binds to `0.0.0.0:3001` by default.
|
||||
|
||||
The backend is an `express.js` server with `socket.io` integrated.
|
||||
It uses `socket.io` to communicate with clients, and most server logic is encapsulated in the `socket.io` handlers.
|
||||
`express.js` is also used to serve:
|
||||
The backend is an `express.js` server with `socket.io` integrated. It uses
|
||||
`socket.io` to communicate with clients, and most server logic is encapsulated
|
||||
in the `socket.io` handlers. `express.js` is also used to serve:
|
||||
|
||||
- as an entry point for redirecting to a status page or the dashboard
|
||||
- the frontend built files (`index.html`, `*.js`, `*.css`, etc.)
|
||||
@ -289,11 +541,13 @@ It uses `socket.io` to communicate with clients, and most server logic is encaps
|
||||
- `routers/` (Express Routers)
|
||||
- `socket-handler/` (Socket.io Handlers)
|
||||
- `server.js` (Server entry point)
|
||||
- `uptime-kuma-server.js` (UptimeKumaServer class, main logic should be here, but some still in `server.js`)
|
||||
- `uptime-kuma-server.js` (UptimeKumaServer class, main logic should be here,
|
||||
but some still in `server.js`)
|
||||
|
||||
## Frontend Dev Server
|
||||
|
||||
It binds to `0.0.0.0:3000` by default. The frontend dev server is used for development only.
|
||||
It binds to `0.0.0.0:3000` by default. The frontend dev server is used for
|
||||
development only.
|
||||
|
||||
For production, it is not used. It will be compiled to `dist` directory instead.
|
||||
|
||||
@ -307,17 +561,19 @@ npm run build
|
||||
|
||||
### Frontend Details
|
||||
|
||||
Uptime Kuma Frontend is a single page application (SPA). Most paths are handled by Vue Router.
|
||||
Uptime Kuma Frontend is a single page application (SPA). Most paths are handled
|
||||
by Vue Router.
|
||||
|
||||
The router is in `src/router.js`
|
||||
|
||||
As you can see, most data in the frontend is stored at the root level, even though you changed the current router to any other pages.
|
||||
As you can see, most data in the frontend is stored at the root level, even
|
||||
though you changed the current router to any other pages.
|
||||
|
||||
The data and socket logic are in `src/mixins/socket.js`.
|
||||
|
||||
## Database Migration
|
||||
|
||||
See: https://github.com/louislam/uptime-kuma/tree/master/db/knex_migrations
|
||||
See: <https://github.com/louislam/uptime-kuma/tree/master/db/knex_migrations>
|
||||
|
||||
## Unit Test
|
||||
|
||||
@ -328,11 +584,12 @@ npm test
|
||||
|
||||
## Dependencies
|
||||
|
||||
Both frontend and backend share the same `package.json`.
|
||||
However, the frontend dependencies are eventually not used in the production environment, because it is usually also baked into `dist` files. So:
|
||||
Both frontend and backend share the same `package.json`. However, the frontend
|
||||
dependencies are eventually not used in the production environment, because it
|
||||
is usually also baked into `dist` files. So:
|
||||
|
||||
- Frontend dependencies = "devDependencies"
|
||||
- Examples: `vue`, `chart.js`
|
||||
- Examples: - `vue`, `chart.js`
|
||||
- Backend dependencies = "dependencies"
|
||||
- Examples: `socket.io`, `sqlite3`
|
||||
- Development dependencies = "devDependencies"
|
||||
@ -340,31 +597,41 @@ However, the frontend dependencies are eventually not used in the production env
|
||||
|
||||
### Update Dependencies
|
||||
|
||||
Since previously updating Vite 2.5.10 to 2.6.0 broke the application completely, from now on, it should update the patch release version only.
|
||||
Since previously updating Vite 2.5.10 to 2.6.0 broke the application completely,
|
||||
from now on, it should update the patch release version only.
|
||||
|
||||
Patch release = the third digit ([Semantic Versioning](https://semver.org/))
|
||||
|
||||
If for security / bug / other reasons, a library must be updated, breaking changes need to be checked by the person proposing the change.
|
||||
If for security / bug / other reasons, a library must be updated, breaking
|
||||
changes need to be checked by the person proposing the change.
|
||||
|
||||
## Translations
|
||||
|
||||
Please add **all** the strings which are translatable to `src/lang/en.json` (if translation keys are omitted, they can not be translated.)
|
||||
Please add **all** the strings which are translatable to `src/lang/en.json` (if
|
||||
translation keys are omitted, they can not be translated.)
|
||||
|
||||
**Don't include any other languages in your initial pull request** (even if this is your mother tongue), to avoid merge-conflicts between weblate and `master`.
|
||||
The translations can then (after merging a PR into `master`) be translated by awesome people donating their language skills.
|
||||
**Don't include any other languages in your initial pull request** (even if this
|
||||
is your mother tongue), to avoid merge-conflicts between weblate and `master`.
|
||||
The translations can then (after merging a PR into `master`) be translated by
|
||||
awesome people donating their language skills.
|
||||
|
||||
If you want to help by translating Uptime Kuma into your language, please visit the [instructions on how to translate using weblate](https://github.com/louislam/uptime-kuma/blob/master/src/lang/README.md).
|
||||
If you want to help by translating Uptime Kuma into your language, please visit
|
||||
the [instructions on how to translate using weblate].
|
||||
|
||||
[instructions on how to translate using weblate]:
|
||||
https://github.com/louislam/uptime-kuma/blob/master/src/lang/README.md
|
||||
|
||||
## Spelling & Grammar
|
||||
|
||||
Feel free to correct the grammar in the documentation or code.
|
||||
My mother language is not English and my grammar is not that great.
|
||||
Feel free to correct the grammar in the documentation or code. My mother
|
||||
language is not English and my grammar is not that great.
|
||||
|
||||
## Wiki
|
||||
|
||||
Since there is no way to make a pull request to the wiki, I have set up another repo to do that.
|
||||
Since there is no way to make a pull request to the wiki, I have set up another
|
||||
repo to do that.
|
||||
|
||||
https://github.com/louislam/uptime-kuma-wiki
|
||||
<https://github.com/louislam/uptime-kuma-wiki>
|
||||
|
||||
## Docker
|
||||
|
||||
@ -405,7 +672,7 @@ https://github.com/louislam/uptime-kuma-wiki
|
||||
## Maintainer
|
||||
|
||||
Check the latest issues and pull requests:
|
||||
https://github.com/louislam/uptime-kuma/issues?q=sort%3Aupdated-desc
|
||||
<https://github.com/louislam/uptime-kuma/issues?q=sort%3Aupdated-desc>
|
||||
|
||||
### What is a maintainer and what are their roles?
|
||||
|
||||
@ -413,7 +680,7 @@ This project has multiple maintainers who specialise in different areas.
|
||||
Currently, there are 3 maintainers:
|
||||
|
||||
| Person | Role | Main Area |
|
||||
|-------------------|-------------------|------------------|
|
||||
| ----------------- | ----------------- | ---------------- |
|
||||
| `@louislam` | senior maintainer | major features |
|
||||
| `@chakflying` | junior maintainer | fixing bugs |
|
||||
| `@commanderstorm` | junior maintainer | issue-management |
|
||||
@ -421,39 +688,49 @@ Currently, there are 3 maintainers:
|
||||
### Procedures
|
||||
|
||||
We have a few procedures we follow. These are documented here:
|
||||
- <details><summary>Set up a Docker Builder</summary>
|
||||
|
||||
- <details><summary><b>Set up a Docker Builder</b> (click to expand)</summary>
|
||||
<p>
|
||||
|
||||
- amd64, armv7 using local.
|
||||
- arm64 using remote arm64 cpu, as the emulator is too slow and can no longer pass the `npm ci` command.
|
||||
1. Add the public key to the remote server.
|
||||
2. Add the remote context. The remote machine must be arm64 and installed Docker CE.
|
||||
```
|
||||
docker context create oracle-arm64-jp --docker "host=ssh://root@100.107.174.88"
|
||||
```
|
||||
3. Create a new builder.
|
||||
```
|
||||
docker buildx create --name kuma-builder --platform linux/amd64,linux/arm/v7
|
||||
docker buildx use kuma-builder
|
||||
docker buildx inspect --bootstrap
|
||||
```
|
||||
4. Append the remote context to the builder.
|
||||
```
|
||||
docker buildx create --append --name kuma-builder --platform linux/arm64 oracle-arm64-jp
|
||||
```
|
||||
5. Verify the builder and check if the builder is using `kuma-builder`.
|
||||
```
|
||||
docker buildx inspect kuma-builder
|
||||
docker buildx ls
|
||||
```
|
||||
- arm64 using remote arm64 cpu, as the emulator is too slow and can no longer
|
||||
pass the `npm ci` command.
|
||||
|
||||
1. Add the public key to the remote server.
|
||||
2. Add the remote context. The remote machine must be arm64 and installed
|
||||
Docker CE.
|
||||
|
||||
```bash
|
||||
docker context create oracle-arm64-jp --docker "host=ssh://root@100.107.174.88"
|
||||
```
|
||||
|
||||
3. Create a new builder.
|
||||
|
||||
```bash
|
||||
docker buildx create --name kuma-builder --platform linux/amd64,linux/arm/v7
|
||||
docker buildx use kuma-builder
|
||||
docker buildx inspect --bootstrap
|
||||
```
|
||||
|
||||
4. Append the remote context to the builder.
|
||||
|
||||
```bash
|
||||
docker buildx create --append --name kuma-builder --platform linux/arm64 oracle-arm64-jp
|
||||
```
|
||||
|
||||
5. Verify the builder and check if the builder is using `kuma-builder`.
|
||||
`docker buildx inspect kuma-builder docker buildx ls`
|
||||
|
||||
</p>
|
||||
</details>
|
||||
- <details><summary>Release</summary>
|
||||
|
||||
- <details><summary><b>Release</b> (click to expand)</summary>
|
||||
<p>
|
||||
|
||||
1. Draft a release note
|
||||
2. Make sure the repo is cleared
|
||||
3. If the healthcheck is updated, remember to re-compile it: `npm run build-docker-builder-go`
|
||||
3. If the healthcheck is updated, remember to re-compile it:
|
||||
`npm run build-docker-builder-go`
|
||||
4. `npm run release-final` with env vars: `VERSION` and `GITHUB_TOKEN`
|
||||
5. Wait until the `Press any key to continue`
|
||||
6. `git push`
|
||||
@ -463,13 +740,16 @@ We have a few procedures we follow. These are documented here:
|
||||
|
||||
These Items need to be checked:
|
||||
|
||||
- [ ] Check all tags is fine on https://hub.docker.com/r/louislam/uptime-kuma/tags
|
||||
- [ ] Try the Docker image with tag 1.X.X (Clean install / amd64 / arm64 / armv7)
|
||||
- [ ] Check all tags is fine on
|
||||
<https://hub.docker.com/r/louislam/uptime-kuma/tags>
|
||||
- [ ] Try the Docker image with tag 1.X.X (Clean install / amd64 / arm64 /
|
||||
armv7)
|
||||
- [ ] Try clean installation with Node.js
|
||||
|
||||
|
||||
</p>
|
||||
</details>
|
||||
- <details><summary>Release Beta</summary>
|
||||
|
||||
- <details><summary><b>Release Beta</b> (click to expand)</summary>
|
||||
<p>
|
||||
|
||||
1. Draft a release note, check `This is a pre-release`
|
||||
@ -478,35 +758,37 @@ We have a few procedures we follow. These are documented here:
|
||||
4. Wait until the `Press any key to continue`
|
||||
5. Publish the release note as `1.X.X-beta.X`
|
||||
6. Press any key to continue
|
||||
|
||||
|
||||
</p>
|
||||
</details>
|
||||
- <details><summary>Release Wiki</summary>
|
||||
|
||||
- <details><summary><b>Release Wiki</b> (click to expand)</summary>
|
||||
<p>
|
||||
|
||||
**Setup Repo**
|
||||
|
||||
|
||||
```bash
|
||||
git clone https://github.com/louislam/uptime-kuma-wiki.git
|
||||
cd uptime-kuma-wiki
|
||||
git remote add production https://github.com/louislam/uptime-kuma.wiki.git
|
||||
```
|
||||
|
||||
|
||||
**Push to Production Wiki**
|
||||
|
||||
|
||||
```bash
|
||||
git pull
|
||||
git push production master
|
||||
```
|
||||
|
||||
|
||||
</p>
|
||||
</details>
|
||||
- <details><summary>Change the base of a pull request such as <code>master</code> to <code>1.23.X</code></summary>
|
||||
|
||||
- <details><summary>Change the base of a pull request such as <code>master</code> to <code>1.23.X</code> (click to expand)</summary>
|
||||
<p>
|
||||
|
||||
|
||||
```bash
|
||||
git rebase --onto <new parent> <old parent>
|
||||
```
|
||||
|
||||
|
||||
</p>
|
||||
</details>
|
||||
|
||||
36
SECURITY.md
36
SECURITY.md
@ -2,29 +2,37 @@
|
||||
|
||||
## Reporting a Vulnerability
|
||||
|
||||
1. Please report security issues to https://github.com/louislam/uptime-kuma/security/advisories/new.
|
||||
2. Please also create an empty security issue to alert me, as GitHub Advisories do not send a notification, I probably will miss it without this. https://github.com/louislam/uptime-kuma/issues/new?assignees=&labels=help&template=security.md
|
||||
1. Please report security issues to
|
||||
<https://github.com/louislam/uptime-kuma/security/advisories/new>.
|
||||
2. Please also create an empty security issue to alert me, as GitHub Advisories
|
||||
do not send a notification, I probably will miss it without this.
|
||||
<https://github.com/louislam/uptime-kuma/issues/new?assignees=&labels=help&template=security.md>
|
||||
|
||||
Do not use the public issue tracker or discuss it in public as it will cause more damage.
|
||||
Do not use the public issue tracker or discuss it in public as it will cause
|
||||
more damage.
|
||||
|
||||
## Do you accept other 3rd-party bug bounty platforms?
|
||||
|
||||
At this moment, I DO NOT accept other bug bounty platforms, because I am not familiar with these platforms and someone has tried to send a phishing link to me by doing this already. To minimize my own risk, please report through GitHub Advisories only. I will ignore all 3rd-party bug bounty platforms emails.
|
||||
At this moment, I DO NOT accept other bug bounty platforms, because I am not
|
||||
familiar with these platforms and someone has tried to send a phishing link to
|
||||
me by doing this already. To minimize my own risk, please report through GitHub
|
||||
Advisories only. I will ignore all 3rd-party bug bounty platforms emails.
|
||||
|
||||
## Supported Versions
|
||||
|
||||
### Uptime Kuma Versions
|
||||
|
||||
You should use or upgrade to the latest version of Uptime Kuma. All `1.X.X` versions are upgradable to the latest version.
|
||||
You should use or upgrade to the latest version of Uptime Kuma. All `1.X.X`
|
||||
versions are upgradable to the latest version.
|
||||
|
||||
### Upgradable Docker Tags
|
||||
|
||||
| Tag | Supported |
|
||||
|-|-|
|
||||
| 1 | :white_check_mark: |
|
||||
| 1-debian | :white_check_mark: |
|
||||
| latest | :white_check_mark: |
|
||||
| debian | :white_check_mark: |
|
||||
| 1-alpine | ⚠️ Deprecated |
|
||||
| alpine | ⚠️ Deprecated |
|
||||
| All other tags | ❌ |
|
||||
| Tag | Supported |
|
||||
| -------------- | ------------------ |
|
||||
| 1 | :white_check_mark: |
|
||||
| 1-debian | :white_check_mark: |
|
||||
| latest | :white_check_mark: |
|
||||
| debian | :white_check_mark: |
|
||||
| 1-alpine | ⚠️ Deprecated |
|
||||
| alpine | ⚠️ Deprecated |
|
||||
| All other tags | ❌ |
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user