unkin-agent
9da206dc7c
PVCs and CloudNativePG Clusters need S3 buckets and backup schedules
provisioned consistently. This operator watches the
backups.unkin.net/{schedule,destination} annotations on those objects and
provisions everything needed to back them up, with no new CRDs.
- Add a PVC controller that provisions cephrgw ObjectStoreUser/Bucket/BucketAccess,
auto-generates a restic repo-password Secret and creates a k8up Schedule scoped
to the PVC via spec.backup.volumes[].persistentVolumeClaim.claimName.
- Add a CNPG Cluster controller that provisions the same bucket stack, idempotently
patches spec.backup.barmanObjectStore (leaving a user-set destinationPath alone
with a Warning event) and creates a ScheduledBackup.
- Resolve destinations through a ConfigMap lookup table; requeue until the
BucketAccess is Ready before creating schedule resources; own-reference created
resources and retain bucket data by default.
- Add schedule-mapping helpers (k8up 5-field/shortcut pass-through, CNPG 6-field
seconds-first) and deterministic, length-bounded name derivation.
- Add unit tests (schedule mapping, name derivation, destination resolution) and
envtest controller tests for both paths, wiring the external CRDs into envtest.
- Add kubebuilder-generated RBAC, a Dockerfile (distroless/nonroot), Woodpecker
lint/test/build pipelines and a tag-triggered image push to the artifactapi
docker-internal registry, plus a version-bump Makefile and deploy manifests.
71 lines
2.1 KiB
Markdown
71 lines
2.1 KiB
Markdown
# Contributing
|
|
|
|
We'd love your help making zap the very best structured logging library in Go!
|
|
|
|
If you'd like to add new exported APIs, please [open an issue][open-issue]
|
|
describing your proposal — discussing API changes ahead of time makes
|
|
pull request review much smoother. In your issue, pull request, and any other
|
|
communications, please remember to treat your fellow contributors with
|
|
respect! We take our [code of conduct](CODE_OF_CONDUCT.md) seriously.
|
|
|
|
Note that you'll need to sign [Uber's Contributor License Agreement][cla]
|
|
before we can accept any of your contributions. If necessary, a bot will remind
|
|
you to accept the CLA when you open your pull request.
|
|
|
|
## Setup
|
|
|
|
[Fork][fork], then clone the repository:
|
|
|
|
```bash
|
|
mkdir -p $GOPATH/src/go.uber.org
|
|
cd $GOPATH/src/go.uber.org
|
|
git clone git@github.com:your_github_username/zap.git
|
|
cd zap
|
|
git remote add upstream https://github.com/uber-go/zap.git
|
|
git fetch upstream
|
|
```
|
|
|
|
Make sure that the tests and the linters pass:
|
|
|
|
```bash
|
|
make test
|
|
make lint
|
|
```
|
|
|
|
## Making Changes
|
|
|
|
Start by creating a new branch for your changes:
|
|
|
|
```bash
|
|
cd $GOPATH/src/go.uber.org/zap
|
|
git checkout master
|
|
git fetch upstream
|
|
git rebase upstream/master
|
|
git checkout -b cool_new_feature
|
|
```
|
|
|
|
Make your changes, then ensure that `make lint` and `make test` still pass. If
|
|
you're satisfied with your changes, push them to your fork.
|
|
|
|
```bash
|
|
git push origin cool_new_feature
|
|
```
|
|
|
|
Then use the GitHub UI to open a pull request.
|
|
|
|
At this point, you're waiting on us to review your changes. We _try_ to respond
|
|
to issues and pull requests within a few business days, and we may suggest some
|
|
improvements or alternatives. Once your changes are approved, one of the
|
|
project maintainers will merge them.
|
|
|
|
We're much more likely to approve your changes if you:
|
|
|
|
- Add tests for new functionality.
|
|
- Write a [good commit message][commit-message].
|
|
- Maintain backward compatibility.
|
|
|
|
[fork]: https://github.com/uber-go/zap/fork
|
|
[open-issue]: https://github.com/uber-go/zap/issues/new
|
|
[cla]: https://cla-assistant.io/uber-go/zap
|
|
[commit-message]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
|