Proposal for sig-build: a new SIG to focus on tooling for building and releasing Dapr

[shubham1172]

Introduction

With each release, the Dapr build system is getting more and more complex. In the past few releases, we have added

1. Support for Dapr build variants #3168
2. Support for new Windows Server 2022 images #5644
3. Build Tools CLI #4729 to manage e2e and perf image builds
4. Support for nightly builds #4124

There are multiple entry points for configuring build steps, including workflows, scripts, Makefiles, and CLI tools. These work at different parts of the release lifecycle, e.g. when a PR is merged to master, when a release is cut, or when tests are run. This also results in bugs going unnoticed until a release is cut, and then we have to fix them at the eleventh hour - e.g., the following fixes in the 1.11 release

1. Skip pushing latest windows tags and remove duplicates from dapr-publish step dapr#6484
2. Fix missing latest tag env. dapr#6482
3. Fix publishing of artifacts. dapr#6476

With this sig-build, the objective is to make the build and release process more robust and reliable. It should be easier to introduce enhancements and the process should be less error-prone.

Scope and Responsibilities

The SIG will be responsible for:

1. Oversight and maintenance of existing build systems
2. Enhancing the existing build system and making it robust and reliable

The main items in scope are:

1. Build pipelines: Building Dapr binaries for different os/arch combinations, build flavors (stable, allcomponents), release channels (edge, nightly, rc).
2. Test builds: Creating build images for e2e and perf test apps and caching of images.

Build enhancements

The first major project of sig-build will be to enhance the existing build pipeline and make it robust.

Here are some potential tooling options -

1. goreleaser
2. nix
3. mage

/cc @artursouza, @JoshVanL

[msfussell]

@shubham1172 - Do you intend to take this proposal and SIG group forward?

[mikeee]

I'd be interested in taking part if this is brought forward 🛠️

[shubham1172]

Hello @msfussell, I don't have the bandwidth right now to take this up, however I am happy to contribute if @mikeee or anyone else wants to take the SIG forward.

[mikeee]

@msfussell @yaron2 I'd like to take this forward with more or less the same aims as SIG-Release

https://github.com/dapr/proposals/pull/68/files

SIG-Release would formalise and make the release process less transient and have the following aims:

• Document and maintain automated tooling for releases (located in dapr/release)
• Ownership and maintenance of existing build workflows
• Ensuring wide distribution of packages e.g. CLI distribution to more package repositories (snap/chocolatey...)
• Promote community attendance and active participation as part of the release process (not ownership of issues)

Post-release issues are still not a problem of the past and I would like to propose this as an item for the next STC meeting.