3a9c48b8a3
* POC code for inotify UDS-io-socket * http-stream format introducing the `http-stream` format support in fn. there are many details for this, none of which can be linked from github :( -- docs are coming (I could even try to add some here?). this is kinda MVP-ish level, but does not implement the remaining spec, ie 'headers' fixing up / invoke fixing up. the thinking being we can land this to test fdks / cli with and start splitting work up on top of this. all other formats work the same as previous (no breakage, only new stuff) with the cli you can set `format: http-stream` and deploy, and then invoke a function via the `http-stream` format. this uses unix domain socket (uds) on the container instead of previous stdin/stdout, and fdks will have to support this in a new fashion (will see about getting docs on here). fdk-go works, which is here: https://github.com/fnproject/fdk-go/pull/30 . the output looks the same as an http format function when invoking a function. wahoo. there's some amount of stuff we can clean up here, enumerated: * the cleanup of the sock files is iffy, high pri here * permissions are a pain in the ass and i punted on dealing with them. you can run `sudo ./fnserver` if running locally, it may/may not work in dind(?) ootb * no pipe usage at all (yay), still could reduce buffer usage around the pipe behavior, we could clean this up potentially before removal (and tests) * my brain can’t figure out if dispatchOldFormats changes pipe behavior, but tests work * i marked XXX to do some clean up which will follow soon… need this to test fdk tho so meh, any thoughts on those marked would be appreciated however (1 less decision for me). mostly happy w/ general shape/plumbing tho * there are no tests atm, this is a tricky dance indeed. attempts were made. need to futz with the permission stuff before committing to adding any tests here, which I don't like either. also, need to get the fdk-go based test image updated according to the fdk-go, and there's a dance there too. rumba time.. * delaying the big big cleanup until we have good enough fdk support to kill all the other formats. open to ideas on how to maneuver landing stuff... * fix unmount * see if the tests work on ci... * add call id header * fix up makefile * add configurable iofs opts * add format file describing http-stream contract * rm some cruft * default iofs to /tmp, remove mounting out of the box fn we can't mount. /tmp will provide a memory backed fs for us on most systems, this will be fine for local developing and this can be configured to be wherever for anyone that wants to make things more difficult for themselves. also removes the mounting, this has to be done as root. we can't do this in the oss fn (short of requesting root, but no). in the future, we may want to have a knob here to have a function that can be configured in fn that allows further configuration here. since we don't know what we need in this dept really, not doing that yet (it may be the case that it could be done operationally outside of fn, eg, but not if each directory needs to be configured itself, which seems likely, anyway...) * add WIP note just in case...
3.9 KiB
Contributing
Issues
- Request features and report bugs using the GitHub Issue Tracker.
- Please indicate the platform you are using fsnotify on.
- A code example to reproduce the problem is appreciated.
Pull Requests
Contributor License Agreement
fsnotify is derived from code in the golang.org/x/exp package and it may be included in the standard library in the future. Therefore fsnotify carries the same LICENSE as Go. Contributors retain their copyright, so you need to fill out a short form before we can accept your contribution: Google Individual Contributor License Agreement.
Please indicate that you have signed the CLA in your pull request.
How fsnotify is Developed
- Development is done on feature branches.
- Tests are run on BSD, Linux, macOS and Windows.
- Pull requests are reviewed and applied to master using hub.
- Maintainers may modify or squash commits rather than asking contributors to.
- To issue a new release, the maintainers will:
- Update the CHANGELOG
- Tag a version, which will become available through gopkg.in.
How to Fork
For smooth sailing, always use the original import path. Installing with go get makes this easy.
- Install from GitHub (
go get -u github.com/fsnotify/fsnotify) - Create your feature branch (
git checkout -b my-new-feature) - Ensure everything works and the tests pass (see below)
- Commit your changes (
git commit -am 'Add some feature')
Contribute upstream:
- Fork fsnotify on GitHub
- Add your remote (
git remote add fork git@github.com:mycompany/repo.git) - Push to the branch (
git push fork my-new-feature) - Create a new Pull Request on GitHub
This workflow is thoroughly explained by Katrina Owen.
Testing
fsnotify uses build tags to compile different code on Linux, BSD, macOS, and Windows.
Before doing a pull request, please do your best to test your changes on multiple platforms, and list which platforms you were able/unable to test on.
To aid in cross-platform testing there is a Vagrantfile for Linux and BSD.
- Install Vagrant and VirtualBox
- Setup Vagrant Gopher in your
srcfolder. - Run
vagrant upfrom the project folder. You can also setup just one box withvagrant up linuxorvagrant up bsd(note: the BSD box doesn't support Windows hosts at this time, and NFS may prompt for your host OS password) - Once setup, you can run the test suite on a given OS with a single command
vagrant ssh linux -c 'cd fsnotify/fsnotify; go test'. - When you're done, you will want to halt or destroy the Vagrant boxes.
Notice: fsnotify file system events won't trigger in shared folders. The tests get around this limitation by using the /tmp directory.
Right now there is no equivalent solution for Windows and macOS, but there are Windows VMs freely available from Microsoft.
Maintainers
Help maintaining fsnotify is welcome. To be a maintainer:
- Submit a pull request and sign the CLA as above.
- You must be able to run the test suite on Mac, Windows, Linux and BSD.
To keep master clean, the fsnotify project uses the "apply mail" workflow outlined in Nathaniel Talbott's post "Merge pull request" Considered Harmful. This requires installing hub.
All code changes should be internal pull requests.
Releases are tagged using Semantic Versioning.