Community: Testing Working Group Meeting Agenda

[gundalow]

Moved to new agenda, please see https://github.com/ansible/community/issues/248

.

[alikins]

~https://github.com/ansible/ansible/issues/16864 - Add test apt,ppa,yum repos to httptester images for integration tests~

[gundalow]

Hi, I'd like to propose https://duckduckgo.com/?q=1800+UTC&ia=answer Starting Thursday 18th August for the weekly meeting. We need to cater for East Coast & Europe, I hope that works for most people.

~~+1/-1 welcome :)~

[srgvg]

:+1: svg on irc

[rcarrillocruz]

~works great for me.~

[pabelanger]

+1

[supertom]

+1

[gundalow]

Hi,

Due to other conflicts I need to move this one hour earlier so it will now be

https://duckduckgo.com/?q=1700+UTC
Hope most can still make that

Starting Thursday 18th August for the weekly meeting

[dagwieers]

+1

[robinro]

~PR by @cinerama70 to review/merge. Test for ansible_os_family and a related bugfix:
https://github.com/ansible/ansible/pull/17620 and https://github.com/ansible/ansible/pull/17575~

~In general the test coverage of basic facts could use some more attention.~

~PRs merged.~

[mscherer]

~Sorry I merged https://github.com/ansible/ansible/pull/17620 before realizing you wanted to have it discussed in the meeting. In exchange of me removing a easy discussion during the meeting, I offer https://github.com/ansible/ansible/pull/17628~

[robinro]

~Thanks @mscherer for the merge. I didn't really want to discuss it but only draw some attention to get it merged and maybe get more tests for the facts code.~

[relaxdiego]

~I'd like to submit my article on Writing Ansible Modules Complete With Tests for feedback by this group. I'll be speaking in AnsibleFest Brooklyn using this content and would like to make sure it aligns with community practices. Feedback will be collated in the next meeting.~

~The article is at https://www.relaxdiego.com/2016/06/writing-ansible-modules-with-tests.html~

~IRC nick: mmaglana~

[caphrim007]

~- I think @gundalow asked how I do coverage testing of the f5-ansible modules. I do it using playbooks. I can talk more about it at the next meeting~

~This is how I do it
https://github.com/F5Networks/f5-ansible/commit/88fb0a423f80955575c5e3945b005a6a067cbc7e~

[relaxdiego]

~Submitting version 2.0.0 of the article for review in the next meeting. Changes are:~

• ~Simplify main() and move business logic to separate function~
• ~Take advantage of lessons from Boundaries talk by Gary Bernhardt~
• ~Reference module checklist~
• ~Give credit where credit is due :-)~
• ~Other minor fixes~

~URL is still https://www.relaxdiego.com/2016/06/writing-ansible-modules-with-tests.html~

[gundalow]

Do we want a test_pull_requests label so we can identify (and therefore fast track) PRs that improve testing? Would people find this useful and help review changes?

~Agreed: 4 people said they would find it useful having a test_pull_requests label.~

[gundalow]

For discussion on Thursday 20th October

Prep for repo merge

• Integration tests moving -
  
  
  
  • https://github.com/ansible/ansible/tree/devel/test/integration/targets
  
  
  • Dropping of test_ prefix
  
  
• ansible-validate-modules is now https://github.com/ansible/ansible/tree/devel/test/sanity/validate-modules

httptester
After seeing the discussion during Contributor Summit regarding making httptester available in non-docker forms Sivel has raised:
https://github.com/ansible/ansible/pull/18107

[gundalow]

~ACTION: gundalow to find all old references to ansible-validate-modules in google and get them updates~

[gundalow]

~No Testing Working Group meeting today (27th October).~

[gundalow]

~No Testing Working Group meeting today (3rd November), instead there is a meeting about the repo merge, all welcome.~

[frenzymadness]

Hi.

I really want to help with Python 3 compatibility for Ansible. I think that good point to start and learn more about Ansible is helping with tests coverage.

I want to ask (here or on the meeting) if there is any roadmap for improving tests coverage of Ansible.

[gundalow]

~@frenzymadness Thanks for the offer of help, please join us in today's meeting~

[mattclay]

https://github.com/ansible/ansible/pull/15470 Specifically, how do people feel about having more yamllint rules enforced for tests?

Merged

[gundalow]

Add a check for type() instead of isinstance()
https://github.com/ansible/ansible/pull/18439
Merged

[gundalow]

~More details about upcoming repo merge
Important to review for those looking to contribute to module development https://groups.google.com/forum/#!topic/ansible-project/9WpXraBSLz8~

[gundalow]

~No IRC meetings this week. Next Testing Working Group meeting will Thursday 15th December.~

[gundalow]

~No IRC meetings next week. Next meeting is on Thursday 5th Jan.~

[dagwieers]

New item for next meeting. Lowering the bar for integration tests by removing silly checks.

See: https://github.com/ansible/ansible/pull/20539#pullrequestreview-19247821

Doing another:

• wait for Shippable (about an hour)
• check results
• find some silly yamllint requirement (no blank lines at the end of a yaml file)
• change branch again
• hunt it down
• commit
• push

This is not really encouraging more integration tests and not valuable time spent on Ansible. I'd say lower the bar and remove silly requirements like this. Tests need to be functional, correct and complete, not comply to arcane cosmetic requirements and waste my time.

[Edit] This was skipped for the February 2nd meeting due to low attendance. We can pick it up at the next meeting on February 9th when everyone is back from Ansible Automates Paris.

[Edit] This was discussed on the February 9th meeting, although dag was not present, so we may not have adequately covered the topic.

[alikins]

https://github.com/ansible/ansible/pull/20944

I'd like to see ansible-test ignore files not in git by default.

Upcoming improvements to ansible-test implement this.

[gundalow]

~Ansible Core 2.1.5RC1 and 2.2.2RC1 are available for testing
https://groups.google.com/forum/#!topic/ansible-devel/VnHIVtzuyzs~

[alikins]

I'd like to see 'ansible-test sanity' run all test and then report all failures instead of exiting on first failure.
No pr yet, but if that is reasonable I can implement it.

2 Mar: Upcoming improvements to ansible-test implement this.

[alikins]

I have a branch that adds a '--lint' option to 'ansible-test sanity' that just displays pep8 results in a format closer to standard pep8.

The intention is to make it easy to use 'ansible-test sanity' output with tools like the 'syntastic' vim plugin.

If there is interest, I can start adding that to other sanity tests as well. Maybe example syntastic setup as well.

Upcoming improvements to ansible-test implement this.

[dagwieers]

I still think we need to make a careful selection of what we think is essential in PEP8, and the stuff that we can leave up to those who care to spend their free time doing. So distinction between mandatory and optional. (Like the trailing newline is, blank lines, the commented lines, ...)

We are now not enforcing everything in PEP8 either because some of it is debatable (or just not important or flat out annoying :-)).

(Apparently I missed that meeting...)

[sivel]

@dagwieers that is an incorrect assessment of our stance on coding style. All new files must adhere to full pep8 with the exception of E402 and 160 char max line length. It is a goal to get all files there, but due to older files being so far out of "compliance" with our new coding style guidelines, they are being ignored to some level while we work through them.

The agree upon coding style as well as implementation details can be found at https://github.com/ansible/proposals/issues/50

Effectively, we have decided that all but E402 (and a max line length of 160 characters) are essential, and we have no plans on excluding anything else. As such, they will all be mandatory.

[dagwieers]

@sivel I wasn't making an assessment of our stance on coding style. I was proposing we don't implement everything. Since you already have 2 exceptions (so it isn't full PEP8 to begin with), you could opt to have 4 or 5 exceptions instead.

• Insisting a blank line at the end of a file means people have to modify their editors for this project. Trailing newlines are usually removed, not added. (Even Jinja2 removes them by default, without asking)
• Requiring '#' to be indented with the code makes sense for inline comments, but does not make sense for commented code (code that is commented because it has been disabled on purpose). If one cannot make the distinction between commented examples and disabled code, that does not increase readability, quite the contrary.

These things shouldn't matter and have nothing to do with code readability. I don't know who thinks having a trailing newline is useful or a sensible thing to do. I don't mind if that person adds trailing lines where they see fit, but don't bother the rest of the community with pedantic rules like this.

And people are allowed to change their minds (even after something has been decided). Sometimes that is called experience or even intelligence ;-) You seem to leave no room for objection or change of mind in your reply.

[sivel]

~There isn't. It's been agreed upon, and implementation is in progress.~

[dagwieers]

~What isn't there ?~

[allanice001]

Woudn't a basic .editorconfig file at project root help ?

# -*- mode: conf-unix; -*-

# defaults
[*]
insert_final_newline = true

# 4 space indentation
[*.{ini,py,py.tpl,rst}]
indent_style = space
indent_size = 4

# and travis does its own thing
[.travis.yml]
indent_style = space
indent_size = 2

[dagwieers]

That we are even discussing this, and @mattclay is copy&pasting these errors in GitHub comments and people have to go back and fix this is so absurd. Nobody ever considered the gains vs the pains ? Contributor frustration for things one cannot simply explain ?

I am not questioning PEP8 in general, a lot of rules do make sense (and because of that, people are willing to put effort in). But I contest this is an all-or-nothing decision. Only @bcoca made sensible remarks wrt. these rules IMO.

Fact is that few new contributors will come and tell you this, they will simply not bother. There are a lot more important things we _do_ want people to know and do wrt. modules and code, and believe me, trailing newlines and other silly requirements are just big distractors to what truly matters. But I guess since you can automate this, and not the rest it's fine to bother everybody else with it.

So I got that out of my system. Good night !

[mattclay]

Just to address a few specific points from earlier comments:

Insisting a blank line at the end of a file

There are two related PEP 8 guidelines being enforced:

W292 no newline at end of file
W391 blank line at end of file

The newline at the end of file is a line terminator rather than a line separator. To be considered a blank line, there must be 2+ consecutive newlines at the end of the file.

Enforcing W292 leads to a cleaner diff for future changes that add to the end of the file.

Requiring '#' to be indented with the code makes sense for inline comments, but does not make sense for commented code

The relevant PEP 8 test is:

E115 expected an indented block (comment)

Generally, commented out code should be avoided. For the rare case where it is desirable, the potential drop in readability for that code should be outweighed by the improved readability of properly indented non-code comments, which occur at a much higher frequency.

people have to go back and fix

Adding more tests to CI will inevitibly lead to more CI failures. That's why making tests easier and faster when running locally is important. To help deal with this, I'm working on improving messaging for various CI failures. When possible, I'd like CI failures to explain not only the failure, but how to run the test locally.

[mikedlr]

~regarding pep8; could ansibot, for example, run autopep8 on new commits and then do a fix commit before sending new PRs off to shippable for testing? Since most of the rules are being enforced by flake8 so the commits won't be accepted otherwise, this could only reduce pain for committers.~

~A script that was easy to set up on local git repos to run flake8 / some simple test from a hook before a git commit would also help more regular committers.~

[jctanner]

~ansibot is not a code linter nor a CI framework nor a commit hook. Almost all of the tests that run in shippable can be run locally.~

[pabelanger]

~FWIW: by using tox (https://tox.readthedocs.io/en/latest/) as the entry point for locally testing, it is very easy to add a pep8 / flake8 envlist to your tox.ini[1]. Then you get to bikeshed on which things to ignore[2]~

~[1] https://github.com/openstack-dev/cookiecutter/blob/master/%7B%7Bcookiecutter.repo_name%7D%7D/tox.ini#L15
[2] https://github.com/openstack-dev/cookiecutter/blob/master/%7B%7Bcookiecutter.repo_name%7D%7D/tox.ini#L38~

~Info. Nothing to discuss.~

[mikedlr]

~I'd like to propose activating cloud integration tests in continuous integration. Last weekend I cleaned enough of them up that they run more or less cleanly for me locally (see #22499). There were many problems showing that most of the tests were not in a runnable state. With some more work they could be made to be reasonably stable. If they ran on checkins to devel at least then it would be much more likely that they would be maintained in future. I'll try to be in thursday's (14th March) testing meeting but if I fail to make it I will read the log anyway.~

~Discussed at the March 16th meeting: @mattclay has added to the proposed 2.4 roadmap running of existing cloud integration tests (AWS, Azure, GCE).~

[dagwieers]

~I'd like to discuss a structured way to reuse tests for both normal mode and check-mode testing, and also discuss the use of YAML anchors and references for doing idempotency testing. Since I would like to redo all the Windows integration tests (some are simply missing) I would like to get approval on the preferred mechanism.~

~See this example : https://github.com/ansible/ansible/pull/22611/files#diff-9bdd58936ad3aaccf0f2daa7c4a385e1R1~

~Discussed at the March 16th meeting: @dagwieers to try a second approach which keeps the assert statements inline and make them conditional with when. This would keep the assertions close to the tasks being checked while still allowing different assertions for normal and check mode.~

~Mentioned at the March 23rd meeting. However, dagwieers was not present.~

~This was implement in: ansible/ansible#22833~

[gundalow]

~Ansible 2.3 RC1 has been released for testing
Please see https://groups.google.com/forum/#!topic/ansible-devel/V2ESSQqLnS0 for details
As you may know there have been many changes to the networking code between 2.2 and 2.3.
We would appreciate your help testing.
Any issues, please raise at https://github.com/ansible/ansible/issues/new
Thanks!~

~Mentioned at the March 16th meeting.~

[gundalow]

~When do we want to remove Ubuntu 12.4 LTS testing which goes EOL in April~

~From the March 16th meeting: @thaumos is checking with "the business" before we continue the discussion. We'll revisit at our next meeting.~

~From the March 23rd meeting: mattclay to remove ubuntu1204 testing from Shippable~

~Done.~

[mattclay]

~Tests for python 2.4 have been removed from devel. Caution is required when making fixes which must be back ported to stable branches, since they still have the python 2.4 requirement.~

~Mentioned at March 16th meeting.~

[Shaps]

~Is it best to have https://github.com/ansible/ansible/issues/18181 as code-smell tests or in validate-modules?~

~Discussed at March 16th meeting. Suggestion is to use validate-modules for this test.~

[mscherer]

~Ubuntu 12.04 will have a Extended LTS it seems ( https://insights.ubuntu.com/2017/03/14/introducing-ubuntu-12-04-esm-extended-security-maintenance/ ). Not sure on the impact of testing, but I guess we can do like RHEL 5 and drop it ?~

~Mentioned at March 16th meeting.~

[mattclay]

~Use flake8 instead of pep8: https://github.com/ansible/ansible/pull/22820~

~Discussed at March 23rd meeting. PR updated with feedback.~

[sivel]

~pep8 current to legacy:~

~https://github.com/ansible/ansible/pull/22891
https://github.com/ansible/ansible/pull/22911~

~Discussed at March 23rd meeting. PRs merged.~

[Shaps]

~still some discussion about: https://github.com/ansible/ansible/pull/22744~

~Discussed at March 23rd meeting. Shaps to update module validator to use a whitelist to exclude modules from the test as needed.~

[gundalow]

Discussion: How to deal with PRs that fail CI after merge

Consider the case:
PR created
Reviews/updates
Still passes CI
Time Passes
CI is made stricter (e.g. pep8 or validate-modules)
PR merged (as it's green)
Merge now fails updated tests

Seen this twice today

Do we need to do rolling reruns CI on status:success?

Discussed at March 30th meeting. There isn't much we can do with GitHub to prevent this entirely. However, we do have plans to make changes which will help minimize this.

[gundalow]

Ansible 2.3 RC3 has been released https://groups.google.com/forum/#!topic/ansible-devel/X8sYLl-ZuTY

We welcome your feedback, after all, we can only fix what we know is broken. If you spot any issues please raise via https://github.com/ansible/ansible/issues/new

Thanks again for your help

[resmo]

• ~Automated CloudStack testing (https://github.com/ansible/ansible/pull/20552)~
  
  
  
  • ~State of integration into ansible-test?~
  
  
  • ~Who doing what, how can I help?~
  
  

Discussed at April 13th meeting. Adding support for this is on mattclay's TODO list.

[gundalow]

~Ansible 2.3.0 FINAL has been released. Thank you for all your help with this release
https://groups.google.com/forum/#!topic/ansible-project/aKnggI-Y8dk~

[mattclay]

~If anyone is interested in joining the Contributors Summit (in person or remote), ping @gundalow directly.~

[gundalow]

NO MEETING: Thursday 20th April

NEXT MEETING: Thursday 27th April

[gundalow]

Ansible 2.2.3 FINAL released, 2.1.6rc1 and 2.3.1rc1 available for testing

All of these releases address at least one CVE (listed below). Users of 2.2.x should upgrade to 2.2.3 as soon as possible. The CVE impacting 2.1.x and 2.3.0 is MODERATE in nature, however users should look to upgrade as soon as the final releases are done.
https://groups.google.com/forum/#!topic/ansible-devel/etlpnJDerY0

[gundalow]

Ansible Contributor Summit 4 (Part of AnsibleFest 2017 London)

We are happy to announce our fourth Ansible Contributors Summit!
AnsibleFest London (http://www.ansible.com/ansiblefest) will be on Thursday 22nd June, and the Contributor Summit will be held on Wednesday 21st June, from 9:30am to 4pm (time subject to change).

Contributors Summit is a day-long working session with the core team and key contributors to discuss important issues affecting the Ansible community. You can participate in person or online

Proposed topics: https://public.etherpad-mozilla.org/p/ansible-summit-june-2017

See https://groups.google.com/forum/#!topic/ansible-devel/stUITiM6hMs for more info

[gundalow]

Ansible Contributor Summit 4 (Part of AnsibleFest 2017 London)

Agenda for Contributor Summit has finalised can be found at https://public.etherpad-mozilla.org/p/ansible-summit-june-2017-agenda.

As a reminder, it will be in #ansible-meeting and BlueJeans

Note that there are sub pages for each topic. It's on the sub pages where you can add any topics there, rather than on the main agenda page.

[gundalow]

Due to Contributors Summit & AnsibleFest

NO MEETING: Thursday 22th June

NEXT MEETING: Thursday 29th June

[dagwieers]

Please discuss during your next meeting what information can be added to:
https://github.com/ansible/community/tree/master/group-testing

And if there's any collaboration information you want to share on the wiki:
https://github.com/ansible/community/wiki

[gundalow]

~Test dependencies~
~test/runner/requirements/integration.txt is growing and contains packages needed only for specific tests, rather than what's needed to just run ansible-test~

~Matt Clay has proposed that we put requirements in test/integration/targets/*/requirements.txt~

~Should this logic also be extended to unit tests?~
~Do we need to require and document that all unit tests gracefully fail if the required dependencies are not installed?~
~Though perhaps for Shippable runs we need to make it a fatal error~

~Related TOX~
~* Make TOX work out of the box https://github.com/ansible/ansible/pull/25915~
~* Add pytest-xdist to requirements.txt https://github.com/ansible/ansible/pull/25962~
~* How can we direct people that want to use tox to use ansible-test~

@Shaps Has volunteered to work on moving test-specific requirements out of test/runner/requirements/integration.txt into their respective test targets. Integration tests are responsible for installing their own dependencies at the start of the test (aside from those common to ansible or the test infrastructure). Additional requirements installation capabilities will not be added to ansible-test at this time.

[gundalow]

~Cleaning up test/~

• ~test_win_group*.yml Do we still need these files, if not can we delete them?~
• ~test/integration/Makefile Should this be deleted?~

The legacy files have been deleted.

[gundalow]

Document codee Coverage https://codecov.io/gh/ansible/ansible/

[pilou-]

~About~

~test_win_group*.yml Do we still need these files, if not can we delete them?~

~mattclay wrote:~

~The Makefile is the legacy method of invoking tests that predates ansible-test. Instead of updating the Windows related targets in the Makefile (and renaming their associated playbooks), they should be removed.~

~and:~

~The test_win_group*.yml files should be removed as well, as they're only used by the windows targets in the Makefile.~

The legacy files have been deleted.

[dagwieers]

For testing the win_uri module (and eventually the uri module as well) we would like to look at using httptester. This was deemed the preferred way during some discussion (don't have a reference at hand).

For Windows that would mean that the VMs need to be able to connect the the httptester docker network. As a result, we will leave the idea to set up our own http listener process (https://github.com/ansible/community/issues/153#issuecomment-307416056).

[dagwieers]

~For the new xml module, we need lxml provisioned. For the docker images, this is already the case, but for the VMs (FreeBSD, MacOSX) lxml is still missing.~

https://github.com/ansible/ansible/pull/25323#issuecomment-312105554

[gundalow]

https://meetbot.fedoraproject.org/ansible-meeting/2017-06-29/testing_working_group.2017-06-29-17.00.html
https://meetbot.fedoraproject.org/ansible-meeting/2017-06-29/testing_working_group.2017-06-29-17.00.log.html

[gundalow]

~test_pull_requests label.~
~If we want to use this label to find PRs with tests should we stop test/sanity/pep8/*.txt from getting that label?~

Action Item: If test/sanity/pep8/legacy-files.txt is the only test/ file modified by a PR, the bot should not apply the test_pull_requests label. This will avoid adding the test_pull_requests label when a PR only cleans up legacy PEP 8 issues without making any other test related changes.

See: https://github.com/ansible/ansibullbot/issues/629

[willthames]

~@gundalow maybe just exclude test/sanity completely if you want to find PRs that are testing themselves rather than testing everything, if that makes sense.~

[gundalow]

Do we want to start testing fedora26?

[mattclay]

I'm updating our Fedora CI testing. My current plan is to:

• Remove testing of Fedora 24 with python 2.
• Remove testing of Fedora 25 with python 2.
• Add testing of Fedora 25 with python 3.
• Add testing of Fedora 26 with python 3.

Fedora 24+ default installations are python 3.5+ only. These changes update CI to match.

[pilou-]

Failure of copymodule integration tests: #25672.

PR needs to be rebased. Nothing to discuss today.

[pdellaert]

Can we add a short discussion on running ansible-test inside an environment that requires a proxy?

Specifically when running ansible-test ... --docker, the docker images are unable to run commands that require external access (for instance pip).

Suggestion: expose *_proxy environment variables to all containers.

Not sure if tox supports this, btw, i've seen some issues there (could be related to something else)

[pilou-]

@pdellaert, during Testing Working Group mattclay wrote:

I can understand why someone might need it to run tests. However, getting all the tests to work with a proxy might be difficult.

[pdellaert]

@pilou-, There's two aspects :

• Test infrastructure aspect: containers being able to install stuff through pip or apt/yum, or tox being able to use proxy
• Tests themselves: Tests needing to connect to the outside world through a proxy, for instance to connect to external APIs (mainly integration testing might be impacted here)

I'd suggest support a proxy within the test infrastructure.

The tests themselves is a different story, these are indeed a lot more complicated and will depend significantly on a test per test basis (some might require a proxy, while others might not because connections are local)

A rough approach could be (if enough support/interest, of course):

• Stage 1: Provide test infrastructure support for proxy, through a new flag in ansible-test (--proxy), this flag sets the http_proxy, https_proxy and the apt/yum proxy values within the docker containers (-e..., as far as i know both Ubuntu and CentOS base containers support an -e setting to configure apt or yum proxy). The flag also configures tox to use the proxy if tests are run through tox.

• Stage 2: For integration testing itself: Expand the test system to allow specifying a boolean in the test cases 'requires_proxy', which would push the proxy setting from Stage 1 into the facts used by the integration playbooks.

[pilou-]

To sum up the meeting:

• copy integration tests fails (PR) when managed and controller aren't the same (CI use one host for managed and controller).
  
  
  
  • that could be solved using different filename prefixes ("local" for local file/"remote" for local file)
  
  
  • Pilou will update the pull requests.
  
  
• test infrastructure support for proxy:
  
  
  
  • pdellaert will provide environment variables, then cc mattclay
  
  
  • mattclay will create a PR with implementation, then pdellaert will be able to test it
  
  
• Pylint tests:
  
  
  
  • abadger1999 has been doing quite a bit of recent code cleanup around Pylint failures: undefined-variable test is enabled
  
  
  • abadger1999 is working on cleaning up wildcard imports.
  
  
  • Volunteers for cleaning up existing pylint issues can reach out to abadger1999 anytime :-)
  
  

[mattclay]

@pilou- Thank you for the excellent summary.

[pilou-]

~I would like to discuss cloud/packet integration tests (https://github.com/ansible/ansible/pull/23127) at the next meeting.~

Pilou to get more details on the Packet sandbox API for possible use with integration tests.

[pdellaert]

~On my action point:
ansible/ansible#27697~

mattclay to add experimental proxy support to ansible-test.
pdellaert has volunteered to test once a PR is ready.

[Spredzy]

~I would like to discuss the addition of the latest macOS 10.12 image in the CI pipeline (current 10.11)~

Spredzy wasn't around for the meeting, so we can discuss more next time.

A brief update from the meeting:

With our current CI resources, we can only test one version of macOS in CI.
So we'll either need to switch from 10.11 to 10.12 or allocate more resources for macOS testing.

[gundalow]

Ansible Contributor Summit 5 (Part of AnsibleFest 2017 San Francisco)

When: 2017-09-06:
Notes: https://public.etherpad-mozilla.org/p/ansible-summit-september-2017
Event will be in person + online (Video + IRC)

Agenda is open for topics for the next Contributors Summit

Please add (and vote +1) for any topics.

[Akasurde]

PR needs review:

• https://github.com/ansible/ansible/pull/26309 - Add testcases for github_issue MERGED
• https://github.com/ansible/ansible/pull/26859 - Refactor code and testcase for find_host_by_cluster_datacenter MERGED

[gundalow]

NOTE: meetings are canceled for the week Aug 21st to 25th due to 'all hands' meeting for the core team. We will resume normal schedule after that.

[mattclay]

~What should qualify as a destructive test? Existing documentation covers this, but we may want to consider changing the criteria.~

The documentation for destructive tests will be clarified. Destructive tests are those which make changes outside of files or directories belonging only to tests. This would include installing/upgrading/uninstalling packages, creating/deleting users, etc.

Additionally, tests which are destructive, but not yet marked as such, will be updated.

It was also requested that by default tests should be assumed destructive and must be marked non_destructive if they are not. This will be done separately, as it is a more invasive change.

[gundalow]

NOTE: meetings are canceled for the week September 4th through 8th due to AnsibleFest San Francisco. We will resume normal schedule after that.

[gundalow]

Now that 2.4.0 has been released, it seems like a sensible point to move to a fresh agenda
https://github.com/ansible/community/issues/248

NO MORE COMMENTS HERE PLEASE