add v2 scaffolding

.github/workflows/ci.yml

@@ -1,6 +1,13 @@
 name: NTH Continuous Integration and Release
 
-on: [push, pull_request, workflow_dispatch]
+on:
+  pull_request:
+    branches:
+    - main
+  push:
+    branches:
+    - main
+  workflow_dispatch:
 
 env:
   DEFAULT_GO_VERSION: ^1.16

BUILD.md

@@ -1,69 +1 @@
-# Build
-If you would like to build and run the project locally you can follow these steps:
-
-Clone the repo:
-```
-git clone https://github.com/aws/aws-node-termination-handler.git
-```
-Build the latest version of the docker image:
-```
-make docker-build
-```
-
-### Multi-Target
-
-By default a linux/amd64 image will be built. To build for a different target the build-arg `GOARCH` can be changed.
-
-```
-$ docker build --build-arg=GOARCH=amd64 -t ${USER}/aws-node-termination-handler-amd64:v1.0.0 .
-$ docker build --build-arg=GOARCH=arm64 -t ${USER}/aws-node-termination-handler-arm64:v1.0.0 .
-```
-
-To push a multi-arch image, the helper tool [manifest-tool](https://github.com/estesp/manifest-tool) can be used.
-
-```
-$ cat << EOF > manifest.yaml
-image: ${USER}/aws-node-termination-handler:v1.0.0
-manifests:
-  -
-    image: ${USER}/aws-node-termination-handler-amd64:v1.0.0
-    platform:
-      architecture: amd64
-      os: linux
-  -
-    image: ${USER}/aws-node-termination-handler-arm64:v1.0.0
-    platform:
-      architecture: arm64
-      os: linux
-EOF
-$ manifest-tool push from-spec manifest.yaml
-```
-
-### Go Module Proxy
-
-By default, Go 1.13+ uses the proxy.golang.org proxy for go module downloads. This can be changed to a different go module proxy or revert back to pre-go 1.13 default which was "direct". `GOPROXY=direct` will pull from the VCS provider directly instead of going through a proxy at all.
-
-```
-## No Proxy
-docker build --build-arg=GOPROXY=direct -t ${USER}/aws-node-termination-handler:v1.0.0 .
-
-## My Corp Proxy
-docker build --build-arg=GOPROXY=go-proxy.mycorp.com -t ${USER}/aws-node-termination-handler:v1.0.0 .
-```
-
-### Kubernetes Object Files
-
-We use Kustomize to create a master Kubernetes yaml file. You can apply the base (default confg), use the provided overlays, or write your own custom overlays.
-
-*NOTE: Kustomize was built into kubectl starting with kubernetes 1.14. If you are using an older version of kubernetes or `kubectl`, you can download the `kustomize` binary for your platform on their github releases page: https://github.com/kubernetes-sigs/kustomize/releases*
-
-```
-## Apply base kustomize directly kubernetes
-kubectl apply -k $REPO_ROOT/config/base
-
-## OR apply an overlay specifying a node selector to run the daemonset only on spot instances
-## This will use the base and add a node selector into the daemonset K8s object definition
-kubectl apply -k $REPO_ROOT/config/overlays/spot-node-selector
-```
-
-Read more about Kustomize and Overlays: https://kustomize.io
+TBD

CONTRIBUTING.md

@@ -1,18 +1,15 @@
 # Contributing Guidelines
 
-Thank you for your interest in contributing to our project. Whether it's a bug report, new feature, correction, or additional
-documentation, we greatly value feedback and contributions from our community.
+Thank you for your interest in contributing to our project. Whether it's a bug report, new feature, correction, or additional documentation, we greatly value feedback and contributions from our community.
 
-Please read through this document before submitting any issues or pull requests to ensure we have all the necessary
-information to effectively respond to your bug report or contribution.
+Please read through this document before submitting any issues or pull requests to ensure we have all the necessary information to effectively respond to your bug report or contribution.
 
 
 ## Reporting Bugs/Feature Requests
 
 We welcome you to use the GitHub issue tracker to report bugs or suggest features.
 
-When filing an issue, please check existing open, or recently closed, issues to make sure somebody else hasn't already
-reported the issue. Please try to include as much information as you can. Details like these are incredibly useful:
+When filing an issue, please check existing open, or recently closed, issues to make sure somebody else hasn't already reported the issue. Please try to include as much information as you can. Details like these are incredibly useful:
 
 * A reproducible test case or series of steps
 * The version of our code being used
@@ -31,10 +28,11 @@ To send us a pull request, please:
 
 1. Fork the repository.
 2. Modify the source; please focus on the specific change you are contributing. If you also reformat all the code, it will be hard for us to focus on your change.
-3. Ensure local tests pass.
-4. Commit to your fork using clear commit messages.
-5. Send us a pull request, answering any default questions in the pull request interface.
-6. Pay attention to any automated CI failures reported in the pull request, and stay involved in the conversation.
+3. Add or update tests. 
+4. Ensure local tests pass.
+5. Commit to your fork using clear commit messages.
+6. Send us a pull request, answering any default questions in the pull request interface.
+7. Pay attention to any automated CI failures reported in the pull request, and stay involved in the conversation.
 
 GitHub provides additional document on [forking a repository](https://help.github.com/articles/fork-a-repo/) and
 [creating a pull request](https://help.github.com/articles/creating-a-pull-request/).