1 | # Contributing
|
2 |
|
3 | 🎉 Thanks for taking the time to contribute to Dockter! 🎉
|
4 |
|
5 |
|
6 | # Table of Contents
|
7 |
|
8 | [General contribution guidelines](#general-contribution-guidelines)
|
9 | * [Licensing and contributor agreement](#licensing-and-contributor-agreement)
|
10 |
|
11 | [Development](#development)
|
12 | * [Development environment](#development-environment)
|
13 | * [Linting and testing](#linting-and-testing)
|
14 | * [Documentation generation](#documentation-generation)
|
15 | * [Commit messages](#commit-messages)
|
16 | * [Continuous integration](#continuous-integration)
|
17 | * [Python System Dependencies](#python-system-dependencies)
|
18 | * [Using The Router and Server](#using-the-router-and-server)
|
19 |
|
20 | # General contribution guidelines
|
21 |
|
22 | [Stencila][stencila-site] is an open-source community-driven project. We encourage
|
23 | and welcome contributions from all community members.
|
24 |
|
25 | These are mostly guidelines, not rules.
|
26 | Use your best judgment, and feel free to propose changes to this document in a pull request.
|
27 |
|
28 | If you are comfortable with Git and GitHub, you can submit a pull request (PR). In Stencila we follow a commonly used workflow
|
29 | for [contributing to open source projects][how-contribute] (see also [GitHub instructions][github-flow]).
|
30 |
|
31 | If you have specific suggestions or have found a bug, please [create an issue](https://github.com/stencila/dockter/issues/new).
|
32 |
|
33 | If you don't want to use GitHub, please tell us what you think on [our chat](https://gitter.im/stencila/stencila) on Gitter or have your say on our
|
34 | our [Community Forum](https://community.stenci.la/).
|
35 |
|
36 | ## Licensing and code of conduct
|
37 |
|
38 | By contributing, you agree that we may redistribute your work under [our license](LICENSE).
|
39 | Everyone involved with Stencila agrees to abide by our [code of conduct][conduct].
|
40 |
|
41 | ## Get in touch!
|
42 |
|
43 | You can chat with the team at our [community forum][community-forum],
|
44 | on Twitter [@Stencila][stencila-twitter],
|
45 | [Gitter][stencila-gitter], or email to [hello@stenci.la][contact]
|
46 |
|
47 |
|
48 | ## Development
|
49 |
|
50 | ### Getting started
|
51 |
|
52 | ### Development environment
|
53 |
|
54 | Dockter is implemented as a `Node.js` package in order to make it easier to integrate with other Stencila components written also in this language.
|
55 | Therefore, in order to develop Dockter you need to have `Node.js` installed on your machine, along with `npm`.
|
56 | The core of the source code of Dockter is written using [`TypeScript`](https://www.typescriptlang.org/) which is then compiled into JavaScript.
|
57 |
|
58 | To get started,
|
59 |
|
60 | ```bash
|
61 | git clone https://github.com/stencila/dockter
|
62 | cd dockter
|
63 | npm install
|
64 | ```
|
65 |
|
66 | To run the CLI during development use, `npm run cli -- <args>` e.g.
|
67 |
|
68 | ```bash
|
69 | npm run cli -- compile tests/fixtures/dockerfile-date/Dockerfile
|
70 | ```
|
71 |
|
72 | This uses `ts-node` to compile and run Typescript on the fly so that you don't need to do a build step first.
|
73 |
|
74 |
|
75 | ## Architecture
|
76 |
|
77 | Dockter implements a compiler design pattern. Source files are _parsed_ into a `SoftwareEnvironment` instance (the equivalent of an AST (Abstract Syntax Tree) in other programming language compilers) which is then used to generate a `Dockerfile` which is then built into a Docker image.
|
78 |
|
79 | The parser classes e.g. `PythonParser`, `RParser` scan for relevant source files and generate `SoftwareEnvironment` instances.
|
80 | The generator classes e.g. `PythonGenerator`, `RGenerator` generates a `Dockerfile` for a given `SoftwareEnvironment`.
|
81 | `DockerGenerator` is a super-generator which combines the other generators.
|
82 | `DockerBuilder` class builds
|
83 | `DockerCompiler` links all of these together.
|
84 |
|
85 | For example, if a folder has single file in it `code.py`, `PythonParser` will parse that file and create a `SoftwareEnvironment` instance, which `DockerGenerator` uses to generate a `Dockerfile`, which `DockerBuilder` uses to build a Docker image.
|
86 |
|
87 |
|
88 | ### Linting and testing
|
89 |
|
90 | Please check that your changes pass linting and unit tests,
|
91 |
|
92 | ```bash
|
93 | npm run lint # or, make lint
|
94 | npm test # or, make text
|
95 | ```
|
96 |
|
97 | Use `npm test -- <test file path>` to run a single test file.
|
98 |
|
99 | You can setup a Git pre-commit hook to perform these checks automatically before each commit using `make hooks`.
|
100 |
|
101 | You can check that any changes you've made are covered 🏅 by unit tests using,
|
102 |
|
103 | ```bash
|
104 | npm run cover # or, make cover
|
105 | open coverage/lcov-report/index.html
|
106 | ```
|
107 |
|
108 | ### Documentation generation
|
109 |
|
110 | If you've been working on in-code documentation 🙏 you can check that by building and viewing the docs,
|
111 |
|
112 | ```bash
|
113 | npm run docs # or, make docs
|
114 | open docs/index.html
|
115 | ```
|
116 |
|
117 | ### Commit messages
|
118 |
|
119 | Please use [conventional changelog](https://github.com/conventional-changelog/conventional-changelog) style commit messages e.g. `docs(readme): fixed spelling mistake`. See [the specifications](https://www.conventionalcommits.org/en/v1.0.0-beta.2/) for full details. This help with automated semantic versioning.
|
120 | To make this easier, [Commitzen](http://commitizen.github.io/cz-cli/) is a development dependency and can be used via `npm` or `make`:
|
121 |
|
122 | ```bash
|
123 | npm run commit # or, make commit
|
124 | ```
|
125 |
|
126 | ### Continuous integration
|
127 |
|
128 | Linting, test coverage, binary builds, package builds, and documentation generation are done on [Travis CI](https://travis-ci.org/stencila/dockter). [`semantic-release`](https://github.com/semantic-release/semantic-release) is enabled to automate version management: minor version releases are done if any `feat(...)` commits are pushed, patch version releases are done if any `fix(...)` commits are pushed. Releases are made to [NPM](https://www.npmjs.com/package/@stencila/dockter) and [Github Releases](https://github.com/stencila/dockter/releases).
|
129 |
|
130 |
|
131 | ### Python System Dependencies
|
132 |
|
133 | We maintain a list of system packages (e.g `deb`/`rpm`) that a Python packages installed through `pip` might need to include. These are in the file `PythonSystemDependencies.json`.
|
134 | If you find a Python package that relies on a system library you can add the lookup to this file; the mapping is in the format `lookup[pythonPackageName][pythonVersion(str)][packagingType][osVersion]`. The `"default"` can be used as a fallback at any level. For example:
|
135 |
|
136 | - `["pypackage"]["2"]["deb"]["trusty"] = ["some-deb-package"]`
|
137 | - `["otherpypackage"]["3"]["rpm"]["default"] = ["some-rpm-package"]`
|
138 | - `["thirdpypackage"]["default"]["default"]["default"] = ["some-consistent-package", "some-other-package"]`
|
139 |
|
140 |
|
141 | ### Using the router and server
|
142 |
|
143 | The [Express](https://expressjs.com) router provides `PUT /compile` and `PUT /execute` endpoints (which do the same thing as the corresponding CLI commands). You can serve them using,
|
144 |
|
145 | ```bash
|
146 | npm start
|
147 | ```
|
148 |
|
149 | Or, during development using,
|
150 |
|
151 | ```bash
|
152 | npm run server
|
153 | ```
|
154 |
|
155 | A minimal example of how to integrate the router into your own Express server,
|
156 |
|
157 | ```js
|
158 | const app = require('express')()
|
159 | const { docker } = require('@stencila/dockter')
|
160 |
|
161 | const app = express()
|
162 | app.use('/docker', docker)
|
163 | app.listen(3000)
|
164 | ```
|
165 |
|
166 |
|
167 |
|
168 | [contact]: mailto:hello@stenci.la
|
169 | [conduct]: https://github.com/stencila/policies/blob/master/CONDUCT.md
|
170 | [github-flow]: https://guides.github.com/introduction/flow/
|
171 | [github-join]: https://github.com/join
|
172 | [issues]: https://help.github.com/articles/creating-an-issue/
|
173 | [how-contribute]: https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github
|
174 | [stencila-site]: http://stenci.la/
|
175 | [stencila-repo]: https://github.com/stencila/stencila
|
176 | [stencila-twitter]: https://twitter.com/stencila
|
177 | [stencila-gitter]: https://gitter.im/stencila/stencila/ |
\ | No newline at end of file |