• a9_707245
  • 107.8KB
  • zip
  • 0
  • VIP专享
  • 0
  • 2022-06-13 20:11
待定 一个基于 git 的去中心化 ci。 地位 预阿尔法。 您可能还不想使用它。 为什么是新的 CI? 我们很沮丧 付费解决方案的高昂成本(咳竹) 不灵活的 CI 服务器使其难以 自定义您的工作流程(例如将 master 合并到分支,然后构建 - 正如rust项目所做的那样) 系统之间的端口构建配置(甚至是运行相同软件的不同服务器) 回答简单的问题,比如did commit <sha> 2 months ago pass or fail? 回答简单的问题,例如What was the build configuration when <commit> failed the build?是What was the build configuration when <commit> failed the build? 鼓励开发人员不要检查其提交的构建状态的工作流 仅提供 Web
# tbd A decentralised ci built on git. ## Status Pre-Alpha. You probably don't want to use this yet. ## Why a new CI? We're frustrated with * The exorbitant cost of paid solutions (*cough* bamboo) * Inflexible CI servers making it difficult to - customise your workflow (e.g. merge master into branch, then build - as the `rust` project does) - port build configuration between systems (or even a different server running the same software) - answer simple questions like `did commit <sha> 2 months ago pass or fail?` - answer simple questions like `What was the build configuration when <commit> failed the build?` * Workflows which encourage developers not to check the build status of their commits * Tools that *only* provide web interfaces * CIs claiming flexibility because you can upload a plugin - Plugins are separately versioned & frequently implemented in a different language - It's not clear which version of a plugin was running when a build ran ## How is tbd different? Core ideas driving `tbd` which are different to traditional CI: * All CI configuration is maintained in the same repository as your code * Build results are stored in your git repository (not in the main tree)as git notes, alongside that commit's code ## Build storage `tbd` stores build results in a git ref (specifically `.git/refs/tbd/all-build-results` by default, controlled by git config tbd.ref or TBD_REF environment). tbd commits contain a directory for each commit/worktree which has ever been built. Because of how git stores files, this requires very little storage. Artifact storage is opt-in; your build configuration can include an array of artifacts which will be passed to `git add -f` and written to the build output. Example directory structure: ``` <source worktree sha> <spec:coverage> <build timestamp and host> STDOUT STDERR ETC artifacts/ application files build artifacts <source commit sha> <same thing> ``` When you run a build, tbd creates a new commit on the `.git/refs/tbd/all-build-results` ref To check a file that was modified by the build process: `git show tbd/all-build-results:<commit>/<metadata-hash>/<target>/WORKTREE/<artifact rel='nofollow' onclick='return false;'>` `git tbd show <ref-like> <target> [--build-number <metadata-hash, defaults to most recent>] -- artifacts/coverage.html` `git tbd show <ref-like> <target> [--build-number <metadata-hash, defaults to most recent>] <git show args>` `git tbd unpack <ref-like> <target> [--build-number <metadata-hash, defaults to most recent>] <dir_to_unpack_into>` ### Advantages * Builds can be viewed & data extracted without tbd tools installed * no changes required to repository config * git notes for each commit can link directly to the build ### Disadvantages No garbage collection for builds of a tree that was never pushed * not a problem unless devs are doing local builds and pushing the branch * probably not a problem since even on a large repo there's very little change * We could write a tool to strip out builds which aren't in the history (it'd re-write the branch) It's easy commit a large binary as part of the post-build worktree and hard to undo. * We'll need to make it obvious, when writing a build to git, that artifacts have been saved (name/size) A developer could carelessly check out `tbd/all-build-results`, which would cause a *lot* of files to be written to their machine. However, they would have to really be poking around since it's not in the `git branch` or `git tags` list. ## TODO ### Sort out a way to merge build result refs without checking them out Currently users have to checkout the build result ref to merge their builds. There's no good reason for this as we never want to diff/merge individual files, only trees (and we anticipate conflicts being extremely rare - will still need to figure out how to resolve them). Options investigated: * Storing in a `git notes` ref - Only supports blobs which is a non-starter * Storing in a branch - :+1: Sets up remote syncs easily by default - :-1: Easy to accidentally checkout - :+1: Still need to checkout to merge using `git pull` * Storing in a ref - need to write a custom mergetool (but it sounds like that was going to happen anyways) - eg `tbd-ff-merge refs/tbd/all-build-results refs/tbd/remotes/origin`