proposal for build multi arch images

README.md

@@ -16,7 +16,7 @@ Workgroup is a virtual team of aggregating the efforts of all the interested par
 |[Scanning](./workgroups/wg-scanning/README.md)|The obejct of workgroup is centralizing and focusing efforts on supporting the ability of Harbor users to choose which container image scanner they want to use with Harbor directly|(Zach Hill@Anchore [zhill](https://github.com/zhill))|Daniel Pacak@Aqua Security ([danielpacak](https://github.com/danielpacak)) / Steven Zou@VMware ([steven-zou](https://github.com/steven-zou))|Liz Rice@Aqua Security ([lizrice](https://github.com/lizrice)), Daniel Pacak@Aqua Security ([danielpacak](https://github.com/danielpacak)), Steven Zou@VMware ([steven-zou](https://github.com/steven-zou))|
 |[P2P Distribution](https://github.com/goharbor/community/tree/master/workgroups/wg-p2p)|The objective of this working group is to aggregate efforts to discuss, design and finally deliver suitable P2P image distribution solutions for Harbor.|Fanjian Kong@Qihoo ([kofj](https://github.com/kofj))| Steven Zou@VMware ([steven-zou](https://github.com/steven-zou)) |[5 Members](https://github.com/goharbor/community/tree/master/workgroups/wg-p2p#members)|
 |[Operator](./workgroups/wg-operator/README.md)|Aggregate the efforts from all the interested parties to discuss, design and finally deliver suitable Operator solutions for Harbor|Steven Zou@VMware ([steven-zou](https://github.com/steven-zou))| - | [14 Members](https://github.com/goharbor/community/blob/master/workgroups/wg-operator/README.md#members)|Steven Zou@VMware ([steven-zou](https://github.com/steven-zou))| - |[5 members](https://github.com/goharbor/community/tree/master/workgroups/wg-p2p#members)|
-|[Multi Architecture](https://github.com/goharbor/community/tree/master/workgroups/wg-multiarch)|The purpose of this working group is to enable Harbor to support multiple architectures, such as x86 arm.|ZhiPeng Yu@Alauda ([yuzp1996](https://github.com/yuzp1996))| Steven Zou@VMware ([steven-zou](https://github.com/steven-zou)) |[8 Members](https://github.com/goharbor/community/tree/master/workgroups/wg-multiarch#members)|
+|[Multi Architecture](https://github.com/goharbor/community/tree/master/workgroups/wg-multiarch)|The purpose of this working group is to enable Harbor to support multiple architectures, such as x86 arm.|ZhiPeng Yu@Alauda ([yuzp1996](https://github.com/yuzp1996))| Steven Zou@VMware ([steven-zou](https://github.com/steven-zou)) |[13 Members](https://github.com/goharbor/community/tree/master/workgroups/wg-multiarch#members)|
 |[Performance](https://github.com/goharbor/community/tree/master/workgroups/wg-performance)|The purpose of this work group is to improve the performance and scalability of harbor in the use case of large data volumes.|ChenYu Zhang@Alauda ([chlins](https://github.com/chlins))| Steven Zou@VMware ([steven-zou](https://github.com/steven-zou))/ Daniel Morinigo@Alauda ([danielfbm](https://github.com/danielfbm)) |[11 Members](https://github.com/goharbor/community/tree/master/workgroups/wg-performance#members)|
 
 ## Structure

proposals/new/multi-arch.md

@@ -0,0 +1,177 @@
+# Proposal: `Harbor Build Supports Multiple Architectures`
+
+Author: `Zhipeng Yu / yuzp1996` and `bo zhu / Jeremy-boo`
+
+Discussion: `none`
+
+## Background
+
+At present, more and more companies need harbor to support multi-architecture construction. Some of the more mainstream ones are x86 and arm64 architectures. This proposal is to provide a solution for generating multi-architecture mirroring.
+
+## Plan
+
+When Habor releases version 2.3, support for arm64 Harbor image construction can be released at the same time
+
+Harbor version 2.3 is tentatively scheduled to be released in mid-June 2021, so we must complete the development and testing of Harbor's multi-architecture construction before the end of May.
+
+## Architecture Maturity Model
+
+In order to provider a **short-term** and **long-term** process to introduce and iterate a new architecture into Harbor ecosystem a maturity model is proposed below
+
+### Overview
+
+#### Glossary
+
+Upstream: github repository go-harbor/harbor
+
+Downstream: github repository like harbor-arm harbor-loongson and so on.
+
+Short-term: We can provide support for different architectures in different Harbor sub-projects.
+For example, in harbor-arm, we can maintain the construction logic of arm64 mirroring and other related information
+
+Long-term: Harbor-arm keeps the synchronization update with goharbor/harbor. When goharbor/harbor updates a version, harbor-arm follows the update and then pushes the mirror image to the mirror warehouse to provide users with multi-architecture support.
+
+#### Jobs For Upstream
+
+1. Increase the environment variable GOARCH, the default is amd64, which can be overridden by specifying a specific value during execution, like arm64 and so on.
+
+2. When executing make compile to generate binary files, it can generate binary files of different architectures according to the environment variable GOARCH
+
+3. Upstream version update and downstream synchronization issues.
+
+   Scheme selection:
+
+    1. Change the upstream github action workflow and add an action: After the upstream master branch merges with pr, a message is sent to notify the downstream that a build update needs to be performed.
+
+    2. The downstream actively pulls the version through timed tasks, and judges whether it needs to be built and updated by comparing with its own version (currently the downstream adopts this kind of plan to update and build).
+
+#### Jobs For Downstream
+
+1. Add a github action, responsible for building and testing related matters (in theory, it is consistent with the upstream github action process, just modify specific environment variables and dependent parameters, such as building an arm64 image through docker buildx).
+
+2. Add a file named adapter.sh, which is mainly responsible for covering the basic parameters and dependency related matters that need to build a multi-arch mirroring.
+
+3. Add a Makefile (which can be called when performing github actions) to achieve, such as overwriting adapter.sh or other functions.
+
+4. Add Dockerfile if necessary
+
+#### Risk
+Upstream modifications may affect downstream construction
+
+1. Upstream changed the Dockerfile.
+
+2. Upstream changed the build dependency package.
+
+3. There are other situations...
+
+### Dev
+
+#### Requisites
+The new architecture uses a dedicated repository to maintain all the necessary files and scripts to build Harbor in its target architecture.
+
+It should be able to build Harbor's master branch and push the resulting docker images to Harbor's org in `DockerHub` using the target architecture as suffix: `goharbor/harbor-core-arm64`
+
+#### Suggested Implementation
+
+**Repository structure:**
+
+- `Makefile`: Maintain its own list of commands to be used during the build process
+
+- `.github`: Maintain project workflow
+
+- `make`: Maintain scripts required for the project construction phase
+
+- `src`: Pull goharbor/harbor's master branch code logic, if necessary
+
+- `VERSION`: harbor-arm version number
+
+- `README.md`: harbor-arm readme
+
+- `CHANGELOG.md`: harbor-arm changelog
+
+
+**Block Item:**
+- 1. confirm harbor-arm image address.
+
+- 2. goharbor/harbor Developer guide.
+
+- 3. Harbor upgrade and pg compatibility issues.
+
+- 4. Can it be merged into the master branch in version 2.3? About goharbor/harbor increase the GOARCH parameter to support multi-architecture mirror construction pr.
+
+- 5. Harbor upgrade pg incompatibility problem.
+
+
+### Test
+
+#### Requisites
+
+It is necessary to develop an arm image test plan and an arm architecture test machine to determine whether the built harbor-arm image can run normally on the arm machine.
+
+#### Suggested Implementation
+
+We hope to be able to use the goharbor/harbor official test plan for test verification, provided that the official can provide a multi-architecture unified test plan.
+
+However, there are currently the following issues that need to be resolved
+
+1. During testing, docker-compose will be used to deploy Harbor and test, but it seems that docker-compose [only provides x86 binary files](https://github.com/docker/compose/releases), and we need to compile other versions by ourselves. We can try to install docker-compose with pip
+
+2. Images of different architectures may not be able to run using the runner provided by github action. [Self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners) should be used to ensure that images of different architectures can run tests.
+
+**Block Item:**
+- 1. Images of different architectures may not be able to run using the runner provided by github action. [Self-hosted runners](https://docs.github.com/en/actions/hosting-your-own-runners) should be used to ensure that images of different architectures can run tests.
+
+- 2. Can harbor officials provide official test solutions and support different architecture modes?
+
+- 3. arm test machine problem.
+
+
+### Alpha release
+
+#### Requisites
+
+Requires upstream goharbor/harbor to support GOARCH parameters to build harbor binary files and downstream harbor-arm to replace GOARCH parameters to build harbor-arm images and push them to Harbor's org in `DockerHub`.
+
+#### Suggested Implementation
+
+- 1. harbor-arm repo executes local build tasks regularly, pulls goharbor/harbor's master branch code, if there is an update, executes local build logic to update the image version.
+
+
+- 2. After the successful build, the harbor-arm repo will update the documents such as `changelog.md` and `readme.md`.
+
+
+
+### Beta release
+
+#### Requisites
+
+After the harbor-arm architecture image has been running stably for a period of time (for example, 2 months), the harbor-arm can consider upgrading the image to the beta version based on the modified version
+
+#### Suggested Implementation
+
+...
+
+### Ultimate goal
+
+The harbor-arm sub-project is accompanied by the iteration of the goharbor/harbor, and finally hopes to be able to support the support of harbor multi-architecture image in the goharbor/harbor project, thus discarding the harbor-arm sub-project.
+
+### Related Implementation
+
+There are already some PRs and repository that have implemented this function, we can make full use of these contents
+
+Changes provided by this [PR](https://github.com/goharbor/harbor/pull/13788) can build amd64 and arm64 image simultaneously
+
+This repository  https://github.com/querycap/harbor have created arm64 and amd64 image successfully
+
+
+## Development Iteration
+
+After several iterations, we need to ensure that the content in adapter.sh and github actions files in downstream repository is as small as possible，After each iteration, more code can be extracted and merge to upstream。
+
+After the adapter.sh and github actions files of the downstream code disappear, we can no longer maintain the downstream repository.
+
+
+## Notify Users
+
+We provide repository addresses that support other architectures in goharbor/harbor release notes. Users can directly find repository addresses of different architectures according to the link.
+

workgroups/wg-multiarch/README.md

@@ -12,12 +12,14 @@ The purpose of this working group is to enable Harbor to support multiple archit
 
 - ChenYu Zhang @Alauda ([chlins](https://github.com/chlins))
 
-- Daniel @Alauda ([danielfbm](https://github.com/danielfbm))
+- Daniel Filipe Bruehmueller Morinigo @Alauda ([danielfbm](https://github.com/danielfbm))
 
 - JingTao Cheng @Alauda ([jtcheng](https://github.com/chengjingtao))
 
 - ZhiPeng Yu @Alauda ([yuzp1996](https://github.com/yuzp1996))
 
+- Bo Zhu @Alauda ([Jeremy-boo](https://github.com/Jeremy-boo))
+
 - WenLong Zhang@Loongson ([zhangwenlong8911](https://github.com/zhangwenlong8911))
 
 - JingYun Hua@Loongson ([huajingyun01](https://github.com/huajingyun01))