This repository has been archived by the owner on Oct 24, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 3
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
The readme now indicates how to install/deploy/develop ardere as well as having 100% test coverage and Travis CI hooks. A contributing doc was also added to match other projects. Closes #22
- Loading branch information
Showing
20 changed files
with
932 additions
and
1,677 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
[report] | ||
show_missing = True |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,19 @@ | ||
language: python | ||
cache: pip | ||
sudo: required | ||
dist: precise | ||
|
||
matrix: | ||
include: | ||
- python: 2.7 | ||
|
||
install: | ||
- pip install -r test-requirements.txt | ||
- pip install ${CODECOV:+codecov} | ||
script: | ||
- nosetests -d tests -- ${CODECOV:+--with-coverage --cover-xml --cover-package=ardere} | ||
after_success: | ||
- ${CODECOV:+codecov} | ||
notifications: | ||
slack: | ||
secure: vT9sWtUuxk28g6xYKAsQmiPZllErOYVfx5lcL+/jo1eRFrmbpYnyndT6s+FxGI1547oizZ0IqZbHVvB7BUoSJixXJyQJYXW2MchwN1UeHrey8mYpF1GNEaJT7FMfqSkxUU9gvAZ3IU7zstNeTLbfG1GkLuzybp0WAiHl/ocUTz8= |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,77 @@ | ||
# Contribution Guidelines | ||
|
||
Anyone is welcome to contribute to this project. Feel free to get in touch with | ||
other community members on IRC, the mailing list or through issues here on | ||
GitHub. | ||
|
||
[See the README](/README.md) for contact information. | ||
|
||
## Bug Reports | ||
|
||
You can file issues here on GitHub. Please try to include as much information as | ||
you can and under what conditions you saw the issue. | ||
|
||
## Sending Pull Requests | ||
|
||
Patches should be submitted as pull requests (PR). | ||
|
||
Before submitting a PR: | ||
- Your code must run and pass all the automated tests before you submit your PR | ||
for review. "Work in progress" pull requests are allowed to be submitted, but | ||
should be clearly labeled as such and should not be merged until all tests | ||
pass and the code has been reviewed. | ||
- Your patch should include new tests that cover your changes. It is your and | ||
your reviewer's responsibility to ensure your patch includes adequate tests. | ||
|
||
When submitting a PR: | ||
- You agree to license your code under the project's open source license | ||
([MPL 2.0](/LICENSE)). | ||
- Base your branch off the current `master` (see below for an example workflow). | ||
- Add both your code and new tests if relevant. | ||
- Run the test suite to make sure your code passes linting and tests. | ||
- Please do not include merge commits in pull requests; include only commits with the new relevant code. | ||
|
||
See the main [README.md](/README.md) for information on prerequisites, installing, running and testing. | ||
|
||
## Code Review | ||
|
||
This project is production Mozilla code and subject to our [engineering practices and quality standards](https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Committing_Rules_and_Responsibilities). Every patch must be peer reviewed. | ||
|
||
## Git Commit Guidelines | ||
|
||
We loosely follow the [Angular commit guidelines](https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#type) of `<type>(<scope>): <subject>` where `type` must be one of: | ||
|
||
* **feat**: A new feature | ||
* **fix**: A bug fix | ||
* **docs**: Documentation only changes | ||
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing | ||
semi-colons, etc) | ||
* **refactor**: A code change that neither fixes a bug or adds a feature | ||
* **perf**: A code change that improves performance | ||
* **test**: Adding missing tests | ||
* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation | ||
generation | ||
|
||
### Scope | ||
The scope could be anything specifying place of the commit change. | ||
|
||
### Subject | ||
The subject contains succinct description of the change: | ||
|
||
* use the imperative, present tense: "change" not "changed" nor "changes" | ||
* don't capitalize first letter | ||
* no dot (.) at the end | ||
|
||
###Body | ||
In order to maintain a reference to the context of the commit, add | ||
`fixes #<issue_number>` if it closes a related issue or `issue #<issue_number>` | ||
if it's a partial fix. | ||
|
||
You can also write a detailed description of the commit: Just as in the | ||
**subject**, use the imperative, present tense: "change" not "changed" nor | ||
"changes" It should include the motivation for the change and contrast this with | ||
previous behavior. | ||
|
||
###Footer | ||
The footer should contain any information about **Breaking Changes** and is also | ||
the place to reference GitHub issues that this commit **Closes**. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,2 +1,47 @@ | ||
# ardere | ||
AWS Serverless Service for Load-Testing | ||
*AWS Serverless Service for Load-Testing* | ||
|
||
ardere runs as a serverless service using AWS to orchestrate | ||
load-tests consisting of docker container configurations arranged as | ||
test plans. | ||
|
||
## Installation | ||
|
||
To deploy ardere to your AWS account, you will need a fairly recent | ||
install of Node, then install the Node packages required: | ||
|
||
$ npm install | ||
|
||
You will need to ensure your have AWS access and secret keys configured | ||
for serverless: | ||
|
||
$ sls config | ||
|
||
To deploy the ardere lambda's and required AWS stack: | ||
|
||
$ sls deploy | ||
|
||
Then you can deploy the ardere Step Function: | ||
|
||
$ sls deploy stepf | ||
|
||
|
||
## Developing | ||
|
||
ardere is written in Python and deployed via serverless to AWS. To an | ||
extent testing it on AWS is the most reliable indicator it works as | ||
intended. However, there are sets of tests that ensure the Python code | ||
is valid and works with arguments as intended that may be run locally. | ||
|
||
Create a Python virtualenv, and install the test requirements: | ||
|
||
$ virtualenv ardenv | ||
$ source ardenv/bin/activate | ||
$ pip install -r test-requirements.txt | ||
|
||
The tests can now be run with nose: | ||
|
||
$ nosetests | ||
|
||
Note that **you cannot run the sls deploy while the virtualenv is active** | ||
due to how the serverless Python requirements plugin operates. |
Oops, something went wrong.