-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Makefile targets for consistency #227
Conversation
Makefile
Outdated
kind-deploy: kind manifests kustomize ## Install controller and dependencies onto the kind cluster | ||
kubectl kustomize config/default > operator-controller.yaml | ||
envsubst '$$CATALOGD_VERSION,$$CERT_MGR_VERSION,$$RUKPAK_VERSION,$$MANIFEST' < scripts/install.tpl.sh | bash -s |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just curious, if we have this, then do we need deploy
target. I see that make kind-deploy
would controller and the dependencies and the latter would only install the controller, but is there a use case where we would like to support just the installation of the controller with (probably) some other version of residual dependencies running on cluster.
Also, thoughts on having the naming as kind-deploy-e2e
? Just so that it's easier to interpret the difference between the two.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could definitely see a case for separate behaviors.
make deploy
would potentially be used in environments where the other components are already installed:
make -C rukpak deploy
make -C catalogd deploy
make -c operator-controller deploy
kind-deploy
is used for both e2e
and run
targets, so I'd prefer to keep it as kind-deploy
.
TBH, I'm thinking that a number of these targets don't really need to be as exposed (via make help
) as they currently are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How much of this is theoretical? I'd very much like to limit our Makefile to having as few supported use-cases as possible, for the sake of our own sanity.
I personally use (pretty much exclusively):
make build
to build the binaries locally.make run
to rebuild/redeploy everything in a fresh kind clustermake test-unit
(or whatever we call it) to run the unit testsmake test-e2e
to run the e2e testsmake verify
to make sure I've got all the auto-generated stuff updated.
Would it be worthwhile to do a quick contributor survey to see what people actually use and then go from there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.github/workflows/deploy.yaml
Outdated
make kind-cluster | ||
make install | ||
kubectl get crds operators.operators.operatorframework.io | ||
make uninstall | ||
! kubectl get crds operators.operators.operatorframework.io | ||
make deploy | ||
kubectl get ns operator-controller-system | ||
make undeploy | ||
! kubectl get ns operator-controller-system |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These steps essentially happen during the course of running the e2e, don't they? I suppose we don't try uninstall
and undeploy
during the e2e, but maybe we could?
Makefile
Outdated
@@ -133,24 +146,26 @@ release: goreleaser ## Runs goreleaser for the operator-controller. By default, | |||
$(GORELEASER) $(GORELEASER_ARGS) | |||
|
|||
quickstart: export MANIFEST="https://github.com/operator-framework/operator-controller/releases/download/$(VERSION)/operator-controller.yaml" | |||
quickstart: kustomize generate ## Generate the installation release manifests and scripts | |||
quickstart: kustomize ### Generate the installation release manifests and scripts with dependencies |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious why we're removing generate
as a dependency. Without it, the generated operator-controller.yaml
may be out-dated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nevermind, I see generate
only generates go code. But perhaps manifests
should be a dependency of quickstart
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't comment on the line since it is unchanged, but I'd propose moving release
to extended help.
Makefile
Outdated
install: manifests kustomize generate ## Install CRDs into the K8s cluster specified in ~/.kube/config. | ||
kubectl kustomize config/default > operator-controller.yaml | ||
envsubst '$$CATALOGD_VERSION,$$CERT_MGR_VERSION,$$RUKPAK_VERSION,$$MANIFEST' < scripts/install.tpl.sh | bash -s | ||
install: manifests kustomize ### Install CRDs into the K8s cluster specified in ~/.kube/config. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are install
/uninstall
valuable to anyone? Or is everyone always going to use deploy
/undeploy
? Wondering if we can drop install
and uninstall
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
install
just does the CRDs... which aren't of much use without the controller. There are some processes that install CRDs first, then everything else... but operator-controller kinda needs to be first anyways.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are some processes that install CRDs first
Our own processes, or theoretical third party processes? If the latter, and only the latter, I'm still of the opinion that we stick with just the deploy/undeploy targets.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Third-party; it's how we tried to service-mesh at my last job.
d134286
to
1887bd6
Compare
ping? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A nit in the action but other than that the changes look reasonable to me
.github/workflows/deploy.yaml
Outdated
with: | ||
go-version-file: go.mod | ||
|
||
- name: Run basic unit tests |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
calling this a "unit" test would be confusing to me if all I saw was the name of the step and not what was actually happening
make kind-cluster | ||
make deploy | ||
kubectl get crds operators.operators.operatorframework.io | ||
kubectl get ns operator-controller-system | ||
make undeploy | ||
! kubectl get ns operator-controller-system | ||
! kubectl get crds operators.operators.operatorframework.io |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two things:
- nit: it looks like there's a mix of spaces and tabs here for indentation (unless GH UI is tricking me). Change tabs to spaces (only because that's how the rest of the file looks, not trying to start a holy war 😛 )?
- My last comment I think was eaten by a new commit, repeating here: These steps essentially happen during the course of running the e2e, don't they? I suppose we don't try uninstall and undeploy during the e2e, but maybe we could?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since removing install
/uninstall
, I put in undeploy
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are no tabs... so GH UI must be tricking you?
63df498
to
50e2a9e
Compare
Codecov Report
@@ Coverage Diff @@
## main #227 +/- ##
==========================================
+ Coverage 81.46% 81.68% +0.21%
==========================================
Files 21 21
Lines 928 928
==========================================
+ Hits 756 758 +2
+ Misses 119 118 -1
+ Partials 53 52 -1
Flags with carried forward coverage won't be shown. Click here to find out more. |
I embrace the thesis of this PR, but IMHO the difference between two-hashes and three-hashes is too subtle to avoid confusion. I believe the file separator for awk is arbitrary. Could we change to something like |
50e2a9e
to
5155964
Compare
?? |
5155964
to
56d79f9
Compare
Fixes operator-framework#226 * Rename the `install` target to `kind-deploy` * Remove `uninstall` target * Rename the `kind-cluster-cleanup` target to `kind-clean` * Remove the `generate` target from `kind-deploy` * Swap `e2e`/`test-e2e` targets * Update help descriptions * Add `help-extended`, * Change e2e workflow to use `test-e2e` Signed-off-by: Todd Short <tshort@redhat.com>
56d79f9
to
74d8148
Compare
/approve |
Description
Update Makefile targets for consistency
Fixes #226
install
target tokind-deploy
uninstall
targetkind-cluster-cleanup
target tokind-clean
generate
target fromkind-deploy
e2e
/test-e2e
targetshelp-extended
,test-e2e
Reviewer Checklist