Skip to content

GitLab

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

Dear lord I haven't touched this in a year and everything is WRONG

parent 1a8dda9c
Pipeline #3710 failed with stage
in 55 seconds
Hide whitespace changes
Inline Side-by-side
Showing with 1055 additions and 457 deletions
.gitignore
View file @ cb93750f
......@@ -13,5 +13,4 @@ whats_open/secret_key.py
whats_open/assets/
static/admin/
data
whats-open/api/migrations
.vscode
.gitlab-ci.yml
View file @ cb93750f
......@@ -34,14 +34,4 @@ whats-open-py3.5:
image: library/python:3.5
type: test
script:
- python manage.py test
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;}'
- echo "Done 😄"
CHANGELOG.md
View file @ cb93750f
......@@ -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
[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
\ No newline at end of file
[2.1.1]: https://git.gmu.edu/srct/whats-open/compare/2.1...2.1.1
CONTRIBUTING.md
View file @ cb93750f
# 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
follow:
- [Code of Conduct](#coc)
- [Question or Problem?](#question)
- [Issues and Bugs](#issue)
- [Feature Requests](#feature)
- [Submission Guidelines](#submit)
- [Coding Rules](#rules)
- [Commit Message Guidelines](#commit)
- [Code of Conduct](#coc)
- [Question or Problem?](#question)
- [Issues and Bugs](#issue)
- [Feature Requests](#feature)
- [Submission Guidelines](#submit)
- [Coding Rules](#rules)
- [Commit Message Guidelines](#commit)
## <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].
## <a name="question"></a> Got a Question or Problem?
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
chances of getting your question answered on [Slack Group][slack] where
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
chances of getting your question answered on [Slack Group][slack] where
questions should be asked in their respective channels.
## <a name="issue"></a> Found a Bug?
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.
## <a name="feature"></a> Missing a Feature?
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
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
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
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.
- 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,
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-issue"></a> Submitting an Issue
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
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
readily available.
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
ask you to describe a use-case that fails to assist in the debugging process.
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
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.
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].
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
submission. You don't want to duplicate effort.
- Search [GitLab][merge-request] for an open or closed MR that relates to your
submission. You don't want to duplicate effort.
* Pull the latest commits from GitLab
- Pull the latest commits from GitLab
```sh
git pull
```
```sh
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
the site in a tagged release (merge into master branch).
```sh
git checkout consolidation
```
All new commits are merged into this development branch before going live on
the site in a tagged release (merge into master branch).
* Create a new git branch:
```sh
git checkout consolidation
```
```sh
git checkout -B ##-shortdescription
# Example
git checkout -B 31-contibution-guidelines-proposal
```
- Create a new git branch:
All branches need to follow the above convention (`##-shortdescription`) `##`
in this case represents the issue number that your branch is related to. Each
issue has one and only one branch and each branch has one and only one purpose:
to add, modify, or remove a feature/bug from the repo. `shortdescription` is
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
```
```sh
git checkout -B ##-shortdescription
# Example
git checkout -B 31-contibution-guidelines-proposal
```
then I would additionally write the following test case:
```python
# 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
```
All branches need to follow the above convention (`##-shortdescription`) `##`
in this case represents the issue number that your branch is related to. Each
issue has one and only one branch and each branch has one and only one purpose:
to add, modify, or remove a feature/bug from the repo. `shortdescription` is
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
* 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.
- 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.
```sh
git add --all
git commit # first line is title, two newlines is description
```
- 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**.
* 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.
For example if I compose the following function:
* Push your branch to GitLab:
```python
# file.py
def oneplus(num):
return num + 1
```
```sh
git push origin ##-shortdescription
# ex.
git push origin 31-contibution-guidelines-proposal
```
then I would additionally write the following test case:
```python
# 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:
* 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
- Push your branch to GitLab:
```sh
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):
```sh
......@@ -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, 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:
* Delete the remote branch on GitLab either through the GitLab web UI or your
local shell as follows:
- Delete the remote branch on GitLab either through the GitLab web UI or your
local shell as follows:
```sh
git push origin --delete ##-shortdescription
# ex.
git push origin --delete 31-contibution-guidelines-proposal
```
```sh
git push origin --delete ##-shortdescription
# ex.
git push origin --delete 31-contibution-guidelines-proposal
```
* Check out the current development branch:
- Check out the current development branch:
```sh
git checkout consolidation -f
```
```sh
git checkout consolidation -f
```
* Delete the local branch:
- Delete the local branch:
```sh
git branch -D ##-shortdescription
# ex.
git branch -D 31-contibution-guidelines-proposal
```
```sh
git branch -D ##-shortdescription
# ex.
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
git l --ff upstream consolidation
```
```sh
git l --ff upstream consolidation
```
## <a name="rules"></a> Coding Rules
To ensure consistency throughout the source code, keep these rules in mind as you
are working:
* All features or bug fixes **must be tested** by one or more specs (unit-tests).
* We follow [the PEP8 styleguide][style-guide].
- All features or bug fixes **must be tested** by one or more specs (unit-tests).
- We follow [the PEP8 styleguide][style-guide].
## <a name="commit"></a> Commit Message Guidelines
......@@ -212,7 +214,7 @@ history**.
### 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**
is mandatory.
......@@ -226,29 +228,31 @@ Layout:
<footer>
```
Sample headers:
Sample headers:
```
docs: update change log to beta.5
```
```
fix: need to depend on latest rxjs and zone.js
```
### \<header> Type
Must be one of the following:
* **build**: Changes that affect the build system or external dependencies
(example scopes: gulp, broccoli, npm)
* **ci**: Changes to our gitlab-ci configuration files and scripts
* **docs**: Documentation only changes
* **feat**: A new feature
* **fix**: A bug fix
* **perf**: A code change that improves performance
* **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,
etc.)
* **test**: Adding missing tests or correcting existing tests
- **build**: Changes that affect the build system or external dependencies
(example scopes: gulp, broccoli, npm)
- **ci**: Changes to our gitlab-ci configuration files and scripts
- **docs**: Documentation only changes
- **feat**: A new feature
- **fix**: A bug fix
- **perf**: A code change that improves performance
- **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,
etc.)
- **test**: Adding missing tests or correcting existing tests
### \<header> Subject
......@@ -274,20 +278,22 @@ Sample Body:
### 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.
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**.
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.
```
```
Closes #31
```
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
will auto close.
......@@ -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
[gitlab]: https://git.gmu.edu/srct/whats-open
[style-guide]: https://www.python.org/dev/peps/pep-0008/
[slack]:https://srct.slack.com/
[new-issue]:https://git.gmu.edu/srct/whats-open/issues/new
[merge-request]:https://git.gmu.edu/srct/whats-open/merge_requests
[slack]: https://srct.slack.com/
[new-issue]: https://git.gmu.edu/srct/whats-open/issues/new
[merge-request]: https://git.gmu.edu/srct/whats-open/merge_requests
Dockerfile
View file @ cb93750f
......@@ -3,7 +3,7 @@
############################################################
# Set the base image to Ubuntu
FROM python:3.6
FROM python:3.7
ENV PYTHONUNBUFFERED 1
# Update the sources list and install all packages
......@@ -23,4 +23,5 @@ WORKDIR /whats-open/
ADD . /whats-open/
# 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
Pipfile 0 → 100644
View file @ cb93750f
[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true
[dev-packages]
black = "*"
[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"
black = "*"
pylint = "*"
pylint-django = "*"
[requires]
python_version = "3.7"
[pipenv]
allow_prereleases = true
Pipfile.lock 0 → 100644
View file @ cb93750f
{
"_meta": {
"hash": {
"sha256": "3a53c49130f008bea5c55acccafcfe7bedeeae2b85fa700f7debe8f0246a991a"
},
"pipfile-spec": 6,
"requires": {
"python_version": "3.7"
},
"sources": [
{
"name": "pypi",
"url": "https://pypi.org/simple",
"verify_ssl": true
}
]
},
"default": {
"appdirs": {
"hashes": [
"sha256:9e5896d1372858f8dd3344faf4e5014d21849c756c8d5701f78f8a103b372d92",
"sha256:d8b24664561d0d34ddfaec54636d502d7cea6e29c3eaf68f3df6180863e2166e"
],
"version": "==1.4.3"
},
"astroid": {
"hashes": [
"sha256:7f5a9f32ba7acd09c3c437946a9fc779494fc4dc6110958fe440dda30ffa4db0",
"sha256:dd357d91d582bc775ad635ac6c35e0a5d305678650df23bd6b20138429b9765d"
],
"version": "==2.2.0.dev0"
},
"attrs": {
"hashes": [
"sha256:10cbf6e27dbce8c30807caf056c8eb50917e0eaafe86347671b57254006c3e69",
"sha256:ca4be454458f9dec299268d472aaa5a11f67a4ff70093396e1ceae9c76cf4bbb"
],
"version": "==18.2.0"
},
"black": {
"hashes": [
"sha256:817243426042db1d36617910df579a54f1afd659adb96fc5032fcf4b36209739",
"sha256:e030a9a28f542debc08acceb273f228ac422798e5215ba2a791a6ddeaaca22a5"
],
"index": "pypi",
"version": "==18.9b0"
},
"certifi": {
"hashes": [
"sha256:47f9c83ef4c0c621eaef743f133f09fa8a74a9b75f037e8624f83bd1b6626cb7",
"sha256:993f830721089fef441cdfeb4b2c8c9df86f0c63239f06bd025a76a7daddb033"
],
"version": "==2018.11.29"
},
"chardet": {
"hashes": [
"sha256:84ab92ed1c4d4f16916e05906b6b75a6c0fb5db821cc65e70cbd64a3e2a5eaae",
"sha256:fc323ffcaeaed0e0a02bf4d117757b98aed530d9ed4531e3e15460124c106691"
],
"version": "==3.0.4"
},
"click": {
"hashes": [
"sha256:2335065e6395b9e67ca716de5f7526736bfa6ceead690adf616d925bdc622b13",
"sha256:5b94b49521f6456670fdb30cd82a4eca9412788a93fa6dd6df72c94d5a8ff2d7"
],
"version": "==7.0"
},
"coreapi": {
"hashes": [
"sha256:46145fcc1f7017c076a2ef684969b641d18a2991051fddec9458ad3f78ffc1cb",
"sha256:bf39d118d6d3e171f10df9ede5666f63ad80bba9a29a8ec17726a66cf52ee6f3"
],
"index": "pypi",
"version": "==2.3.3"
},
"coreschema": {
"hashes": [
"sha256:5e6ef7bf38c1525d5e55a895934ab4273548629f16aed5c0a6caa74ebf45551f",
"sha256:9503506007d482ab0867ba14724b93c18a33b22b6d19fb419ef2d239dd4a1607"
],
"version": "==0.0.4"
},
"django": {
"hashes": [
"sha256:0292a7ad7d8ffc9cfc6a77f043d2e81f5bbc360c0c4a1686e130ef3432437d23",
"sha256:e89f613e3c1f7ff245ffee3560472f9fa9c07060b11f65e1de3cb763f8dcd4b9"
],
"index": "pypi",
"version": "==2.0.10"
},
"django-autoslug-iplweb": {
"hashes": [
"sha256:6ddec119072067e78cbdb53f7ba11ae8bee5a2f2f0fe1d90c6a4d3c0a91489d3",
"sha256:8a3ba49b18f082e29ac9cb17884d4b2149ad14988bd89e118b1c5ddf94fdea8e"
],
"index": "pypi",
"version": "==1.9.4"
},
"django-cas-client": {
"hashes": [
"sha256:48add68bf5c7f94cd0c4a43dd8a954696438c7bc707a1f5d84e8c5b397478bc1",
"sha256:890536d712d3b3425e2c09e8fe07344fbcfb6e0832ae512b1a37224333d07d5f"
],
"index": "pypi",
"version": "==1.3.0"
},
"django-crispy-forms": {
"hashes": [
"sha256:b29a9a671194e3a482891f319f69da81e30ae81c075f6e37adb14a83ba2c409b",
"sha256:d37fe72eb550b41ba651c06293fb861d5a9e6e3ada23304718858cd6250d258d"
],
"index": "pypi",
"version": "==1.7.0"
},
"django-filter": {
"hashes": [
"sha256:6ef1611aeacfda8f13a075a992ff65687afbd5cc8fcb0f3f1563a9ad4fe2d1b0",
"sha256:e44620d4e707beaff7396ac8df765dc015a07467df813b9c1663fe4017934b58"
],
"index": "pypi",
"version": "==1.0.4"
},
"django-model-utils": {
"hashes": [
"sha256:60ead1ba50e1353f38bde12ab8b4a80b6a0f825a8e53c348fe259548cbd1a312"
],
"index": "pypi",
"version": "==3.0.0"
},
"django-taggit": {
"hashes": [
"sha256:58aa3e59e0643446e102523f22d137300298e2a537b1c5b0c310d99143f2c2b8",
"sha256:fd13e304ba37ff09e601c4797d893fb7d3e699a789b5afb0b09d686f94470441"
],
"index": "pypi",
"version": "==0.22.2"
},
"django-taggit-serializer": {
"hashes": [
"sha256:258fbf13354c00a19e00ea8c1829458e644be7b52cfd9cf39b90fe2ccf813ed5"