有网友碰到这样的问题“自部署Gitea实现简易CI/CD”。小编为您整理了以下解决方案，希望对您有帮助：
解决方案1：
项目需求是，当代码被推送至Gitea后，自动执行Docker构建与运行。分析了市面上的解决方案，Jenkins因内存消耗大且性能不佳被排除。尝试使用Gitea action，但因网络问题无法从测试环境的GitHub action拉取项目，且action运行过程复杂，难以满足需求。考虑到需求较为简单，放弃深入研究action，转而探索Webhook方案，通过在本地部署HTTP服务器接收Gitea发送的Webhook，然后使用脚本操作Docker来实现CI/CD流程。项目地址还未搭建，待有空时进行。
为了简化实现过程，选择Golang作为实现语言。Golang能够原生编译且拥有齐全的工具链，支持交叉编译，相较于Python、Java、C#等语言，无需依赖第三方库，且具备良好的性能。通过将需求提交给GPT，获取到实现模板。关键代码已整合，尽量避免了错误处理的冗长。测试时，将cloneUrl地址转换为Docker虚拟网卡地址，以确保Webhook能够正常触发。
对于Webhook的实现，Golang的错误处理机制较为复杂，需要细心处理。测试环境下的cloneUrl地址为localhost:3000，导致无法正常运行，解决方案是将地址更改为Docker虚拟网卡的地址，提高稳定性。另外，补充了go.mod文件，由于使用的是原生库，此文件的添加与否对实现并无影响。
在实现过程中，构建了一个Docker-compose.yaml文件用于启动Gitea，同时准备了一个通用的Dockerfile以适应前端项目的部署需求。考虑到自动起的端口固定为40030:80，可能不适用于后续需求变化，计划在程序内部添加逻辑，根据repo-description或其他字段调整端口映射，以提高灵活性。当前仅考虑满足自身前端页面自动更新的需求，暂未有其他要求，因此未进行优化。
在容器内部操作Docker遇到挑战，尝试在普通Alpine镜像中挂载/usr/bin/docker后，发现映射失败。最终选择在Alpine Linux基础上安装Docker CLI，以确保Docker命令的正常执行。同时，遇到了WSL环境下的一系列问题，包括Docker Desktop闪退、Docker Compose创建网络失败等，解决方法是先手动创建网络，再启动Docker Compose。
Gitea自身也存在报错问题，指出Webhook只能调用允许的HTTP服务器（检查webhook.ALLOWED_HOST_LIST设置），拒绝了本地服务器（172.18.0.3:3001）。为解决此问题，在Gitea的app.ini配置文件中添加了额外的配置。虽然配置*可能存在安全隐患，但考虑到仅为个人使用，此方案较为便捷。