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

Add tests for helm completion (#6115) #6120

Closed

Conversation

marckhouzam
Copy link
Member

@marckhouzam marckhouzam commented Jul 30, 2019

What this PR does / why we need it:

This commit adds a framework and tests for helm command-line
completion.

To cover different shells (bash 4, bash 3, zsh) we use docker.

For MacOS, the tests are run locally if the host is MacOS and has
the right setup (bash completion installed, or zsh installed).

Dynamic-completion (e.g., helm status <TAB>) is not yet tested, but has
been considered in the design of the framework.

To run the tests:
make test-completion

Although the framework supports marking tests as known failures,
this commit commented out the failing tests to allow for a clean
output for this proposal. They can be uncommented later on.

A new directory is added: scripts/completion-tests.
It contains the required scripts for the completion tests.

scripts/completion-tests/completionTests.sh:

  • helm-specific completion tests.
  • This script should evolve as new tests are added and new completion features implemented.

scripts/completion-tests/test-completion.sh:

  • This script repeatedly runs the completion-tests in different environments using docker.
  • This script would need changes if a new environment needs to be added.

scripts/completion-tests/lib/completionTests-base.sh:

  • The magic. It is this script that allows completion testing.
  • This script is not expected to change in day-to-day helm evolution.

closes #6115

Special notes for your reviewer:

To see a test fail, you can uncomment one of the failing tests of
scripts/completion-tests/completionTests.sh
or you can modify the expected result of one of those tests to something bogus such as
_completionTests_verifyCompletion "helm stat" "statusBAD"

Interesting example is that the test
#_completionTests_verifyCompletion ZFAIL "helm --kubeconfig=/tmp/config lis" "list"
can be seen to start working if we apply PR #5680. Should allow to review that PR with more confidence.

This commit adds a framework and tests for helm command-line
completion.

To cover different shells (bash 4, bash 3, zsh) we use docker.

For MacOS, the tests are run locally if the host is MacOS and has
the right setup (bash completion installed, or zsh installed).

Dynamic-completion (e.g., helm status <TAB>) is not yet tested, but has
been considered in the design of the framework.

To run the tests:
  make test-completion

Although the framework supports marking tests as known failures,
this commit commented out the failing tests to allow for a clean
output for this proposal.  They can be uncommented later on.

A new directory is added: scripts/completion-tests.
It contains the required scripts for the completion tests.

scripts/completion-tests/completionTests.sh:
   Helm-specific completion tests.
   This script should evolve as new tests are added and new
   completion features implemented.

scripts/completion-tests/test-completion.sh:
   This script repeatedly runs the completion-tests in different
   environments using docker.
   This script would need changes if a new environment needs to
   be added.

scripts/completion-tests/lib/completionTests-base.sh:
   The magic. It is this script that allows completion testing.
   This script is not expected to change in day-to-day helm
   evolution.

Signed-off-by: Marc Khouzam <marc.khouzam@ville.montreal.qc.ca>
@helm-bot helm-bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jul 30, 2019
@bacongobbler bacongobbler added the v3.x Issues and Pull Requests related to the major version v3 label Jul 30, 2019
Copy link
Collaborator

@mattfarina mattfarina left a comment

Choose a reason for hiding this comment

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

Thanks for the PR.

@jdolitsky recently started an acceptance testing repo. I wonder if this is the type of thing that belongs in there or here.

@@ -81,6 +81,12 @@ test-style: vendor $(GOLANGCI_LINT)
$(GOLANGCI_LINT) run
@scripts/validate-license.sh

.PHONY: test-completion
test-completion: TARGETS = linux/amd64
Copy link
Collaborator

Choose a reason for hiding this comment

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

Any chance these tests could be made to work on multiple platforms?

Copy link
Member Author

Choose a reason for hiding this comment

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

I made the assumption that the person running these tests would run docker under linux/amd64. I can try to figure out where docker is being run and choose the correct platform.

Is that what you mean?

@@ -0,0 +1,64 @@
#!bash
#
# Copyright (C) 2019 Ville de Montreal
Copy link
Collaborator

Choose a reason for hiding this comment

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

The copyright should read:

Copyright The Helm Authors.

Can you please update it throughout the PR.

Copy link
Member Author

Choose a reason for hiding this comment

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

I was hoping you'd catch this since I wasn't sure how to handle it.

IIUC the DCO is a way for me to contribute this code to the project under the licence used by the project; the DCO does not transfer the copyright ownership of the code however.

So, since I'm not a Helm Author and don't have authorization to give away the copyright, I didn't think it was ok to put the "The Helm Authors". In other projects I've seen the form <original copyright holder> and others to more appropriately reflect the copyright ownership.

Do you know of guidelines from the CNCF on this?

I don't mean to be a pain, but I also don't want to overstep what I'm allowed to do.

Copy link
Member

Choose a reason for hiding this comment

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

IIRC the CNCF wants all projects to be Apache 2 licensed. One of the reasons is because of point 5 under the terms of use, which calls this out explicitly: https://github.com/helm/helm/blob/master/LICENSE#L131-L137

If this code is copyrighted, then the CNCF team has made one recommendation before: if a contributor is providing code from another project, it should be stored in a directory that is explicitly known to come from a third party, and the licenses can be stored there under a NOTICE. Kubernetes does this with a /third-party directory in their codebase, so that may be worth looking into.

Copy link
Member Author

Choose a reason for hiding this comment

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

This contribution is made under the Apache 2 license, so it can be part of the project directly.

It's just that the Copyright ownership is not transferred by the DCO, so I thought it should be written properly who the copyright owner is, in this case Ville de Montreal. But the license remains Apache 2.

Copy link
Member Author

Choose a reason for hiding this comment

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

To complete on this discussion, I've contacted the CNCF about the copyright question and they explained that by making a contribution to the Helm project, my employer (through me) becomes a "Helm Author". Therefore, it is ok to put "Copyright The Helm Authors" as part of my contribution even though the copyright is not transferred. Sorry for me not realizing this.

@marckhouzam
Copy link
Member Author

@mattfarina Good point about the acceptance-testing repo. I hesitated after seeing the announcement about this new repo. However, I liked the fact that these tests could be run while doing development as it would allow to handle regressions of the completion logic more quickly.

When/if we move forward and get to the point of adding testing of dynamic completion, I was going to propose to avoid using a real kubernetes cluster and instead use a fake store as is done with the go tests. So the completion tests could still be run easily by the developer.

I'm just voicing my opinion but of course it is your call.

@jdolitsky
Copy link
Contributor

@marckhouzam originally I had PR'd the acceptance tests to helm/helm under the same premise that I would like to run them during development. However, it is easy enough to just run a "make build" and set PATH appropriately prior to running the acceptance test suite.

On that basis, I'd be in favor of moving this stuff over to helm/acceptance-testing, under some new file completion.robot. Let me know if you want to chat about this.

Criteria for what to put in acceptance test repo should probably be "does a fully-built version of Helm work in its target environment(s)?" (different Kubernetes clusters, different shells, etc.)

@marckhouzam
Copy link
Member Author

@jdolitsky Thanks for the context. I'll have a deeper look at the acceptance-testing repo to see how things could work there. I'll post back once I make progress or if I have questions :-)

@marckhouzam
Copy link
Member Author

I'm closing this PR as it was moved to the acceptance-testing repo:
helm/acceptance-testing#12

The question of Copyright is still under discussion.

@marckhouzam marckhouzam deleted the feat-v3/addtestcompletion branch September 3, 2019 14:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size/L Denotes a PR that changes 100-499 lines, ignoring generated files. v3.x Issues and Pull Requests related to the major version v3
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants