Skip to content
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

Merged
merged 1 commit into from
Sep 1, 2023

Conversation

tmshort
Copy link
Contributor

@tmshort tmshort commented May 22, 2023

Description

Update Makefile targets for consistency

Fixes #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

Reviewer Checklist

  • API Go Documentation
  • Tests: Unit Tests (and E2E Tests, if appropriate)
  • Comprehensive Commit Messages
  • Links to related GitHub Issue(s)

Makefile Outdated
Comment on lines 95 to 138
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
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

@joelanford joelanford May 26, 2023

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 cluster
  • make test-unit (or whatever we call it) to run the unit tests
  • make test-e2e to run the e2e tests
  • make 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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines 23 to 28
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
Copy link
Member

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
Copy link
Member

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.

Copy link
Member

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?

Copy link
Member

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.
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

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.

@tmshort tmshort force-pushed the update-makefile branch 2 times, most recently from d134286 to 1887bd6 Compare June 1, 2023 14:43
@tmshort
Copy link
Contributor Author

tmshort commented Jun 1, 2023

ping?

Copy link
Contributor

@everettraven everettraven left a 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

with:
go-version-file: go.mod

- name: Run basic unit tests
Copy link
Contributor

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

Comment on lines +23 to +29
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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two things:

  1. 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 😛 )?
  2. 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?

Copy link
Contributor Author

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

Copy link
Contributor Author

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?

@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Jun 8, 2023
@tmshort tmshort requested a review from a team as a code owner August 10, 2023 16:03
@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Aug 10, 2023
@codecov
Copy link

codecov bot commented Aug 10, 2023

Codecov Report

Merging #227 (74d8148) into main (2114da6) will increase coverage by 0.21%.
The diff coverage is n/a.

@@            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     
Flag Coverage Δ
e2e 62.28% <ø> (+0.21%) ⬆️
unit 77.22% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

see 1 file with indirect coverage changes

@grokspawn
Copy link
Contributor

grokspawn commented Aug 16, 2023

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 #extended or something which more intuitively indicates the distinction from ##?

@tmshort
Copy link
Contributor Author

tmshort commented Aug 16, 2023

I believe the file separator for awk is arbitrary. Could we change to something like #extended or something which more intuitively indicates the distinction from ##?

#HELP
#EXHELP
#SECTION

??

@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Aug 24, 2023
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>
@openshift-merge-robot openshift-merge-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Aug 25, 2023
@grokspawn
Copy link
Contributor

/approve
/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Aug 25, 2023
@tmshort tmshort added this pull request to the merge queue Sep 1, 2023
Merged via the queue into operator-framework:main with commit 87d2087 Sep 1, 2023
11 checks passed
@tmshort tmshort deleted the update-makefile branch September 5, 2023 17:32
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Makefile inconsistencies
6 participants