weiguoqiang/cert-manager
1
0
Fork 0
Code Issues Pull Requests Actions 2 Packages Projects Releases Wiki Activity

fix double indented dashes for github markdown

Browse Source 
Signed-off-by: Ashley Davis <ashley.davis@jetstack.io>
This commit is contained in:
Ashley Davis 2023-05-26 11:55:42 +01:00
parent 07cd2e3782
commit cc89050c02
No known key found for this signature in database
GPG Key ID: DD14CC017E32BEB1
1 changed files with 19 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
design/20230302.gomod.md
View File

@ -18,39 +18,39 @@ The intention here is to describe what we did and what we discovered, with an ey
- Create a go module for each binary
- Create go modules for integration and e2e tests
- Utilise local replace statements where possible
- - i.e. Binaries have a local replace for the core cert-manager module
- - This breaks imports of those binaries but means changes only require one PR
- i.e. Binaries have a local replace for the core cert-manager module
- This breaks imports of those binaries but means changes only require one PR
### Pros
- Each binary can be patched independently
- - Side effects of a patch are limited to one binary when only that binary has the dependency
- - This includes forking a dependency or needing to `replace` one
- - Gives us more control over our own destiny
- Side effects of a patch are limited to one binary when only that binary has the dependency
- This includes forking a dependency or needing to `replace` one
- Gives us more control over our own destiny
- Core go.mod dependencies are reduced
- - All importers of `github.com/cert-manager/cert-manager` have fewer transitive dependencies
- - Reduced chance of dependency conflicts for all importers
- - Including us - in subprojects!
- - Many people need to import cert-manager! (pkg/apis, etc).
- - We might split things more in the future - this is a good first step
- All importers of `github.com/cert-manager/cert-manager` have fewer transitive dependencies
- Reduced chance of dependency conflicts for all importers
- Including us - in subprojects!
- Many people need to import cert-manager! (pkg/apis, etc).
- We might split things more in the future - this is a good first step
- Lays the groundwork for further splitting out binaries / packages
- - This is the start of what we'll do if we want cmctl to be its own repo
- - Or splitting `pkg/apis` into a separate module
- - Or splitting issuers into a module (to isolate cloud SDK dependencies)
- This is the start of what we'll do if we want cmctl to be its own repo
- Or splitting `pkg/apis` into a separate module
- Or splitting issuers into a module (to isolate cloud SDK dependencies)
### Cons
- Using local `replace` statements for binaries will break imports for those binaries
- - We assume this won't be too destructive in most cases
- - If we need to make binaries importable again, we can change them to use regular import statements
- - That would require two PRs in the event that we need to change the binary + the core module at the same time
- - If the binary would've ended up in a separate repo anyway (e.g. cmctl) we'd have done this eventually
- We assume this won't be too destructive in most cases
- If we need to make binaries importable again, we can change them to use regular import statements
- That would require two PRs in the event that we need to change the binary + the core module at the same time
- If the binary would've ended up in a separate repo anyway (e.g. cmctl) we'd have done this eventually
- Increased complexity in working with the codebase
- - E.g. `go test ./...` no longer tests _everything_, since it won't recurse into modules
- - This can be alleviated with some Makefile work - `make test` can still test everything
- E.g. `go test ./...` no longer tests _everything_, since it won't recurse into modules
- This can be alleviated with some Makefile work - `make test` can still test everything
## Longer Form Problem Statement