Permalink
Browse files

Bumping version to v2.4.1

  • Loading branch information...
pbanaszkiewicz committed Jan 20, 2019
2 parents 9bff40b + 18eab30 commit 6cf99ba9b1c9a0c2167a5a922ea8d43e728d7c9a
@@ -1,4 +1,5 @@
sudo: false
dist: xenial
sudo: required

language: python

@@ -7,7 +8,7 @@ cache: pip
python:
- 3.5
- 3.6
- "3.7-dev"
- 3.7

env:
- AMY_ENABLE_PYDATA=true
@@ -58,7 +58,7 @@ node_modules : package.json
touch node_modules

## git_version : store details about the current commit and tree state.
workshops/git_version.py :
amy/workshops/git_version.py :
@if test -d .git; \
then \
git log -1 --date=short --format="HASH = '%H'%nSHORT_HASH = '%h'%nDATE = '%cd'%n" >$@; \
@@ -100,3 +100,12 @@ clean :
coverage :
coverage --source=amy manage.py test
coverage html

## bumpversion : bump version strings in various files, expected envvars CURRENT, NEXT
bumpversion :
@if [ "${CURRENT}" -a "$(NEXT)" ]; \
then \
echo "Bumping version $(CURRENT) to $(NEXT)"; \
sed -i "s/$(CURRENT)/$(NEXT)/" amy/workshops/__init__.py ; \
sed -i "s/$(CURRENT)/$(NEXT)/" package.json ; \
fi
@@ -1,3 +1,4 @@
from django.conf import settings
from django.urls import reverse

from extrequests.forms import WorkshopRequestBaseForm
@@ -405,3 +406,22 @@ def test_accepted_request_reopened(self):
follow=True)
self.wr2.refresh_from_db()
self.assertEqual(self.wr2.state, "p")

def test_list_no_comments(self):
"""Regression for #1435: missing "comment" field displayed on "all
workshops" page.
https://github.com/swcarpentry/amy/issues/1435
"""

# make sure the `string_if_invalid` is not empty
self.assertTrue(settings.TEMPLATES[0]['OPTIONS']['string_if_invalid'])

rv = self.client.get(reverse('all_workshoprequests'))

# some objects available in the page
self.assertNotEqual(len(rv.context['requests']), 0)

# no string_if_invalid found in the page
invalid = settings.TEMPLATES[0]['OPTIONS']['string_if_invalid']
self.assertNotIn(invalid, rv.content.decode('utf-8'))
@@ -92,16 +92,6 @@ class Meta:
'additional_instructor_training_seats',
]

def save(self, *args, **kwargs):
res = super().save(*args, **kwargs)

create_comment_signal.send(sender=self.__class__,
content_object=res,
comment=self.cleaned_data['comment'],
timestamp=None)

return res


class MembershipCreateForm(MembershipForm):
comment = MarkdownxFormField(
@@ -116,6 +106,16 @@ class Meta(MembershipForm.Meta):
fields = MembershipForm.Meta.fields.copy()
fields.append('comment')

def save(self, *args, **kwargs):
res = super().save(*args, **kwargs)

create_comment_signal.send(sender=self.__class__,
content_object=res,
comment=self.cleaned_data['comment'],
timestamp=None)

return res


class SponsorshipForm(WidgetOverrideMixin, forms.ModelForm):

@@ -4,7 +4,7 @@
from django.urls import reverse
from django_comments.models import Comment

from fiscal.forms import MembershipCreateForm
from fiscal.forms import MembershipCreateForm, MembershipForm
from workshops.tests.base import TestBase
from workshops.models import Membership, Organization, Event, Role, Tag, Task

@@ -210,3 +210,23 @@ def test_creating_event_with_comment(self):
comment = Comment.objects.first()
self.assertEqual(comment.comment, 'This is a test comment.')
self.assertIn(comment, Comment.objects.for_model(obj))

def test_workshop_edit_form_no_comment(self):
"""Ensure workshop edit form works and doesn't provide `comment` field.
This is a regression test against #1437:
https://github.com/swcarpentry/amy/issues/1437
"""
self.assertNotIn('comment', MembershipForm.Meta.fields)

self.assertEqual(Comment.objects.count(), 0)
data = {
'organization': self.org_alpha.pk,
'variant': 'partner',
'contribution_type': 'financial',
'additional_instructor_training_seats': 0,
'seats_instructor_training': 0,
}
form = MembershipForm(data, instance=self.current)
form.save()
self.assertEqual(Comment.objects.count(), 0)
@@ -19,7 +19,6 @@
data-toggle="popover" data-html="true"
data-content="<span class='badge badge-warning'>Pending</span> <span class='badge badge-danger'>Discarded</span> <span class='badge badge-success'>Accepted</span>"></i>
</th>
<th>Comment</th>
<th class="additional-links"></th>
</tr>
{% for req in requests %}
@@ -46,7 +45,6 @@
{{ req.get_state_display }}
</span>
</td>
<td>{{ req.comment|truncatewords:5|default:"—" }}</td>
<td><a href="{{ req.get_absolute_url }}"><i class="fas fa-info-circle"></i></a></td>
</tr>
{% endfor %}
@@ -1 +1 @@
__version__ = 'v2.4.0'
__version__ = 'v2.4.1'
@@ -6,12 +6,14 @@
Release notes should have two sections: new features and bugfixes, each one enumerating changes and mentioning their authors.
Base your work on the list of all closed pull requests for given milestone, available on GitHub.

3. Follow Release Procedure (see below).
3. Follow [Release Procedure](#release-procedure).

4. Follow Deployment Procedure (see below).
4. Follow Deployment Procedure (either
[manual method](#deployment-procedure---manual-method) or using
[Ansible Playbook](#deployment-procedure-using-ansible)).

5. Write to <amy@lists.carpentries.org> mailing list.
The suggested subject of the new thread is "[Amy] New release v2.X.Y".
The suggested subject of the new thread is "[AMY] New release v2.X.Y".

# Release Procedure

@@ -44,23 +46,23 @@ Execute the following commands on your local machine, not production.
$ git pull upstream master
$ git push origin master

Pushes to your `origin` repository are optional.
Pushes to your `origin` remote are optional.

4. Define which version you're going to release (replace X and Y with correct numbers):

$ AMY_CURRENT=v2.X.Y-dev # this needs to correspond to what you have in amy/workshops/__init__.py and package.json
$ AMY_VERSION=v2.X.Y
$ AMY_NEXT_VERSION=v2.X+1.0-dev

5. Merge `develop` into `master` branch:
5. Merge `develop` into `master` branch (be careful, as there are sometimes conflicts that need to be manually resolved):

$ git checkout master
$ git merge --no-ff develop # sometimes there are conflicts in files with release version, but most often we need to edit them and commit
$ git merge --no-ff develop

6. Bump version on `master`:

$ echo "__version__ = '$AMY_VERSION'" > workshops/__init__.py # change version to 2.X.Y
$ vim package.json # change version to $AMY_VERSION
$ git add workshops/__init__.py package.json
$ make bumpversion CURRENT=$AMY_CURRENT NEXT=$AMY_VERSION
$ git add amy/workshops/__init__.py package.json
$ git commit -m "Bumping version to $AMY_VERSION"

7. Just to be safe, run tests:
@@ -82,23 +84,25 @@ Execute the following commands on your local machine, not production.
10. Bump version on `develop`:

$ git checkout develop
$ echo "__version__ = '$AMY_NEXT_VERSION'" > workshops/__init__.py # change version to 2.X+1.0
$ vim package.json # change version to $AMY_NEXT_VERSION
$ git add workshops/__init__.py package.json
$ make bumpversion CURRENT=$AMY_CURRENT NEXT=$AMY_NEXT_VERSION
$ git add amy/workshops/__init__.py package.json
$ git commit -m "Bumping version to $AMY_NEXT_VERSION"

Skip this step if you're releasing minor AMY version (that is, when you increment Y, not X).
Skip this step if development version doesn't change, for example during
minor version development cycle (`v2.X.0-dev`) you're releasing a patch
(`v2.X-1.Y`).

11. And push it everywhere:

$ git push upstream develop
$ git push origin develop

# Deployment Procedure

# Deployment Procedure - manual method

1. Log into production:

$ ssh amy@amy.software-carpentry.org
$ ssh amy@amy.carpentries.org

All the following commands will be executed on production, not your local machine.

@@ -124,11 +128,12 @@ Execute the following commands on your local machine, not production.

6. Go to [admin dashboard](https://amy.software-carpentry.org/workshops/admin-dashboard/) and make sure that maintenance page is displayed.

7. Create local database backup:
7. Create a compressed local database backup (through special backup function in SQLite client):

$ cp db.sqlite3 backup-before-upgrade-to-v2.X.Y.sqlite3
$ sqlite3 db.sqlite3 ".backup DB_backups/backup-before-upgrade-to-v2.X.Y.sqlite3"
$ gzip DB_backups/backup-before-upgrade-to-v2.X.Y.sqlite3

Do not use $AMY_VERSION environment variable because it's not defined here.
Do not use `$AMY_VERSION` environment variable because it's not defined here.

8. Fetch newer AMY source code:

@@ -141,8 +146,8 @@ Execute the following commands on your local machine, not production.

10. Test migrations:

$ cp db.sqlite3 migration-test.sqlite3
$ AMY_DB_FILENAME=migration-test.sqlite3 ./manage.py migrate
$ sqlite3 db.sqlite3 ".backup migration-test.sqlite3"
$ DATABASE_URL=sqlite:///migration-test.sqlite3 ./manage.py migrate
$ rm migration-test.sqlite3

11. Migrate production database (`db.sqlite3`):
@@ -151,9 +156,7 @@ Execute the following commands on your local machine, not production.

12. Regenerate version number in the footer:

$ make serve

This launches local server on 8000 port. Quit it with Ctrl+C.
$ make amy/workshops/git_version.py

13. Update static files:

@@ -173,3 +176,57 @@ Execute the following commands on your local machine, not production.
17. Log out production:

$ exit


# Deployment procedure using Ansible

If you have access to Ansible playbook files for AMY, you can automate
deployment.

**CAUTION:** only use this method if you don't have to invoke any custom
methods when the server is off for upgrade.

1. Ensure you have `ansible-playbook` command available:

$ ansible-playbook --version

2. Create an inventory file `production` containing production server address:

[all:vars]
env=production

[webservers]
amy.carpentries.org

The first group `all:vars` sets `production` variable group. You can
further tweak them in `env_vars/production.yml`.

3. Set correct git tag in `env_vars/production.yml`:

...
#===> Git settings only for production
fetch_git_tag: yes
git_tag: tags/v2.4.0
...

Replace `v2.4.0` with the version you want to fetch (e.g. `v2.5.0`).

4. Review other variables in `env_vars/production.yml` and update them if
required.

5. Make sure your public SSH key is added to the `~/.ssh/authorized_keys` file
on destination server `amy.carpentries.org`.

6. Optional: test provisioning on a local Vagrant machine

$ vagrant up --provision

7. Run Ansible provisioning:

$ ansible-playbook --inventory=production --user=amy -vv

The last switch `-vv` enables verbosity, which helps in debugging if errors
occur.

8. Check production website - it should be running, and there should be a
version number (e.g. `v2.5.0`) in the footer.
@@ -1,6 +1,6 @@
{
"name": "AMY",
"version": "2.4.0",
"version": "v2.4.1",
"description": "A web-based workshop administration application for The Carpentries",
"main": "index.js",
"repository": "git@github.com:swcarpentry/amy.git",

0 comments on commit 6cf99ba

Please sign in to comment.