├── .dockerignore ├── .gitignore ├── CONTRIBUTING.md ├── DCO ├── Dockerfile ├── LICENSE ├── NOTICE ├── README.md ├── bounce.conf └── contrib └── k8s ├── https-redirect-rc.yaml └── https-redirect-service.yaml /.dockerignore: -------------------------------------------------------------------------------- 1 | .git 2 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *~ 2 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # How to Contribute 2 | 3 | CoreOS projects are [Apache 2.0 licensed](LICENSE) and accept contributions via 4 | GitHub pull requests. This document outlines some of the conventions on 5 | development workflow, commit message formatting, contact points and other 6 | resources to make it easier to get your contribution accepted. 7 | 8 | # Certificate of Origin 9 | 10 | By contributing to this project you agree to the Developer Certificate of 11 | Origin (DCO). This document was created by the Linux Kernel community and is a 12 | simple statement that you, as a contributor, have the legal right to make the 13 | contribution. See the [DCO](DCO) file for details. 14 | 15 | # Email and Chat 16 | 17 | The project currently uses the general CoreOS email list and IRC channel: 18 | - Email: [coreos-dev](https://groups.google.com/forum/#!forum/coreos-dev) 19 | - IRC: #[coreos](irc://irc.freenode.org:6667/#coreos) IRC channel on freenode.org 20 | 21 | Please avoid emailing maintainers found in the MAINTAINERS file directly. They 22 | are very busy and read the mailing lists. 23 | 24 | ## Getting Started 25 | 26 | - Fork the repository on GitHub 27 | - Read the [README](README.md) for build and test instructions 28 | - Play with the project, submit bugs, submit patches! 29 | 30 | ## Contribution Flow 31 | 32 | This is a rough outline of what a contributor's workflow looks like: 33 | 34 | - Create a topic branch from where you want to base your work (usually master). 35 | - Make commits of logical units. 36 | - Make sure your commit messages are in the proper format (see below). 37 | - Push your changes to a topic branch in your fork of the repository. 38 | - Make sure the tests pass, and add any new tests as appropriate. 39 | - Submit a pull request to the original repository. 40 | 41 | Thanks for your contributions! 42 | 43 | ### Coding Style 44 | 45 | CoreOS projects written in Go follow a set of style guidelines that we've documented 46 | [here](https://github.com/coreos/docs/tree/master/golang). Please follow them when 47 | working on your contributions. 48 | 49 | ### Format of the Commit Message 50 | 51 | We follow a rough convention for commit messages that is designed to answer two 52 | questions: what changed and why. The subject line should feature the what and 53 | the body of the commit should describe the why. 54 | 55 | ``` 56 | scripts: add the test-cluster command 57 | 58 | this uses tmux to setup a test cluster that you can easily kill and 59 | start for debugging. 60 | 61 | Fixes #38 62 | ``` 63 | 64 | The format can be described more formally as follows: 65 | 66 | ``` 67 | : 68 | 69 | 70 | 71 |