Dagster 如何配置 GitHub Actions 或 GitLab CI/CD 自动部署代码【免费下载链接】dagsterAn orchestration platform for the development, production, and observation of data assets.项目地址: https://gitcode.com/GitHub_Trending/da/dagster当你把 Dagster 项目代码托管到 GitHub 或 GitLab 后希望在每次推送代码时自动把变更部署到 DagsterServerless 或 Hybrid而不用每次手动运行部署命令官方文档提供了一条统一的操作路径用dg plus deploy configure命令在项目中脚手架生成对应的 CI/CD 工作流文件GitHub Actions workflow 或.gitlab-ci.yml再把 Dagster Cloud API token 配置为仓库的 Secret / CI/CD 变量之后 commit 并 push 即可触发自动部署。本文适用前提你已经拥有一个 Dagster 项目例如通过uvx create-dagsterlatest project my-project创建见 创建 Dagster 项目并已通过dg plus login登录到你的 Dagster 组织。完整官方文档见 配置 Dagster 中的 CI/CD。GitHub Actions 路径GitHub 路径的额外前置条件来自文档的 Prerequisites 说明已创建 Dagster 项目已安装 GitHub 官方ghCLI并通过gh auth login完成认证已通过dg plus login登录 Dagster 组织。操作步骤进入项目根目录并激活虚拟环境cd project-directory source .venv/bin/activate # MacOS/UnixWindows 使用 .venv\Scripts\activate其中project-directory替换为你自己的项目目录。添加依赖dagster-cloud作为运行时依赖dagster-dg-cli作为 dev 依赖。dagster-cloud必须安装在生产容器内Dagster code server 才能启动dagster-dg-cli只在 CI 中运行执行dg list projects和dg plus deploy最终镜像通过uv sync --no-dev将其排除。uv add dagster-cloud uv add --dev dagster-dg-cli如果使用 pippip install dagster-cloud pip install --group dev注意pip install --group要求 pip 25.1 或更高版本2025 年 4 月它从pyproject.toml的[dependency-groups.dev]读取依赖项目若未使用 PEP 735 dependency groups改为直接pip install dagster-dg-cli。另外如果项目是用create-dagster project创建的dagster-dg-cli已声明为 dev 依赖可跳过上述--dev命令。初始化本地 Git 仓库并通过gh repo create创建关联的 GitHub 远程仓库。提示选择时选择Push an existing local repository to github.comgit init . gh repo create用dg plus deploy configure脚手架生成部署配置文件包括 GitHub Actions workflow 文件--git-provider指定为githubdg plus deploy configure --git-provider github创建 Dagster Cloud API token并一步设置为该项目的 GitHub Actions secretDAGSTER_CLOUD_API_TOKENdg plus create ci-api-token --description Used in my-project GitHub Actions | gh secret set DAGSTER_CLOUD_API_TOKEN提交并推送触发部署git add . git commit -m Deploy to Dagster git push origin mainGitLab CI/CD 路径GitLab 路径的前置条件已创建 Dagster 项目并已通过dg plus login登录 Dagster 组织。进入项目根目录、激活虚拟环境、安装依赖命令与 GitHub 路径中的第 1、2 步完全相同此处不再重复。初始化仓库并做首次提交git init . git add . git commit -m Initial commit在 GitLab 上创建远程仓库并推送。可以在 GitLab 界面手动新建项目或用命令行推送命令中的USERNAME替换为你的 GitLab 用户名或组织 workspacegit push --set-upstream gitgitlab.com:USERNAME/$(git rev-parse --show-toplevel | xargs basename).git $(git rev-parse --abbrev-ref HEAD)脚手架生成 GitLab CI/CD 配置文件dg plus deploy configure --git-provider gitlab创建 Dagster Cloud API tokendg plus create ci-api-token --description Used in Dagster project GitHub Actions将该 token 配置为 GitLab 仓库的 CI/CD 变量进入 GitLab 项目页面左侧栏点击SettingsCI/CD再点击Variables在Project variables下点击Add variableKey 填DAGSTER_CLOUD_API_TOKENValue 粘贴上一步生成的 token可按需修改变量类型、环境、可见性、标志和描述最后点击Add variable。完成以上配置后之后每次向 GitLab 仓库 commit 并 push 新变更都会自动部署到你的 Dagster 组织。如何确认部署成功GitHub 路径部署过程中agent 会尝试加载你的代码并更新 Dagster 中的元数据。完成后GitHub Action 显示成功结束并且能在 Dagster 的Deployment标签下看到对应的 code location。GitLab 路径文档以 push 后自动部署作为成功条件部署结果同样体现在 Dagster 组织的 code location 中。关于 Serverless 部署形态的补充向main分支推送变更会自动部署到 DagsterPull / Merge Request 会创建临时的 branch deployment可以在 Dagster UI 中预览和测试。CI 中环境变量如何处理文档说明部署过程中你在 Dagster 部署里配置的环境变量会在代码加载阶段自动获取并可用。也就是说需要数据库密码、API key 等凭据的组件在 CI 中可以直接访问这些值不需要把它们再复制一份成 GitHub Secrets作用域完整部署还是 branch deployment会根据部署类型自动选择。GitHub Actions 工作流版本维护文档建议大约每 6 个月更新一次 workflow 文件中 Dagster GitHub Actions 的版本这些 action 使用跟随 Dagster 发布节奏的版本 tag例如v1.11.13。如果你的组织要求第三方 action 必须固定到完整 commit SHA该策略递归覆盖dagster-cloud-action内部引用的actions/checkout、docker/build-push-action等需要使用dagster-io/dagster-cloud-actionv1.13.11 或更高版本从该版本起Dagster action 内部引用的第三方 action 全部固定到完整 commit SHA。更早的版本即使把 Dagster action 本身固定到 SHA在策略启用时仍会导致 workflow 失败。文档给出的工作流片段示例其中full-length-commit-sha需替换为对应版本的完整 commit SHA- name: Pre-run checks id: prerun uses: dagster-io/dagster-cloud-action/actions/utils/prerunfull-length-commit-sha # v1.13.11不使用 GitHub/GitLab 时的替代方式如果你使用其他 Git provider 或本地 Git 仓库可以不依赖上述自动化流程改用 CLI 手动部署作为可选分支了解即可Serverless先在 CI 或本地完成认证交互式用dg plus login再运行dagster-cloud serverless deploy-python-executableWindows 上改用dagster-cloud serverless deploy例如dagster-cloud serverless deploy-python-executable ./my-project \ --location-name example \ --package-name YOUR_PACKAGE_NAME \ --python-version 3.12其中./my-project为你的项目目录YOUR_PACKAGE_NAME替换为你的 Dagster 包名。Hybrid先用dg plus deploy configure脚手架生成 Dockerfile、build.yaml、container_context.yaml设置DAGSTER_CLOUD_ORGANIZATION、DAGSTER_CLOUD_API_TOKEN敏感值建议存为 CI/CD secret、DAGSTER_BUILD_STATEDIR指向构建机上空白或尚不存在的临时目录三个变量均为必填然后依次执行dg plus deploy start --deploymentDEPLOYMENT_NAME --project-dir.、dg plus deploy build-and-push上传到build.yaml中指定的镜像仓库需要该仓库的认证、dg plus deploy成功后可在 Dagster 的Deployments标签下看到 code location。两条主路径的共同核心就是dg plus deploy configure --git-provider github|gitlab生成的工作流文件加上DAGSTER_CLOUD_API_TOKEN这一 Secret/变量其余差异只体现在仓库创建和 token 配置方式上。【免费下载链接】dagsterAn orchestration platform for the development, production, and observation of data assets.项目地址: https://gitcode.com/GitHub_Trending/da/dagster创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Dagster 如何配置 GitHub Actions 或 GitLab CI/CD 自动部署代码【免费下载链接】dagsterAn orchestration platform for the development, production, and observation of data assets.项目地址: https://gitcode.com/GitHub_Trending/da/dagster当你把 Dagster 项目代码托管到 GitHub 或 GitLab 后希望在每次推送代码时自动把变更部署到 DagsterServerless 或 Hybrid而不用每次手动运行部署命令官方文档提供了一条统一的操作路径用dg plus deploy configure命令在项目中脚手架生成对应的 CI/CD 工作流文件GitHub Actions workflow 或.gitlab-ci.yml再把 Dagster Cloud API token 配置为仓库的 Secret / CI/CD 变量之后 commit 并 push 即可触发自动部署。本文适用前提你已经拥有一个 Dagster 项目例如通过uvx create-dagsterlatest project my-project创建见 创建 Dagster 项目并已通过dg plus login登录到你的 Dagster 组织。完整官方文档见 配置 Dagster 中的 CI/CD。GitHub Actions 路径GitHub 路径的额外前置条件来自文档的 Prerequisites 说明已创建 Dagster 项目已安装 GitHub 官方ghCLI并通过gh auth login完成认证已通过dg plus login登录 Dagster 组织。操作步骤进入项目根目录并激活虚拟环境cd project-directory source .venv/bin/activate # MacOS/UnixWindows 使用 .venv\Scripts\activate其中project-directory替换为你自己的项目目录。添加依赖dagster-cloud作为运行时依赖dagster-dg-cli作为 dev 依赖。dagster-cloud必须安装在生产容器内Dagster code server 才能启动dagster-dg-cli只在 CI 中运行执行dg list projects和dg plus deploy最终镜像通过uv sync --no-dev将其排除。uv add dagster-cloud uv add --dev dagster-dg-cli如果使用 pippip install dagster-cloud pip install --group dev注意pip install --group要求 pip 25.1 或更高版本2025 年 4 月它从pyproject.toml的[dependency-groups.dev]读取依赖项目若未使用 PEP 735 dependency groups改为直接pip install dagster-dg-cli。另外如果项目是用create-dagster project创建的dagster-dg-cli已声明为 dev 依赖可跳过上述--dev命令。初始化本地 Git 仓库并通过gh repo create创建关联的 GitHub 远程仓库。提示选择时选择Push an existing local repository to github.comgit init . gh repo create用dg plus deploy configure脚手架生成部署配置文件包括 GitHub Actions workflow 文件--git-provider指定为githubdg plus deploy configure --git-provider github创建 Dagster Cloud API token并一步设置为该项目的 GitHub Actions secretDAGSTER_CLOUD_API_TOKENdg plus create ci-api-token --description Used in my-project GitHub Actions | gh secret set DAGSTER_CLOUD_API_TOKEN提交并推送触发部署git add . git commit -m Deploy to Dagster git push origin mainGitLab CI/CD 路径GitLab 路径的前置条件已创建 Dagster 项目并已通过dg plus login登录 Dagster 组织。进入项目根目录、激活虚拟环境、安装依赖命令与 GitHub 路径中的第 1、2 步完全相同此处不再重复。初始化仓库并做首次提交git init . git add . git commit -m Initial commit在 GitLab 上创建远程仓库并推送。可以在 GitLab 界面手动新建项目或用命令行推送命令中的USERNAME替换为你的 GitLab 用户名或组织 workspacegit push --set-upstream gitgitlab.com:USERNAME/$(git rev-parse --show-toplevel | xargs basename).git $(git rev-parse --abbrev-ref HEAD)脚手架生成 GitLab CI/CD 配置文件dg plus deploy configure --git-provider gitlab创建 Dagster Cloud API tokendg plus create ci-api-token --description Used in Dagster project GitHub Actions将该 token 配置为 GitLab 仓库的 CI/CD 变量进入 GitLab 项目页面左侧栏点击SettingsCI/CD再点击Variables在Project variables下点击Add variableKey 填DAGSTER_CLOUD_API_TOKENValue 粘贴上一步生成的 token可按需修改变量类型、环境、可见性、标志和描述最后点击Add variable。完成以上配置后之后每次向 GitLab 仓库 commit 并 push 新变更都会自动部署到你的 Dagster 组织。如何确认部署成功GitHub 路径部署过程中agent 会尝试加载你的代码并更新 Dagster 中的元数据。完成后GitHub Action 显示成功结束并且能在 Dagster 的Deployment标签下看到对应的 code location。GitLab 路径文档以 push 后自动部署作为成功条件部署结果同样体现在 Dagster 组织的 code location 中。关于 Serverless 部署形态的补充向main分支推送变更会自动部署到 DagsterPull / Merge Request 会创建临时的 branch deployment可以在 Dagster UI 中预览和测试。CI 中环境变量如何处理文档说明部署过程中你在 Dagster 部署里配置的环境变量会在代码加载阶段自动获取并可用。也就是说需要数据库密码、API key 等凭据的组件在 CI 中可以直接访问这些值不需要把它们再复制一份成 GitHub Secrets作用域完整部署还是 branch deployment会根据部署类型自动选择。GitHub Actions 工作流版本维护文档建议大约每 6 个月更新一次 workflow 文件中 Dagster GitHub Actions 的版本这些 action 使用跟随 Dagster 发布节奏的版本 tag例如v1.11.13。如果你的组织要求第三方 action 必须固定到完整 commit SHA该策略递归覆盖dagster-cloud-action内部引用的actions/checkout、docker/build-push-action等需要使用dagster-io/dagster-cloud-actionv1.13.11 或更高版本从该版本起Dagster action 内部引用的第三方 action 全部固定到完整 commit SHA。更早的版本即使把 Dagster action 本身固定到 SHA在策略启用时仍会导致 workflow 失败。文档给出的工作流片段示例其中full-length-commit-sha需替换为对应版本的完整 commit SHA- name: Pre-run checks id: prerun uses: dagster-io/dagster-cloud-action/actions/utils/prerunfull-length-commit-sha # v1.13.11不使用 GitHub/GitLab 时的替代方式如果你使用其他 Git provider 或本地 Git 仓库可以不依赖上述自动化流程改用 CLI 手动部署作为可选分支了解即可Serverless先在 CI 或本地完成认证交互式用dg plus login再运行dagster-cloud serverless deploy-python-executableWindows 上改用dagster-cloud serverless deploy例如dagster-cloud serverless deploy-python-executable ./my-project \ --location-name example \ --package-name YOUR_PACKAGE_NAME \ --python-version 3.12其中./my-project为你的项目目录YOUR_PACKAGE_NAME替换为你的 Dagster 包名。Hybrid先用dg plus deploy configure脚手架生成 Dockerfile、build.yaml、container_context.yaml设置DAGSTER_CLOUD_ORGANIZATION、DAGSTER_CLOUD_API_TOKEN敏感值建议存为 CI/CD secret、DAGSTER_BUILD_STATEDIR指向构建机上空白或尚不存在的临时目录三个变量均为必填然后依次执行dg plus deploy start --deploymentDEPLOYMENT_NAME --project-dir.、dg plus deploy build-and-push上传到build.yaml中指定的镜像仓库需要该仓库的认证、dg plus deploy成功后可在 Dagster 的Deployments标签下看到 code location。两条主路径的共同核心就是dg plus deploy configure --git-provider github|gitlab生成的工作流文件加上DAGSTER_CLOUD_API_TOKEN这一 Secret/变量其余差异只体现在仓库创建和 token 配置方式上。【免费下载链接】dagsterAn orchestration platform for the development, production, and observation of data assets.项目地址: https://gitcode.com/GitHub_Trending/da/dagster创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
