Gitea Action 简单配置(CI/CD)

线上pipeline,(我使用是本地仓库的,你们使用切换成官网的即可)

# 工作流的名称

name: Build and Push Docker Image deployment-k8s

# 触发条件,只在 master 或 main 分支发送推送时触发
on:
  push:
    branches:
      - main

# 作业,工作流运行由一个或多个 jobs 组成,默认情况下并行运行
jobs:
  build-and-push-image:
    # 定义要运行作业的计算机类型
    runs-on: ubuntu-latest
    steps:
    # 检出代码
    - name: Checkout Code
      #uses: actions/checkout@v4
      uses: http://192.168.0.20:3000/admins/checkout@main

    # 设置 Docker BuildX
    - name: Set up Docker Buildx
      id: buildx
      #uses: docker/setup-buildx-action@v2.6.0
      uses: http://192.168.0.20:3000/admins/setup-buildx-action@v2.6.0

    # 登录 Registry       
    - name: Login to DockerHub
      #uses: docker/login-action@v2
      uses: http://192.168.0.20:3000/admins/login-action@v3
      with:
        registry: ${{ secrets.REGISTRY }}
        username: ${{ secrets.DOCKER_USERNAME }}
        password: ${{ secrets.DOCKER_PASSWORD }}
   
   
    # 构建并推送 Docker 镜像
    - name: Build Docker Image 
      id: docker_build
      uses: http://192.168.0.20:3000/admins/build-push-action@v4
      #uses: docker/build-push-action@v4
      with:
        push: true
        file: ./Dockerfile-uat
        tags: ${{ secrets.REGISTRY_PATH }}/www:${{ github.sha }}

    # 部署k8s
    - name: deploy to cluster
      #uses: actions-hub/kubectl@master
      uses: http://192.168.0.20:3000/admins/kubectl@main
      env:
        KUBE_CONFIG: ${{ secrets.KUBE_CONFIG_DATA_160 }}
      with:
        args: set image deployment/www-web www-web=${{ secrets.REGISTRY_PATH }}/www:${{ github.sha }}  -n test

    - name: verify deployment
      uses: http://192.168.0.20:3000/admins/kubectl@main
      env:
        KUBE_CONFIG: ${{ secrets.KUBE_CONFIG_DATA_160 }}
      with:
        args: rollout status deployment/www-web  -n test

流水线变量 — 设置>>>> Runner >>> 密钥(输入你的变量)

在这里插入图片描述

注意原生使用k8s,然后在加入变量中

cat $HOME/.kube/config | base64

如果你是AWS EKS如下简单配置使用专门EKS镜像:

    - name: Deploy Application
      uses: statsig-io/kubectl-via-eksctl@main
      env:
        aws_access_key_id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws_secret_access_key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        region: ap-northeast-1
        cluster: ${{ secrets.CLUSTER_NAME }}
      with:
        args: get pods -n prometheus
        #args: set image deployment/my-app container=${{ github.repository}}:${{ github.sha }}
Gitea Action工具链更丰富以下是他的市场和工具链,大家可以自己选择自己喜欢的工具
#镜像包
https://github.com/actions/runner-images?tab=readme-ov-file#available-images

#入门文档
https://docs.github.com/zh/actions/writing-workflows/quickstart

#市场
https://github.com/marketplace?type=actions
最后还可以加入一个webhook,目前只找到一个飞书的
    - name: Send Text Message
      #uses: foxundermoon/feishu-action@v2
      uses: http://192.168.0.20:3000/admins/feishu-action@v2
      with:
        url: ${{ secrets.FEISHU_BOT_WEBHOOK_URL }}
        msg_type: text
        content: |
          text: |
           发布者/项目名: ${{ github.repository }}
           项目状态: ${{ job.status }}   

在这里插入图片描述

### Gitea CI/CD 集成设置与配置 #### 安装和准备阶段 为了使 Gitea 能够顺利集成 CI/CD 流程,首先需要确保服务器具备适当版本的 Java 环境。如果当前环境中存在旧版 JDK 版本,则可能会影响某些工具的功能正常运作[^3]。 对于 Jenkins 的部署,在 OpenShift 上仅提供单个 Maven Pod 可能会限制并行处理能力,进而影响构建效率。因此建议确认集群资源分配情况以及 Pod 数量设定是否合理[^1]。 #### 创建 Webhook 和服务端点 要在 Gitea 中启用自动化持续集成流程,需创建一个指向 CI 工具(如 Jenkins 或 GitLab Runner)的服务钩子(webhook),每当有新的提交推送到仓库时触发相应的动作。具体操作如下: - 登录至 Gitea 控制面板; - 进入目标项目页面; - 寻找 “Settings -> Webhooks & Services” 选项卡; - 添加一个新的 webhook 或者激活已有的 CI service plugin; ```json { "url": "http://<your-jenkins-server>/github-webhook/", "content_type": "json", "secret": "<webhook-secret>", "events": ["push"] } ``` 此 JSON 数据结构定义了当检测到推送事件发生时应向何处发送通知请求,并指定了通信所使用的数据格式为 `application/json` 类型[^2]。 #### 构建流水线文件 接下来要做的就是在项目的根目录下放置名为 `.gitea/workflows.yml` 或其他支持的语言特定命名约定下的 YAML 文件来描述整个 CI/CD 生命周期内的各个步骤。下面是一个简单的例子用于展示如何利用多云特性简化应用发布过程而不必手动编写额外脚本。 ```yaml name: Build and Deploy Application Pipeline on: push: branches: - main jobs: build: runs-on: ubuntu-latest steps: - name: Checkout codebase uses: actions/checkout@v2 - name: Set up JDK 17 uses: actions/setup-java@v2 with: distribution: 'temurin' java-version: '17' - run: mvn clean install deploy: needs: build runs-on: self-hosted # Assuming you have a runner configured within your infrastructure. environment: production steps: - name: Fetch latest artifact from previous job id: download_artifact uses: dawidd6/action-download-artifact@v2 with: workflow: ci- name: Execute deployment strategy defined by the platform env: DEPLOYMENT_ENVIRONMENT: ${{ secrets.DEPLOYMENT_ENV }} run: | echo "Deploying application..." # Here would be commands interacting with cloud provider APIs or container orchestration tools like Kubernetes CLI. ``` 上述代码片段展示了通过 GitHub Actions 来管理基于 Gitea 触发器启动的工作流实例化逻辑。它包含了两个主要部分:“build”负责编译源码包,“deploy”则执行实际的应用程序部署任务。值得注意的是这里的自托管运行器(`self-hosted`)意味着你需要预先准备好能够访问内部网络资源的机器作为执行节点。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值