Skip to content

Conversation

JJediny
Copy link
Member

@JJediny JJediny commented Aug 1, 2017

No description provided.

@JJediny JJediny requested a review from afeld August 1, 2017 19:43
@JJediny
Copy link
Member Author

JJediny commented Aug 1, 2017

TP7lAoGAY/IHN42AVG1wjrvmLjs3W2DyvYEr3odzLhfQhWQB89Yqpni59N9iceMn
DQhxeuXzXIuAnjmHMsWC0FUzBcu+9ZgHIIqZFhTsC0zo6PS9gbgs+jKEG3U0j5hq
pwR7fKFYqY4er3ZILQDzG01cmwndAoU5Fj/Z4e816b8vxtEPa5w=
-----END RSA PRIVATE KEY-----
Copy link
Contributor

Choose a reason for hiding this comment

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

What is this for? Does it need to be checked in to the repository?

Copy link
Member Author

Choose a reason for hiding this comment

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

doesn't kitchen coins a dummy private/pub ssh key on each run.. this is a bad missed gitignore thing

Copy link
Member Author

Choose a reason for hiding this comment

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

E, [2017-08-01T15:34:05.159095 #1448] ERROR -- Kitchen: /home/john/.rvm/gems/ruby-2.4.0/gems/test-kitchen-1.16.0/lib/kitchen/command.rb:197:in `public_send'
E, [2017-08-01T15:34:05.159120 #1448] ERROR -- Kitchen: /home/john/.rvm/gems/ruby-2.4.0/gems/test-kitchen-1.16.0/lib/kitchen/command.rb:197:in `run_action_in_thread'
E, [2017-08-01T15:34:05.159144 #1448] ERROR -- Kitchen: /home/john/.rvm/gems/ruby-2.4.0/gems/test-kitchen-1.16.0/lib/kitchen/command.rb:169:in `block (2 levels) in run_action'
E, [2017-08-01T15:34:05.159169 #1448] ERROR -- Kitchen: ----End Backtrace-----
Copy link
Contributor

@afeld afeld Aug 2, 2017

Choose a reason for hiding this comment

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

This and the other log files should be ignored from Git.

Copy link
Member Author

Choose a reason for hiding this comment

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

username: kitchen
ssh_key: "/home/john/ansible-https-proxy/.kitchen/docker_id_rsa"
image_id: 76fac104ae78
container_id: 07a32b35818e885f895f1be28b497b66cccccafabc8e7f0b18f079280e126859
Copy link
Contributor

Choose a reason for hiding this comment

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

What are these?

@@ -0,0 +1,9 @@
---
username: kitchen
ssh_key: "/home/john/ansible-https-proxy/.kitchen/docker_id_rsa"
Copy link
Contributor

Choose a reason for hiding this comment

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

Is an SSH key needed at all if using the Docker backend?

fail:
when: http_req.location != 'https://localhost/'

# TODO Check that nginx is listening on port 443. Not the responsibility of this role to check for a response from the proxied service.
Copy link
Contributor

Choose a reason for hiding this comment

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

This is still an outstanding TODO. Should we make an issue instead?

@afeld
Copy link
Contributor

afeld commented Aug 2, 2017

ERROR! the role 'gsa.https-proxy' was not found in /tmp/kitchen/roles:/tmp/kitchen/roles:/tmp/kitchen
       
       The error appears to have been in '/tmp/kitchen/test.yml': line 8, column 7, but may
       be elsewhere in the file depending on the exact syntax problem.
       
       The offending line appears to be:
       
         roles:
           - gsa.https-proxy
             ^ here

Yeeeeah, this is annoying problem. Ansible is looking for a role by that name in its "roles path", but since the repository is cloned (by default) into a folder named ansible-https-proxy, the playbook thinks the role is missing. Two options are:

  • Change the role reference in the playbook to ansible-https-proxy
  • Change the role's directory name to be gsa.https-proxy

While the Test Kitchen setup seems nice for testing across different operating systems, I worry that it

  • Adds another dependency (Ruby), making setup (especially locally) harder
  • Requires a bunch of boilerplate
  • Is more opaque than executing Docker directly, which could make troubleshooting harder

I have been doing (simple) integration/acceptance/smoke testing as tasks within roles, and have been really happy with that approach. This keeps all the testing in Ansible, and runs those tests in the context of applying the role, which

  • Execute any time you execute the role, whether in testing or production
  • Can short-circuit the role right after the corresponding change is applied, if the corresponding test fails

Not saying we shouldn't use Test Kitchen...just that there are tradeoffs.

docker:
- image: docker
test-centos-7:
working_directory: ~/ansible-https-proxy
Copy link
Contributor

Choose a reason for hiding this comment

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

Changing this back might fix the build error.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants