这是本节的多页打印视图。点击此处打印.

components-contrib仓库的构建学习

Dapr构建学习之components-contrib仓库

1: component-contrib仓库构建简介
2: Makefile文件
3: codedov文件
4: components-contrib仓库的workflow

4.1: components-contrib.yml

https://github.com/dapr/components-contrib

1 - component-contrib仓库构建简介

kit仓库适合入门

https://github.com/dapr/components-contrib

components-contrib 仓库相比 kit 仓库代码量要大很多仓库，但构建还是会比 dapr 仓库要简单。

备注：后续其他仓库的构建学习中，不会重复kit仓库中已有的内容。

2 - Makefile文件

定义和获取变量，定义 test/lint/go.mod/check-diff等target

https://github.com/dapr/components-contrib/blob/master/Makefile

变量定义

和 kit 仓库完全一致，跳过。

build target

然后就是正式的 build target 定义了。

其中 target test / target lint / target modtidy 和 kit 仓库完全一致，跳过。

Target: modtidy-all

在 modtidy 之外，还提供了一个 modtidy-all 的target，这是因为 conponents-contrib 仓库除了根目录下的 go.mod 之外，还在 ./tests/certification/ 目录下有多个 go.mod 文件。

find . -name go.mod
./go.mod
./tests/certification/bindings/azure/blobstorage/go.mod
./tests/certification/bindings/azure/cosmosdb/go.mod
./tests/certification/bindings/azure/servicebusqueues/go.mod
./tests/certification/go.mod
./tests/certification/pubsub/rabbitmq/go.mod
./tests/certification/pubsub/mqtt/go.mod
./tests/certification/pubsub/kafka/go.mod
./tests/certification/secretstores/azure/keyvault/go.mod
./tests/certification/state/sqlserver/go.mod

################################################################################
# Target: modtidy-all                                                          #
################################################################################
MODFILES := $(shell find . -name go.mod)  # 列出所有的 go.mod 文件，列表如上面所示

define modtidy-target
.PHONY: modtidy-$(1)
modtidy-$(1):
	# 进入每一个 go.mod 所在的目录，执行 go mod tidy，然后再返回原来的目录
	cd $(shell dirname $(1)); go mod tidy -compat=1.17; cd -
endef

# Generate modtidy target action for each go.mod file
# 为每个go.mod文件生成modtidy target动作
$(foreach MODFILE,$(MODFILES),$(eval $(call modtidy-target,$(MODFILE))))

# Enumerate all generated modtidy targets
# Note that the order of execution matters: root and tests/certification go.mod
# are dependencies in each certification test. This order is preserved by the
# tree walk when finding the go.mod files.
TIDY_MODFILES:=$(foreach ITEM,$(MODFILES),modtidy-$(ITEM))

# Define modtidy-all action trigger to run make on all generated modtidy targets
.PHONY: modtidy-all
modtidy-all: $(TIDY_MODFILES)

实际执行的日志输出如下：

make modtidy-all
cd .; go mod tidy -compat=1.17; cd -
/home/sky/work/code/dapr/components-contrib
cd ./tests/certification/bindings/azure/blobstorage; go mod tidy -compat=1.17; cd -
/home/sky/work/code/dapr/components-contrib
cd ./tests/certification/bindings/azure/cosmosdb; go mod tidy -compat=1.17; cd -
/home/sky/work/code/dapr/components-contrib
cd ./tests/certification/bindings/azure/servicebusqueues; go mod tidy -compat=1.17; cd -
/home/sky/work/code/dapr/components-contrib
cd ./tests/certification; go mod tidy -compat=1.17; cd -
/home/sky/work/code/dapr/components-contrib
cd ./tests/certification/pubsub/rabbitmq; go mod tidy -compat=1.17; cd -
/home/sky/work/code/dapr/components-contrib
cd ./tests/certification/pubsub/mqtt; go mod tidy -compat=1.17; cd -
/home/sky/work/code/dapr/components-contrib
cd ./tests/certification/pubsub/kafka; go mod tidy -compat=1.17; cd -
/home/sky/work/code/dapr/components-contrib
cd ./tests/certification/secretstores/azure/keyvault; go mod tidy -compat=1.17; cd -
/home/sky/work/code/dapr/components-contrib
cd ./tests/certification/state/sqlserver; go mod tidy -compat=1.17; cd -
/home/sky/work/code/dapr/components-contrib

Target: check-diff

################################################################################
# Target: check-diff                                                           #
################################################################################
.PHONY: check-diff
check-diff:
	.PHONY: check-diff
check-diff:
	git diff --exit-code -- '*go.mod' # check no changes
	git diff --exit-code -- '*go.sum' # check no changes

和 kit 仓库的 check-diff 仅仅检查 go.mod 文件不同，component-contrib 的 check-diff 还会检查 go.sum。

疑问：为什么 kit 仓库的 check-diff 不检查 go.sum 文件？

Target: conf-tests

执行一致性测试, 其中一致性的测试案例被标注有:

//go:build conftests
// +build conftests

总共有四个文件，都在 ./tests/conformance 目录下：

binding_test.go
pubsub_test.go
secretstores_test.go
state_test.go

################################################################################
# Target: conf-tests                                                           #
################################################################################
.PHONY: conf-tests
conf-tests:
	CGO_ENABLED=$(CGO) go test -v -tags=conftests -count=1 ./tests/conformance

但这些测试在本地是跑不起来的，因为缺乏对应的可连接的外部组件如 azure.eventhubs 、 azure.cosmosdb。

Target: e2e-tests-zeebe

端到端测试，类似：

################################################################################
# Target: e2e-tests-zeebe                                                      #
################################################################################
.PHONY: e2e-tests-zeebe
e2e-tests-zeebe:
	CGO_ENABLED=$(CGO) go test -v -tags=e2etests -count=1 ./tests/e2e/bindings/zeebe/...

3 - codedov文件

codedov的配置文件

components-contrib仓库配置

https://github.com/dapr/components-contrib/blob/master/.codecov.yaml

kit仓库的 .codecov.yaml 文件极其简单，只配置了 coverage.status 的少数属性：

coverage:
  # Commit status https://docs.codecov.io/docs/commit-status are used
  # to block PR based on coverage threshold.
  status:
    project:
      default:
        informational: true
    patch:
      # Disable the coverage threshold of the patch, so that PRs are
      # only failing because of overall project coverage threshold.
      # See https://docs.codecov.io/docs/commit-status#disabling-a-status.
      default: false
comment:
  # Delete old comment and post new one for new coverage information.
  behavior: new

和 kit 仓库的很不一样。

TODO：后面来看为啥差别这么大。

4 - components-contrib仓库的workflow

Dapr构建学习之components-contrib仓库的workflow

4.1 - components-contrib.yml

components-contrib workflow

components-contrib 仓库的 workflow 有多个：

https://github.com/dapr/components-contrib/tree/master/.github/workflows

先看最核心的 components-contrib.yml

https://github.com/dapr/components-contrib/blob/master/.github/workflows/components-contrib.yml

action基本设置

和 kit 仓库完全一致，这块感觉应该各个go仓库都差不多。

steps配置

step: Set up job

这是 github action 自身的job，主要是准备操作系统和相关的软件, 以及准备相关的 actions，以备后续步骤使用：

Prepare workflow directory
Prepare all required actions
Getting action download info
Download action repository 'fkirc/skip-duplicate-actions@v3.4.0' (SHA:4c656bbdb6906310fa6213604828008bc28fe55d)
Download action repository 'actions/setup-go@v2' (SHA:424fc82d43fa5a37540bae62709ddcc23d9520d4)
Download action repository 'actions/checkout@v2' (SHA:ec3a7ce113134d7a93b817d10a8272cb61118579)
Download action repository 'golangci/golangci-lint-action@v2.2.1' (SHA:54a84d46fb7183443c869b1b7d0dc34f640fcfd7)
Download action repository 'codecov/codecov-action@v1' (SHA:29386c70ef20e286228c72b668a06fd0e8399192)

和 kit 相比，fkirc/skip-duplicate-actions@v3.4.0 是个新的内容，其他都相同。

step: Check if need skip

和 kit 仓库相比，这是最大的不同，多了一个是否需要跳过的检查，在之后的多个步骤中，都相应的增加了对是否可以跳过的判断。

      - name: Check if need skip
        id: skip_check
        uses: fkirc/skip-duplicate-actions@v3.4.0
        with:
          cancel_others: 'true'
          paths_ignore: '["**.md", ".codecov.yaml", ".github/workflows/dapr-automerge.yml"]'

好处就是可以极大的提高CI执行的速度，因为如果判断出来可以跳过（之前执行过检查而之后没有文件变化），就会让后续的各个步骤直接跳过执行过程从而让CI极快的通过。

这是正常执行的 workflow 的情况, 绿色框中的步骤都正常执行，总耗时3分钟37秒：

normal

这是跳过之后的 workflow 的执行情况，可以看到绿色框中的步骤都被跳过，然后总耗时就从之前的3分钟37秒降到4秒：

skipped

检查一下日志，看这个step是怎么执行的：

Run fkirc/skip-duplicate-actions@v3.4.0
  with:
    cancel_others: true
    paths_ignore: ["**.md", ".codecov.yaml", ".github/workflows/dapr-automerge.yml"]
    github_token: ***
    paths: []
    skip_after_successful_duplicate: true					# 在成功之后的重复就跳过
    do_not_skip: ["workflow_dispatch", "schedule"]
    concurrent_skipping: never
  env:
    GOVER: 1.17
    GOOS: linux
    GOARCH: amd64
    GOPROXY: https://proxy.golang.org
    GOLANGCI_LINT_VER: v1.31
Did not find other workflow-runs to be cancelled
Skip execution because the exact same files have been successfully checked in https://github.com/dapr/components-contrib/actions/runs/1715733057							# 发现之前有成功的检查，而文件和当前完全相同

学习一下 fkirc/skip-duplicate-actions ：

https://github.com/fkirc/skip-duplicate-actions

skip-duplicate-actions 提供了以下功能来优化GitHub Actions:

在合并、拉动请求或类似情况下，跳过重复的工作流运行。

跳过并发的或平行的工作流运行，以避免运行两次。

跳过忽略的路径，以加快文档更改或类似的速度。

如果路径没有改变，则跳过目录特定的测试等内容。

在分支推送后取消过时的工作流运行。

所有这些功能都有助于节省时间和成本；特别是对于长期运行的工作流程。你可以选择这些功能的任何子集。

step: Set up Go

安装go的步骤，使用到前面准备的 action actions/setup-go@v1:

      - name: Set up Go ${{ env.GOVER }}
        if: ${{ steps.skip_check.outputs.should_skip != 'true' }}
        uses: actions/setup-go@v2
        with:
          go-version: ${{ env.GOVER }}

和 kit 仓库相比，只是多了一个 steps.skip_check.outputs.should_skip != 'true' 的判断，其他是一样的。

step: Check out code

checkout 代码的步骤，使用到前面准备的 action actions/checkout@v2:

      - name: Check out code into the Go module directory
        if: ${{ steps.skip_check.outputs.should_skip != 'true' }}
        uses: actions/checkout@v2

和 kit 仓库相比，只是多了一个 steps.skip_check.outputs.should_skip != 'true' 的判断，其他是一样的。

step：Run golangci-lint

执行golangci-lint的步骤，使用到前面准备的 action golangci/golangci-lint-action@v2.2.1:

      - name: Run golangci-lint
        if: matrix.target_arch == 'amd64' && matrix.target_os == 'linux' && steps.skip_check.outputs.should_skip != 'true'
        uses: golangci/golangci-lint-action@v2.2.1
        with:
          version: ${{ env.GOLANGCI_LINT_VER }}

和 kit 仓库相比，只是多了一个 steps.skip_check.outputs.should_skip != 'true' 的判断，其他是一样的。

step: Run go mod tidy check diff

使用到 Makefile 中定义的 target modtidy-all 和 check-diff:

      - name: Run go mod tidy check diff
        if: matrix.target_arch == 'amd64' && matrix.target_os == 'linux' && steps.skip_check.outputs.should_skip != 'true'
        run: make modtidy-all check-diff

和 kit 仓库相比, 除了需要检查的 go.mod 文件是多个之外，只是多了一个 steps.skip_check.outputs.should_skip != 'true' 的判断，其他是一样的。

step: Run make test

      - name: Run make test
        env:
          COVERAGE_OPTS: "-coverprofile=coverage.txt -covermode=atomic"
        if: matrix.target_arch != 'arm' && steps.skip_check.outputs.should_skip != 'true'
        run: make test

和 kit 仓库相比，只是多了一个 steps.skip_check.outputs.should_skip != 'true' 的判断，其他是一样的。

step: Codecov

step: Post Run golangci-lint

step: Post Check out code

和 kit 仓库相同。

总结

components-contrib 的 workflow 和 kit 仓库基本相同，只是多了一个 skip-duplicate-actions 的优化。

备注：估计是 kit 仓库还没有来得及做这个 skip-duplicate-actions 优化，如果做了，就又一致了。