mirror of
https://github.com/veggiemonk/awesome-docker.git
synced 2025-11-24 09:24:29 +01:00
* - ✅ Removed 3 broken links (labex.io, hashnode.com entries) - ✅ Fixed rust-lang.org redirect issue - ✅ Added problematic domains to exclusion list (YouTube playlists, aquasec, cloudsmith) - ✅ Updated all npm dependencies to latest versions - ✅ **health_check.mjs** - Comprehensive repository health checker - Detects archived repositories - Identifies stale projects (2+ years inactive) - Flags inactive projects (1-2 years) - Generates detailed health reports - Run with: `npm run health-check` - ✅ **test_all.mjs** - Now detects archived repositories - Added `isArchived` field to GraphQL query - Warns about archived repos that should be marked `💀` - Non-blocking warnings (doesn't fail builds) - Runs every Monday at 9 AM UTC - Checks all 731+ GitHub repositories for health - Auto-creates/updates GitHub issue with findings - Labels: `health-report`, `maintenance` - Manual trigger available - Runs every Saturday at 2 AM UTC - Tests all external links - Auto-creates issue when links break - Auto-closes issue when all links fixed - Labels: `broken-links`, `bug` - Already checks for duplicates - Now also checks for archived repos - Validates link format and availability - ✅ **MAINTENANCE.md** - Complete guide for maintainers - Monthly, quarterly, and annual tasks - Emergency procedures - Quality standards - Metrics to track - ✅ **AGENTS.md** - Updated with new commands - Added health-check command - Noted GITHUB_TOKEN requirements - Added alphabetical sorting guideline - **Total Links**: 883 (731 GitHub repos + 152 external) - **Working Links**: >99% (after fixes) - **Abandoned Projects**: 15 marked with `💀` - **Automated Checks**: 3 workflows running - **Automatic detection** of abandoned/archived projects - **Weekly monitoring** ensures issues are caught early - **Proactive alerts** via GitHub issues - No more manual link checking (automated weekly) - Archived repos detected automatically - Contributors get instant PR feedback - Health metrics tracked over time - Clear standards documented - Easy onboarding for new maintainers - Monday: Health report generated and posted - Saturday: Link validation runs - Review health report issue - Mark any newly archived projects with `💀` - Run full health check: `npm run health-check` - Review inactive projects (1-2 years) - Consider removing very old abandoned projects - Deep cleanup of `💀` projects - Update documentation - Review categories and organization 1. **Auto-PR for Archived Repos**: Bot could auto-create PRs to mark archived repos 2. **Contribution Stats**: Track and display top contributors 3. **Category Health**: Per-category health metrics 4. **Dependency Updates**: Dependabot for npm packages 5. **Star Trending**: Track which projects are gaining popularity - `tests/health_check.mjs` - Health checker script - `.github/workflows/health_report.yml` - Weekly health workflow - `.github/workflows/broken_links.yml` - Link validation workflow - `.github/MAINTENANCE.md` - Maintainer guide - `AGENTS.md` - AI agent guidelines - `README.md` - Removed 3 broken links, fixed 1 redirect - `tests/test_all.mjs` - Added archive detection - `tests/exclude_in_test.json` - Added problematic domains - `package.json` - Added health-check script - `package-lock.json` - Updated dependencies Before: Manual maintenance, broken links accumulate, outdated projects linger After: **Automated health monitoring, proactive issue detection, systematic maintenance** The list is now **self-maintaining** with minimal human oversight required. --- *Generated: 2025-10-01* * update github actions * remove dead links * set timeout * Add badges
49 lines
2.4 KiB
Markdown
49 lines
2.4 KiB
Markdown
<!-- Congrats on creating an Awesome Docker entry! 🎉 -->
|
|
|
|
<!-- **Remember that entries are ordered alphabetically** -->
|
|
|
|
# TLDR
|
|
* all entries sorted alphabetically (from A to Z),
|
|
* If paying service add :heavy_dollar_sign:
|
|
* If WIP add :construction:
|
|
* clear and short description of the project
|
|
* project MUST have: How to setup/install
|
|
* project MUST have: How to use (examples)
|
|
* we can help you get there :)
|
|
|
|
## Quality Standards
|
|
|
|
Note that we can help you achieve those standards, just try your best and be brave.
|
|
We'll guide you to the best of our abilities.
|
|
|
|
To be on the list, it would be **nice** if entries adhere to these quality standards:
|
|
|
|
- It should take less than 20 sec to find what is the project, how to install it and how to use it.
|
|
- Generally useful to the community.
|
|
- A project on GitHub with a well documented `README.md` file and plenty of examples is considered high quality.
|
|
- Clearly stating if an entry is related to (Linux) containers and not to Docker. There is an [awesome list](https://github.com/Friz-zy/awesome-linux-containers) for that.
|
|
- Clearly stating "what is it" i.e. which category it belongs to.
|
|
- Clearly stating "what is it for" i.e. mention a real problem it solves (even a small one). Make it clear for the next person.
|
|
- If it is a **WIP** (work in progress, not safe for production), please mention it. (Remember the time before Docker 1.0 ? ;-) )
|
|
- Always put the link to the GitHub project instead of the website!
|
|
|
|
To be on the list, the project **must** have:
|
|
|
|
- How to setup/install the project
|
|
- How to use the project (examples)
|
|
|
|
If your PR is not merged, we will tell you why so that you may be able to improve it.
|
|
But usually, we are pretty relaxed people, so just come and say hi, we'll figure something out together.
|
|
|
|
# Rules for Pull Request
|
|
|
|
- Each item should be limited to one link, no duplicates, no redirection (careful with `http` vs `https`!)
|
|
- The link should be the name of the package or project or website
|
|
- Description should be clear and concise (read it out loud to be sure)
|
|
- Description should follow the link, on the same line
|
|
- Entries are listed alphabetically, please respect the order
|
|
- If you want to add more than one link, please don't do all PR on the exact same line, it usually results in conflicts and your PR cannot be automatically merged...
|
|
|
|
Please contribute links to packages/projects you have used or are familiar with. This will help ensure high-quality entries.
|
|
|