[release] Release including updated Dockerfiles

images/supported/.appveyor.yml

@@ -0,0 +1,28 @@
+clone_folder: c:\gopath\src\github.com\containernetworking\plugins
+
+environment:
+  GOPATH: c:\gopath
+
+install:
+  - echo %PATH%
+  - echo %GOPATH%
+  - set PATH=%GOPATH%\bin;c:\go\bin;%PATH%
+  - go version
+  - go env
+
+build: off
+
+test_script:
+  - ps: |
+      go list ./... | Select-String -Pattern (Get-Content "./plugins/linux_only.txt") -NotMatch > "to_test.txt"
+      echo "Will test:"
+      Get-Content "to_test.txt"
+      foreach ($pkg in Get-Content "to_test.txt") {
+        if ($pkg) {
+          echo $pkg
+          go test -v $pkg
+          if ($LastExitCode -ne 0) {
+            throw "test failed"
+          }
+        }
+      }

images/supported/.gitignore

@@ -0,0 +1,28 @@
+# Compiled Object files, Static and Dynamic libs (Shared Objects)
+*.o
+*.a
+*.so
+
+# Folders
+_obj
+_test
+
+# Architecture specific extensions/prefixes
+*.[568vq]
+[568vq].out
+
+*.cgo1.go
+*.cgo2.c
+_cgo_defun.c
+_cgo_gotypes.go
+_cgo_export.*
+
+_testmain.go
+
+*.exe
+*.test
+*.prof
+
+bin/
+gopath/
+.vagrant

images/supported/.travis.yml

@@ -0,0 +1,37 @@
+language: go
+sudo: required
+dist: trusty
+
+go:
+  - 1.8.x
+  - 1.9.x
+
+env:
+  global:
+  - PATH=$GOROOT/bin:$GOPATH/bin:$PATH
+  matrix:
+  - TARGET=amd64
+  - TARGET=arm
+  - TARGET=arm64
+  - TARGET=ppc64le
+  - TARGET=s390x
+
+matrix:
+  fast_finish: true
+
+install:
+  - go get github.com/onsi/ginkgo/ginkgo
+
+script:
+ - |
+   if [ "${TARGET}" == "amd64" ]; then
+     GOARCH="${TARGET}" ./test.sh
+   else
+     GOARCH="${TARGET}" ./build.sh
+   fi
+
+notifications:
+  email: false
+
+git:
+  depth: 9999999

images/supported/CONTRIBUTING.md

@@ -0,0 +1,134 @@
+# How to Contribute
+
+CNI is [Apache 2.0 licensed](LICENSE) and accepts contributions via GitHub
+pull requests. This document outlines some of the conventions on development
+workflow, commit message formatting, contact points and other resources to make
+it easier to get your contribution accepted.
+
+We gratefully welcome improvements to documentation as well as to code.
+
+# Certificate of Origin
+
+By contributing to this project you agree to the Developer Certificate of
+Origin (DCO). This document was created by the Linux Kernel community and is a
+simple statement that you, as a contributor, have the legal right to make the
+contribution. See the [DCO](DCO) file for details.
+
+# Email and Chat
+
+The project uses the the cni-dev email list and IRC chat:
+- Email: [cni-dev](https://groups.google.com/forum/#!forum/cni-dev)
+- IRC: #[containernetworking](irc://irc.freenode.org:6667/#containernetworking) channel on freenode.org
+
+Please avoid emailing maintainers found in the MAINTAINERS file directly. They
+are very busy and read the mailing lists.
+
+## Getting Started
+
+- Fork the repository on GitHub
+- Read the [README](README.md) for build and test instructions
+- Play with the project, submit bugs, submit pull requests!
+
+## Contribution workflow
+
+This is a rough outline of how to prepare a contribution:
+
+- Create a topic branch from where you want to base your work (usually branched from master).
+- Make commits of logical units.
+- Make sure your commit messages are in the proper format (see below).
+- Push your changes to a topic branch in your fork of the repository.
+- If you changed code:
+   - add automated tests to cover your changes, using the [Ginkgo](http://onsi.github.io/ginkgo/) & [Gomega](http://onsi.github.io/gomega/) style
+   - if the package did not previously have any test coverage, add it to the list
+   of `TESTABLE` packages in the `test.sh` script.
+   - run the full test script and ensure it passes
+- Make sure any new code files have a license header (this is now enforced by automated tests)
+- Submit a pull request to the original repository.
+
+## How to run the test suite
+We generally require test coverage of any new features or bug fixes.
+
+Here's how you can run the test suite on any system (even Mac or Windows) using
+ [Vagrant](https://www.vagrantup.com/) and a hypervisor of your choice:
+
+First, ensure that you have the [CNI repo](https://github.com/containernetworking/cni) and this repo (plugins) cloned side-by-side:
+```bash
+cd ~/workspace
+git clone https://github.com/containernetworking/cni
+git clone https://github.com/containernetworking/plugins
+```
+
+Next, boot the virtual machine and SSH in to run the tests:
+
+```bash
+vagrant up
+vagrant ssh
+# you're now in a shell in a virtual machine
+sudo su
+cd /go/src/github.com/containernetworking/plugins
+
+# to run the full test suite
+./test.sh
+
+# to focus on a particular test suite
+cd plugins/main/loopback
+go test
+```
+
+# Acceptance policy
+
+These things will make a PR more likely to be accepted:
+
+ * a well-described requirement
+ * tests for new code
+ * tests for old code!
+ * new code and tests follow the conventions in old code and tests
+ * a good commit message (see below)
+
+In general, we will merge a PR once two maintainers have endorsed it.
+Trivial changes (e.g., corrections to spelling) may get waved through.
+For substantial changes, more people may become involved, and you might get asked to resubmit the PR or divide the changes into more than one PR.
+
+### Format of the Commit Message
+
+We follow a rough convention for commit messages that is designed to answer two
+questions: what changed and why. The subject line should feature the what and
+the body of the commit should describe the why.
+
+```
+scripts: add the test-cluster command
+
+this uses tmux to setup a test cluster that you can easily kill and
+start for debugging.
+
+Fixes #38
+```
+
+The format can be described more formally as follows:
+
+```
+<subsystem>: <what changed>
+<BLANK LINE>
+<why this change was made>
+<BLANK LINE>
+<footer>
+```
+
+The first line is the subject and should be no longer than 70 characters, the
+second line is always blank, and other lines should be wrapped at 80 characters.
+This allows the message to be easier to read on GitHub as well as in various
+git tools.
+
+## 3rd party plugins
+So you've built a CNI plugin.  Where should it live?
+
+Short answer: We'd be happy to link to it from our [list of 3rd party plugins](README.md#3rd-party-plugins).
+But we'd rather you kept the code in your own repo.
+
+Long answer: An advantage of the CNI model is that independent plugins can be
+built, distributed and used without any code changes to this repository.  While
+some widely used plugins (and a few less-popular legacy ones) live in this repo,
+we're reluctant to add more.
+
+If you have a good reason why the CNI maintainers should take custody of your
+plugin, please open an issue or PR.