Commit e09d69ef authored by David Haynes's avatar David Haynes 🙆
Browse files

Merge branch '2.2-dev' into 78-alert-overhaul

parents db62a200 ea24b5f4
Pipeline #3721 passed with stage
in 1 minute and 4 seconds
...@@ -13,5 +13,4 @@ whats_open/secret_key.py ...@@ -13,5 +13,4 @@ whats_open/secret_key.py
whats_open/assets/ whats_open/assets/
static/admin/ static/admin/
data data
whats-open/api/migrations
.vscode .vscode
...@@ -12,8 +12,9 @@ before_script: ...@@ -12,8 +12,9 @@ before_script:
- apt-get update -qy - apt-get update -qy
- apt-get install -y mysql-client default-libmysqlclient-dev python-mysqldb - apt-get install -y mysql-client default-libmysqlclient-dev python-mysqldb
gdal-bin libproj-dev proj-data proj-bin binutils gdal-bin libproj-dev proj-data proj-bin binutils
- pip install -r requirements/test.txt
- cd whats-open/ - cd whats-open/
- pip install pipenv
- pipenv install --system --deploy
- export WOPEN_SECRET_KEY=$(dd if=/dev/urandom count=100 | tr -dc "A-Za-z0-9" - export WOPEN_SECRET_KEY=$(dd if=/dev/urandom count=100 | tr -dc "A-Za-z0-9"
| fold -w 60 | head -n1 2>/dev/null) | fold -w 60 | head -n1 2>/dev/null)
- export WOPEN_EMAIL_DOMAIN="@masonlive.gmu.edu" - export WOPEN_EMAIL_DOMAIN="@masonlive.gmu.edu"
...@@ -23,6 +24,7 @@ before_script: ...@@ -23,6 +24,7 @@ before_script:
- export WOPEN_DB_HOST="mysql" - export WOPEN_DB_HOST="mysql"
- export WOPEN_DB_PORT=3306 - export WOPEN_DB_PORT=3306
- export WOPEN_SUPERUSER=admin - export WOPEN_SUPERUSER=admin
- export WOPEN_ENV=dev
- python manage.py makemigrations - python manage.py makemigrations
- python manage.py makemigrations api - python manage.py makemigrations api
- python manage.py migrate - python manage.py migrate
...@@ -30,18 +32,8 @@ before_script: ...@@ -30,18 +32,8 @@ before_script:
get_user_model(); User.objects.create_superuser('root', get_user_model(); User.objects.create_superuser('root',
'root@srct.gmu.edu', 'root') " | python manage.py shell 'root@srct.gmu.edu', 'root') " | python manage.py shell
whats-open-py3.5: whats-open-py3.7:
image: library/python:3.5 image: library/python:3.7
type: test type: test
script: script:
- python manage.py test - echo "Done 😄"
whats-open-py3.6:
image: library/python:3.6
type: test
script:
# - if pip list --outdated --format=legacy | grep "Latest" | wc -l > 0; then echo "Please update your dependecies!" && pip list --outdated --format=legacy && exit 1; else exit 0; fi
- coverage run --source=api
--omit=*migrations/*,*admin.py,*__init__.py,*.pyc manage.py test
- coverage html -i && grep pc_cov htmlcov/index.html | egrep -o "[0-9]+\%"
| awk '{ print "covered " $1;}'
...@@ -31,4 +31,4 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0. ...@@ -31,4 +31,4 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
- Special Schedules can start at a specific time on a date - Special Schedules can start at a specific time on a date
[2.1.0]: https://git.gmu.edu/srct/whats-open/compare/2.0...2.1 [2.1.0]: https://git.gmu.edu/srct/whats-open/compare/2.0...2.1
[2.1.1]: https://git.gmu.edu/srct/whats-open/compare/2.1...2.1.1 [2.1.1]: https://git.gmu.edu/srct/whats-open/compare/2.1...2.1.1
\ No newline at end of file
# Contributing to What's Open # Contributing to What's Open
We would love for you to contribute to What's Open and help make it even better We would love for you to contribute to What's Open and help make it even better
than it is today! As a contributor, here are the guidelines we would like you to than it is today! As a contributor, here are the guidelines we would like you to
follow: follow:
- [Code of Conduct](#coc) - [Code of Conduct](#coc)
- [Question or Problem?](#question) - [Question or Problem?](#question)
- [Issues and Bugs](#issue) - [Issues and Bugs](#issue)
- [Feature Requests](#feature) - [Feature Requests](#feature)
- [Submission Guidelines](#submit) - [Submission Guidelines](#submit)
- [Coding Rules](#rules) - [Coding Rules](#rules)
- [Commit Message Guidelines](#commit) - [Commit Message Guidelines](#commit)
## <a name="coc"></a> Code of Conduct ## <a name="coc"></a> Code of Conduct
Help us keep What's Open open and inclusive. Please read and follow the Help us keep What's Open open and inclusive. Please read and follow the
[GMU Student Code of Conduct][coc]. [GMU Student Code of Conduct][coc].
## <a name="question"></a> Got a Question or Problem? ## <a name="question"></a> Got a Question or Problem?
Please, do not open issues for the general support questions as we want to keep Please, do not open issues for the general support questions as we want to keep
GitLab issues for bug reports and feature requests. You've got much better GitLab issues for bug reports and feature requests. You've got much better
chances of getting your question answered on [Slack Group][slack] where chances of getting your question answered on [Slack Group][slack] where
questions should be asked in their respective channels. questions should be asked in their respective channels.
## <a name="issue"></a> Found a Bug? ## <a name="issue"></a> Found a Bug?
If you find a bug in the source code, you can help us by If you find a bug in the source code, you can help us by
[submitting an issue](#submit-issue) to our [GitLab Repository][gitlab]. Even [submitting an issue](#submit-issue) to our [GitLab Repository][gitlab]. Even
better, you can [submit a Merge Request](#submit-pr) with a fix. better, you can [submit a Merge Request](#submit-pr) with a fix.
## <a name="feature"></a> Missing a Feature? ## <a name="feature"></a> Missing a Feature?
You can *request* a new feature by [submitting an issue](#submit-issue) to our You can _request_ a new feature by [submitting an issue](#submit-issue) to our
GitLab Repository. If you would like to *implement* a new feature, please ensure GitLab Repository. If you would like to _implement_ a new feature, please ensure
an issue already exists to be associated with your commits. an issue already exists to be associated with your commits.
* For any **contribution**, first [open an issue](#submit-issue) and outline your proposal so that it can be - For any **contribution**, first [open an issue](#submit-issue) and outline your proposal so that it can be
discussed. This will also allow us to better coordinate our efforts, prevent duplication of work, discussed. This will also allow us to better coordinate our efforts, prevent duplication of work,
and help you to craft the change so that it is successfully accepted into the project. and help you to craft the change so that it is successfully accepted into the project.
## <a name="submit"></a> Submission Guidelines ## <a name="submit"></a> Submission Guidelines
### <a name="submit-issue"></a> Submitting an Issue ### <a name="submit-issue"></a> Submitting an Issue
Before you submit an issue, please search through open issues, maybe an issue for Before you submit an issue, please search through open issues, maybe an issue for
your problem already exists and the discussion might inform you of workarounds your problem already exists and the discussion might inform you of workarounds
readily available. readily available.
We want to fix all the issues as soon as possible, but before fixing a bug we We want to fix all the issues as soon as possible, but before fixing a bug we
need to reproduce and confirm it. In order to reproduce bugs we may need to reproduce and confirm it. In order to reproduce bugs we may
ask you to describe a use-case that fails to assist in the debugging process. ask you to describe a use-case that fails to assist in the debugging process.
In GitLab there are issue templates that you can use which paste in a sample In GitLab there are issue templates that you can use which paste in a sample
format for you to use. format for you to use.
Check out the following issue for an example: [https://git.gmu.edu/srct/whats-open/issues/31](https://git.gmu.edu/srct/whats-open/issues/31) Check out the following issue for an example: [https://git.gmu.edu/srct/whats-open/issues/31](https://git.gmu.edu/srct/whats-open/issues/31)
...@@ -63,97 +63,99 @@ You can file new issues by filling out our [new issue form][new-issue]. ...@@ -63,97 +63,99 @@ You can file new issues by filling out our [new issue form][new-issue].
Before you submit your Merge Request (MR) consider the following steps: Before you submit your Merge Request (MR) consider the following steps:
* Search [GitLab][merge-request] for an open or closed MR that relates to your - Search [GitLab][merge-request] for an open or closed MR that relates to your
submission. You don't want to duplicate effort. submission. You don't want to duplicate effort.
* Pull the latest commits from GitLab - Pull the latest commits from GitLab
```sh ```sh
git pull git pull
``` ```
* Check into the current development branch: - Check into the current development branch:
All new commits are merged into this development branch before going live on All new commits are merged into this development branch before going live on
the site in a tagged release (merge into master branch). the site in a tagged release (merge into master branch).
```sh
git checkout consolidation
```
* Create a new git branch: ```sh
git checkout consolidation
```
```sh - Create a new git branch:
git checkout -B ##-shortdescription
# Example
git checkout -B 31-contibution-guidelines-proposal
```
All branches need to follow the above convention (`##-shortdescription`) `##` ```sh
in this case represents the issue number that your branch is related to. Each git checkout -B ##-shortdescription
issue has one and only one branch and each branch has one and only one purpose: # Example
to add, modify, or remove a feature/bug from the repo. `shortdescription` is git checkout -B 31-contibution-guidelines-proposal
a few hyphon (`-`) seperated words that consisely describe the branch. This helps people ```
who may be unfamiliar with the issue number to know at a glance what the branch
* Now you're ready to write your code in your new branch! Make sure to follow
listed [style](#rules) & [commit](#commit) guidelines/rules when contributing
code.
* Unit tests are run at the CI (GitLab-CI) level once you push your code to GitLab.
We do this to ensure that the project builds properly and passes tests. In general,
if you are adding some new piece of code like a function you must **include
appropriate test cases**.
For example if I compose the following function:
```python
# file.py
def oneplus(num):
return num + 1
```
then I would additionally write the following test case: All branches need to follow the above convention (`##-shortdescription`) `##`
in this case represents the issue number that your branch is related to. Each
```python issue has one and only one branch and each branch has one and only one purpose:
# test_file.py to add, modify, or remove a feature/bug from the repo. `shortdescription` is
def TestOneplus(TestCase): a few hyphon (`-`) seperated words that consisely describe the branch. This helps people
assertEquals(oneplus(1), 2) who may be unfamiliar with the issue number to know at a glance what the branch
```
* Before you push your code to GitLab it is suggested that you run all unit tests locally.
```sh
python manage.py test
```
* Commit your changes using a descriptive commit message that follows our - Now you're ready to write your code in your new branch! Make sure to follow
[commit message conventions](#commit). Adherence to these conventions is strongly listed [style](#rules) & [commit](#commit) guidelines/rules when contributing
suggested as it makes it easier to determine what each commit does when, for example, code.
things break.
```sh - Unit tests are run at the CI (GitLab-CI) level once you push your code to GitLab.
git add --all We do this to ensure that the project builds properly and passes tests. In general,
git commit # first line is title, two newlines is description if you are adding some new piece of code like a function you must **include
``` appropriate test cases**.
* You will need to ask in the slack channel to be added to the GitLab repo. This For example if I compose the following function:
step is necessary such that you have the necessary permissions to push up your
branch.
* Push your branch to GitLab: ```python
# file.py
def oneplus(num):
return num + 1
```
```sh then I would additionally write the following test case:
git push origin ##-shortdescription
# ex. ```python
git push origin 31-contibution-guidelines-proposal # test_file.py
``` def TestOneplus(TestCase):
assertEquals(oneplus(1), 2)
```
- Before you push your code to GitLab it is suggested that you run all unit tests locally.
```sh
python manage.py test
```
- Commit your changes using a descriptive commit message that follows our
[commit message conventions](#commit). Adherence to these conventions is strongly
suggested as it makes it easier to determine what each commit does when, for example,
things break.
```sh
git add --all
git commit # first line is title, two newlines is description
```
* In GitLab, send a merge request to the current development branch. - You will need to ask in the slack channel to be added to the GitLab repo. This
step is necessary such that you have the necessary permissions to push up your
branch.
* If we suggest changes to your branch then: - Push your branch to GitLab:
* Make the required updates.
* Re-run the unit tests to ensure tests are still passing. ```sh
* Rebase your branch and force push to your GitLab repository (this will update git push origin ##-shortdescription
# ex.
git push origin 31-contibution-guidelines-proposal
```
- In GitLab, send a merge request to the current development branch.
- If we suggest changes to your branch then:
- Make the required updates.
- Re-run the unit tests to ensure tests are still passing.
- Rebase your branch and force push to your GitLab repository (this will update
your Merge Request): your Merge Request):
```sh ```sh
...@@ -165,45 +167,45 @@ That's it! Thank you for your contribution! :tada: ...@@ -165,45 +167,45 @@ That's it! Thank you for your contribution! :tada:
#### After your merge request is merged #### After your merge request is merged
After your merge request is merged, you can safely delete your branch and merge After your merge request is merged, you can safely delete your branch and merge
the changes from the main (upstream) repository: the changes from the main (upstream) repository:
* Delete the remote branch on GitLab either through the GitLab web UI or your - Delete the remote branch on GitLab either through the GitLab web UI or your
local shell as follows: local shell as follows:
```sh ```sh
git push origin --delete ##-shortdescription git push origin --delete ##-shortdescription
# ex. # ex.
git push origin --delete 31-contibution-guidelines-proposal git push origin --delete 31-contibution-guidelines-proposal
``` ```
* Check out the current development branch: - Check out the current development branch:
```sh ```sh
git checkout consolidation -f git checkout consolidation -f
``` ```
* Delete the local branch: - Delete the local branch:
```sh ```sh
git branch -D ##-shortdescription git branch -D ##-shortdescription
# ex. # ex.
git branch -D 31-contibution-guidelines-proposal git branch -D 31-contibution-guidelines-proposal
``` ```
* Update your current development branch with the latest upstream version: - Update your current development branch with the latest upstream version:
```sh ```sh
git l --ff upstream consolidation git l --ff upstream consolidation
``` ```
## <a name="rules"></a> Coding Rules ## <a name="rules"></a> Coding Rules
To ensure consistency throughout the source code, keep these rules in mind as you To ensure consistency throughout the source code, keep these rules in mind as you
are working: are working:
* All features or bug fixes **must be tested** by one or more specs (unit-tests). - All features or bug fixes **must be tested** by one or more specs (unit-tests).
* We follow [the PEP8 styleguide][style-guide]. - We follow [the PEP8 styleguide][style-guide].
## <a name="commit"></a> Commit Message Guidelines ## <a name="commit"></a> Commit Message Guidelines
...@@ -212,7 +214,7 @@ history**. ...@@ -212,7 +214,7 @@ history**.
### Commit Message Format ### Commit Message Format
Each commit message consists of a **header**, a **body** and a **footer**. The Each commit message consists of a **header**, a **body** and a **footer**. The
header has a special format that includes a **type** and a **subject**. The **header** header has a special format that includes a **type** and a **subject**. The **header**
is mandatory. is mandatory.
...@@ -226,29 +228,31 @@ Layout: ...@@ -226,29 +228,31 @@ Layout:
<footer> <footer>
``` ```
Sample headers: Sample headers:
``` ```
docs: update change log to beta.5 docs: update change log to beta.5
``` ```
``` ```
fix: need to depend on latest rxjs and zone.js fix: need to depend on latest rxjs and zone.js
``` ```
### \<header> Type ### \<header> Type
Must be one of the following: Must be one of the following:
* **build**: Changes that affect the build system or external dependencies - **build**: Changes that affect the build system or external dependencies
(example scopes: gulp, broccoli, npm) (example scopes: gulp, broccoli, npm)
* **ci**: Changes to our gitlab-ci configuration files and scripts - **ci**: Changes to our gitlab-ci configuration files and scripts
* **docs**: Documentation only changes - **docs**: Documentation only changes
* **feat**: A new feature - **feat**: A new feature
* **fix**: A bug fix - **fix**: A bug fix
* **perf**: A code change that improves performance - **perf**: A code change that improves performance
* **refactor**: A code change that neither fixes a bug nor adds a feature - **refactor**: A code change that neither fixes a bug nor adds a feature
* **style**: Changes that do not affect the meaning of the code (white-space, formatting, - **style**: Changes that do not affect the meaning of the code (white-space, formatting,
etc.) etc.)
* **test**: Adding missing tests or correcting existing tests - **test**: Adding missing tests or correcting existing tests
### \<header> Subject ### \<header> Subject
...@@ -274,20 +278,22 @@ Sample Body: ...@@ -274,20 +278,22 @@ Sample Body:
### Footer ### Footer
The footer should contain any information about **Breaking Changes** (**Breaking The footer should contain any information about **Breaking Changes** (**Breaking
Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines. Changes** should start with the word `BREAKING CHANGE:` with a space or two newlines.
The rest of the commit message is then used for this. and is also the place to The rest of the commit message is then used for this. and is also the place to
reference GitLab issues that this commit **Closes**. reference GitLab issues that this commit **Closes**.
Sample footers: Sample footers:
``` ```
BREAKING CHANGE: remove outdated dependency from requirements.txt. be sure to BREAKING CHANGE: remove outdated dependency from requirements.txt. be sure to
reinstall your packages in order for the project to build. reinstall your packages in order for the project to build.
``` ```
``` ```
Closes #31 Closes #31
``` ```
This "Closes" statement should only be incuded in commits that resolve an issue. This "Closes" statement should only be incuded in commits that resolve an issue.
What's nice about the statement itself is that when the commit is merged, the issue What's nice about the statement itself is that when the commit is merged, the issue
will auto close. will auto close.
...@@ -298,6 +304,6 @@ then feel free to omit the footer. ...@@ -298,6 +304,6 @@ then feel free to omit the footer.
[coc]: https://studentconduct.gmu.edu/wp-content/uploads/2011/09/2016-17-Code-of-Student-Conduct.pdf [coc]: https://studentconduct.gmu.edu/wp-content/uploads/2011/09/2016-17-Code-of-Student-Conduct.pdf
[gitlab]: https://git.gmu.edu/srct/whats-open [gitlab]: https://git.gmu.edu/srct/whats-open
[style-guide]: https://www.python.org/dev/peps/pep-0008/ [style-guide]: https://www.python.org/dev/peps/pep-0008/
[slack]:https://srct.slack.com/ [slack]: https://srct.slack.com/
[new-issue]:https://git.gmu.edu/srct/whats-open/issues/new [new-issue]: https://git.gmu.edu/srct/whats-open/issues/new
[merge-request]:https://git.gmu.edu/srct/whats-open/merge_requests [merge-request]: https://git.gmu.edu/srct/whats-open/merge_requests
...@@ -3,7 +3,7 @@ ...@@ -3,7 +3,7 @@
############################################################ ############################################################
# Set the base image to Ubuntu # Set the base image to Ubuntu
FROM python:3.6 FROM python:3.7
ENV PYTHONUNBUFFERED 1 ENV PYTHONUNBUFFERED 1
# Update the sources list and install all packages # Update the sources list and install all packages
...@@ -23,4 +23,5 @@ WORKDIR /whats-open/ ...@@ -23,4 +23,5 @@ WORKDIR /whats-open/
ADD . /whats-open/ ADD . /whats-open/
# Pip install all required dependecies # Pip install all required dependecies
RUN pip install -r /whats-open/requirements/base.txt RUN pip install pipenv
RUN pipenv install --system --deploy
\ No newline at end of file
[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true
[dev-packages]
black = "*"
pylint = "*"
pylint-django = "*"
[packages]
django-autoslug-iplweb = "*"
django-cas-client = "==1.3.0"
djangorestframework = "==3.7.7"
django-model-utils = "==3.0.0"
mysqlclient = "==1.3.12"
django-taggit = "==0.22.2"
django-taggit-serializer = "==0.1.5"
djangorestframework-gis = "==0.12.0"
django-filter = "==1.0.4"
django-crispy-forms = "==1.7.0"
coreapi = "==2.3.3"
urllib3 = "==1.22"
docutils = "==0.13.1"
gunicorn = "*"
Django = "<2.1,>=2.0"
Markdown = "==2.6.10"
[requires]
python_version = "3.7"
[pipenv]
allow_prereleases = true
{
"_meta": {
"hash": {
"sha256": "465820099b95b54e0ceaa9975f59da0a88605cb2dc3edb3630d513d8afb550ba"
},
"pipfile-spec": 6,
"requires": {
"python_version": "3.7"
},
"sources": [
{
"name": "pypi",
"url": "https://pypi.org/simple",
"verify_ssl": true
}
]
},
"default": {
"certifi": {
"hashes": [
"sha256:47f9c83ef4c0c621eaef743f133f09fa8a74a9b75f037e8624f83bd1b6626cb7",
"sha256:993f830721089fef441cdfeb4b2c8c9df86f0c63239f06bd025a76a7daddb033"
],
"version":