Skip to content

Commit

Permalink
Release/0.0.1 (#237)
Browse files Browse the repository at this point in the history
Overview: DRS as it was when we started the transition from DOS

* Rename DOS to DRS, strip data prefix (closes #192)

This also closes #196.

This commit begins the rename of the Data Object Service
to the Data Repository Service within the codebase. It also
removes the data- prefix from data bundles and data objects.

* Begin adoption of HubFlow

Further work required, see #206

* Bump version to v0.6.0

* Setting up documentation build system (#199)

This documentation build system automates builds of
Swagger and HTML/PDF documentation using adapted
code originally developed by @jaeddy for
ga4gh/workflow-execution-service-schemas.

* making the doc links more clear, also want to trigger TravisCI

* trying to get develop to build but not deploy to PyPI

* I think this is better, we only deploy when the branch is master. I need to check with Natan and see if this will work for release tags (which we do want deployed to PyPI).

* adds data-bundle checksum test (closes #119) (+5 squashed commits)
Squashed commits:
[327cdd2] Update python/test/test_server.py

Co-Authored-By: rshreya <[email protected]>
[c9fcd75] Update python/test/test_server.py

as per review suggestion

Co-Authored-By: rshreya <[email protected]>
[285509f] fix per PR review
[c8a3bf7] removed unused variable
[42c1275] added databundles checksum test

* quick fix

* Update CONTRIBUTING.md

* Update CONTRIBUTING.md

* Update CONTRIBUTING.md

* Update CONTRIBUTING.md

* trying to correctly match feature branches

* Update CONTRIBUTING.md

* include doc changes from the January hackathon (#231)

* update the doc intro in front_matter.adoc (from the shared doc)
* add back_matter.adoc
* add a new "Motivation" appendix, with figure[123] cartoons (from the shared doc)
* update staging code to a) support images and b) fix a bug in deploy to master

* Updating release branch info with HubFlow reference.

* I added a simplified PR voting process based on #225

* small update on format

* updating the travis build info to use common account

* trying to correct failed build for a PR

* fixing syntax

* updating travis to get release branches to build

* removing an attribute causing error

* updating to 0.0.1 of DRS

* adding a note about 1.0.0 and transition from DOS

* updating david S's docs
  • Loading branch information
briandoconnor authored Apr 15, 2019
1 parent 8a68cee commit f79884f
Show file tree
Hide file tree
Showing 44 changed files with 5,929 additions and 788 deletions.
3 changes: 2 additions & 1 deletion .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,8 @@ dist/
downloads/
eggs/
.eggs/
lib/
# need to comment out otherwise the swagger js libs don't get copied in the gh-pages deploy
#lib/
lib64/
parts/
sdist/
Expand Down
92 changes: 47 additions & 45 deletions .travis.yml
Original file line number Diff line number Diff line change
@@ -1,60 +1,62 @@
language: python

python:
- '2.7'
- '3.6'

# Specifying `branches.only = ['master']` can cause tagged builds to
# not deploy. See travis-ci/travis-ci#2498 and travis-ci/travis-ci#1675.
# We can fix this by only build master and branches/tags that follow the
# format x.y.z.
branches:
only:
- master
- /^\d+\.\d+(\.\d+)?(-\S*)?$/

- master
- develop
- "/^\\d+\\.\\d+(\\.\\d+)?(-\\S*)?$/"
- "/^feature\\/issue-\\d+(-\\S*)?$/"
- "/^release\\/\\d+\\.\\d+(\\.\\d+)?$/"
stages:
- linting
- test
# The deploy stage only has `deploy` actions which will only run on commits to master
# (and not pull requests). That said, we still explicitly skip this stage because
# if we don't, Travis will only stop execution once the build stage has already been
# set up. If we skip the deploy stage for pull requests at the stage level, we can
# shave off a couple minutes of runtime.
- name: deploy
if: type != pull_request

- linting
- test
- name: deploy
if: type != pull_request && branch = "master"
jobs:
include:
# If the linting stage fails, then none of the other stages will run.
- stage: linting
python: '3.6'
script:
# Travis will install requirements.txt by default
- flake8 --select=E121,E123,E126,E226,E24,E704,W503,W504 --ignore=E501 app.py tests

# Deploy to PyPI on every tagged commit
- stage: deploy
python: '3.6'
script: ignore
before_install: ignore
deploy:
- provider: pypi
on:
tags: true
branch: master
python: '3.6'
repo: ga4gh/data-object-service-schemas
user: david4096
password:
secure: LlQn8ZBAb5ekujHnoDrmzrmXaM6TpyzByNHPH4FTbbdnJ8lkDPb/ZhYvdmqrOvXPQg81/IoYKlIvP7fY9kc3oGUJ2IXhcPFqiw8njsRE5Qaebp+YppQO7C3IWGlHoZtXNtC608ZSA4x0oneNeNy+Y8KYnqKbmOlbuvrYRlNYfe9/8z7yLPH8wdmp0GyvbViedr3p7PXhtQVUKAgPpgjffZnSA7P/Y6AdkvjHHv2xMAzWP/QmOFWZNxUXjg0miR0K7eGFeGBNMM/+QsVXrGOu/TCtPtJ4JXyD86nzrZUbsOluyAblxwGlrv05se5ImVhR210OC5zvSW2902y/lxCw5uek+xg4/tcSA1ckshxLeu02GfDygCktMUtqtKVIZ+qvU7H4dEQ6Jnz9yBvZW5M6V94Ew3wBFy0RB5I9k3MMQY21FdynIUEZzBgJbOChCbmlIDT1varBHvWBiwg8EwPOVuJt1CsOoptJxUsoJND4tAOPIvXMNI17qGJ+VWAVMVNn7cVUuhEeGXwQF4urrkFBA7WIYOp6O9R8Ipg6WnQdxVdnqb3NsEc19SRdFXQ82SYibKfIZxjpdmYVgKzTYsJGMhfG6fTw9D4JABhggfgShsnByrFtbbkn/9g64jXDOjwPLeRXwXYZe6ZV6M69PDWdo0o326Qq/OHBG5eU7z2plNI=

- stage: linting
python: '3.6'
script:
- flake8 --select=E121,E123,E126,E226,E24,E704,W503,W504 --ignore=E501 app.py
tests
- stage: build_pages
language: java
jdk: oraclejdk8
before_install:
- chmod +x gradlew
- chmod +x scripts/fetchpages.sh
- chmod +x scripts/stagepages.sh
script:
- "./scripts/fetchpages.sh"
- "./gradlew installSwagger buildSwagger asciidoctor"
- "./scripts/stagepages.sh"
deploy:
provider: pages
skip-cleanup: true
github-token: "$GITHUB_TOKEN"
on:
all_branches: true
- stage: deploy
python: '3.6'
script: ignore
before_install: ignore
deploy:
- provider: pypi
on:
tags: true
branch: master
python: '3.6'
repo: ga4gh/data-repository-service-schemas
user: ga4gh-cloud-workstream
password:
secure: O3xHQwUG2pEhU0FXmeaWzDY70iRz0J+LeXGhyH9UJz84WCSSfmwEyxH4gJlucHLEmUBV+nuwxbe6vRzN2jiO34qSXrdSV7fippw2ZCuYM+hwOz0rB42B0fUVqMBIMjAusKdoumaeOS15spOV+06qSAtzB+bhI0ZqhSEFy7yeX1qIdx33bJUSqB73r9be+gndafXG9vK2lqz0C8tMA3cYFze6alX3vde8dWYuTeq65XhXyqrwELhCMTVTYQmHit9Y7qMqcJdb5a/O/Q8QcmhxiowxfZXqzXtRKfAFaukq1FobG05WYVcz3Uwsog6EVkqlQ9WZ7LNv2ZskLRut+o/bq2zuYGoiEtjLu4SVaPQrgRrcAf4HisMx6elJIjQffNjaaZTJ89kMJq8lGV/t+HfBSEUwxU6gK3ueDIAHDLbnaPbGTPs8bBNo2XZ+7rRU3xCkiDB/ZwOktuwguGFBSOA7UT129JOp8yQ3y4G2SvwwMNo7KUKr2R4PDY5q6FG2XoZZqJHOkPP/iOvy3e+3gpUg3tGYxsQF2XJaarvzqOfkrHMMnlKmCrkcueVeIRyxbMfp/FylxAL4D4AY6xdM2Otl7+hZjB49ZruoRitoa+N5w6AEG0CaIQoJWQ3k2UIGektjdhrDszJS47Q65efjiO93XEcUiEXh2bM4KJfYDxHI13M=
before_install:
- python setup.py sdist
- pip install dist/ga4gh_dos_schemas-*.tar.gz
- pip install dist/ga4gh_drs_schemas-*.tar.gz
- npm install -g swagger2openapi

script:
- make schemas
- nosetests python/
- ga4gh_dos_client
- ga4gh_drs_client
105 changes: 52 additions & 53 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -1,9 +1,9 @@
How to contribute to the GA4GH Schemas
How to contribute to the DRS GA4GH Schema
======================================

Thank you for taking the time to contribute. We appreciate it!

The GA4GH schemas define an API for sharing genomic and phenotypic data.
The GA4GH DRS schema defines an API for sharing data.

There are two ways to contribute to the effort - via issues, which are
used for discussion, and pull requests, which are concrete proposals of
Expand Down Expand Up @@ -41,18 +41,25 @@ repositories each with the same name is a branch set, e.g. the master
branch in each repository forms the master branch set.

Some general rules to follow:

- [Fork](https://help.github.com/articles/fork-a-repo) the main
project into your personal GitHub space to work on.
- Create a branch for each update that you're working on. These
branches are often called "feature" or "topic" branches. Any changes
that you push to your feature branch will automatically be shown in
the pull request.
- If necessary, replicate the last two steps' fork-and-branch process
for each of the compliance and server repositories to create a
branch set - each constituent repository branch will be
identically named.
- Coordinate pull requests across the branch set by making them as
- Create an issue in Github to track your work and start a conversation. Make a note of the number, you'll
need it when naming your feature branch below.
- We follow [HubFlow](https://datasift.github.io/gitflow/) which means we use
a feature branch strategy with pull requests always going to `develop`
and releases happening from `master`. **Please read the HubFlow guide linked above, it's a quick read and will give you a really good idea of how our branches work. Do not make pull requests to `master`!**
- If you are a core developer with write access to the repo, make a feature
branch following HubFlow conventions in the repo (see next step). Otherwise
[fork](https://help.github.com/articles/fork-a-repo) the repo into your personal GitHub space to work on.
- Create a "feature" branch for each update that you're working on (either in the main repo or your fork depending
on the previous step). These branches should start with "feature/issue-[number]-[some-description]". For example
"feature/issue-123-improving-the-docs". Most devs will use the HubFlow command line tools to do this however, if you
make a feature branch in GitHub's UI, then please make sure you follow this naming convention.
- If you are creating a feature branch in the main repo and you follow this
convention nice things will happen e.g. TravisCI will check your branch and the documentation and swagger will be built
for you, see the [README.md](README.md) for how to construct a URL to view these for your feature branch.
- When you're happy with your feature branch, make a [Pull Request](https://help.github.com/articles/about-pull-requests/)
in GitHub from your feature branch (or fork with a feature branch) to develop. Pick at least one other person to review
and write up a good message that links back to the issue you started this whole process with.
- If you have multiple related pull requests, coordinate pull requests across the branch set by making them as
simultaneously as possible, and [cross referencing
them](http://stackoverflow.com/questions/23019608/github-commit-syntax-to-link-a-pull-request-issue).
- Keep your pull requests as small as possible. Large pull requests
Expand All @@ -68,40 +75,32 @@ will automatically run tests to ensure valid schema syntax. If your pull
request fails to pass tests, review the test log, make changes and then
push them to your feature branch to be tested again.

Issue Resolution
================
Builds with Travis-CI
=====================

We use Travis for CI testing. If you create a fork and feature branch
this will not automatically be built from our Travis. However, if you
are a developer and have created a feature branch following the naming
convention above, you should see automated builds.

Check https://travis-ci.org/ga4gh/data-repository-service-schemas/builds to see the status of the builds.

Pull Request Voting Process
===========================

DRS is very much focused on meeting the needs of our Driver Projects
so this voting process is focused on their needs.

1) We always have an issue created before a PR, this is where a description and initial conversation takes place

2) Someone is assigned the ticket, they bring together one (or more) pull requests... they might do it themselves or ask for help. Multiple pull requests could be used if there are different approaches that need to be explored

3) David, Brian, and Rishi review the PRs every week on the call (and also ping the mailing list), set a deadline by which drivers (and a few key non-drivers) need to respond with a +1, 0, or -1 by. A non-vote means 0 so neutral. We try for no "-1"s. Strive to reach consensus with our drivers. We ask that a -1 give us details why.

4) David and Brian as Work Stream leads retain a veto if something goes off the rails

5) We merge or discard depending on the vote/veto by the date we set when the PR was shared with the group

Once a pull request or issue have been submitted, anyone can comment or
vote on to express their opinion following the Apache voting system.
Quick summary:

- **+1** something you agree with
- **-1** if you have a strong objection to an issue, which will be
taken very seriously. A -1 vote should provide an
alternative solution.
- **+0** or **-0** for neutral comments or weak opinions.
- It's okay to have input without voting
- Silence gives assent

A pull request with at least two **+1** votes, no **-1** votes, that has
been open for at least 3 days, and whose cross-referenced pull requests
to server and compliance have similarly been upvoted is ready to be
merged. The merge should be done by someone from a different
organization than the submitter. (We sometimes waive the 3 days for
cosmetic-only changes -- use good judgment.) A pull request to either
the schemas, servers or compliance repository that involves changes to
the others should not be merged without coordinating, mergable pull
requests to the other repositories. Conversely, when merging a pull
request the other pull requests in the branch set must be merged at the
same time (In practise, when merging a branch set including the schemas
repository, merge the pull request to schemas first to avoid the
continuous integration build issues). If an issue gets any **-1** votes,
the comments on the issue need to reach consensus before the issue can
be resolved one way or the other. There isn't any strict time limit on a
contentious issue.

The project will strive for full consensus on everything until it runs
into a problem with this model.

Syntax Style and Conventions
============================
Expand Down Expand Up @@ -186,12 +185,12 @@ resolution](#issue%20resolution).
Release Branches
================

From time to time the group will make a release. This is achieved by
creating a branch set including all the repositories named
"release-foo", where foo is the release name. Only bug fixes are allowed
to release branch sets. To refer to a specific version of a release
branch set either the commit id can be used, or alternatively (better),
a tag can be created (which should be replicated across repositories).
From time to time the group will make a release, this is done with the HubFlow
release process which generally involves creating a branch
"release-foo", where foo is the release name. And following the HubFlow
tooling for pushing this to master/develop and taggging in GitHub.
Only bug fixes are allowed
to the release branch and the release branch is removed after a successful HubFlow release.

Retired Task Teams
==================
Expand Down
Loading

0 comments on commit f79884f

Please sign in to comment.