All documentation pertaining to how developers can contribute to NDS Labs.

New to NDS Labs?

Start here: New Developer Workflow

Develop Workflows

JIRA Workflows: Issue and project tracking workflows
Git Workflows: Forking workflow with feature branches
1. Fork repo (if applicable)
  - Press "Fork" in GitHub UI
2. Clone repo to make changes locally (if applicable)
  - git clone https://github.com/USERNAME/ndslabs.git
  - git remote add upstream https://github.com/nds-org/ndslabs.git
3. Ensure correct branch and sync with upstream before making additional changes
  - git checkout master
  - git pull upstream master
4. Create a branch named after the Story (for example )
  - git checkout -b NDS-174
5. Make any necessary modifications locally on your branch
6. Stage any modified files for commit
  - git add path/to/modified/file.ext
7. Commit any modifications to your local branch with a comment
  - git commit -m "A comment about this commit"
8. Push any local commits back up to your remote branch (your forked repo)
  - git push origin NDS-174
9. When you are satisfied with your set of commits, create a Pull Request (PR) to view the diff
  - Press "Pull Request" in GitHub UI
  - Be sure to select the correct base and compare branches
    - Select nds-org/ndslabs as the base fork
    - Select master as the base branch
    - Select your personal fork (USERNAME/ndslabs) as the head fork
    - Select your personal Story branch as the compare branch
  - Scroll down and click on the "Files Changed" tab to briefly review your own Pull Request
    - Ensure that all changes made on this branch were intentional
    - If you are unsure about any specific code segments, comment in-line on the PR to ask for clarification
    - If you are unsure about any general concepts changed or introduced, comment in the section at the bottom of the PR
  - Name your Pull Request after the Story / branch (i.e. "NDS-174: User can access console of running service via CLI")
  - Enter a short description of any modifications, additions, or removals from the codebase
    - If applicable, include a Test Case that the reviewer should run before merging the Pull Request
  - Click "Create Pull Request"
Docker Workflows: Push any necessary test images to Docker Hub
1. Build test image
  - docker build -t ndslabs/apiserver:dev .
2. Tag test image with Story id (i.e. NDS-174)
  - docker tag ndslabs/apiserver:dev ndslabs/apiserver:NDS-174
3. Push test image to Docker Hub
  - docker push ndslabs/apiserver:NDS-174
Kubernetes Workflows: Sometimes used in testing new services or the API server

An Example

https://github.com/bodom0015/developer-workflow

More Detail

Release Workflows

New Unstable "Test" Release

Prerequisites:

Pull request has been created containing the changes to be reviewed / tested
Ensure that associated JIRA ticket
Ensure documentation in Confluence is up-to-date
Checkout your feature branch
- git checkout master
Sync with upstream
- git pull upstream master
- git push origin master
Update ALL documentation in GitHub

Process:

Build new docker images from PR branch
Tag / push new image to DockerHub (issue tag: push, latest: don't push)
Mark ticket as "In Review" and assign to tester

New Unstable "Latest" Release

Prerequisites:

Any related PRs have been merged to master
Ensure that smoke test passes
Ensure documentation in Confluence is up-to-date
Checkout your master branch
- git checkout master
Sync with upstream
- git pull upstream master
- git push origin master
Update ALL documentation in GitHub

Process:

New "latest" Docker images are automatically built from the upstream master branch on GitHub.
All new changes that make it into master on GitHub will automatically trigger a build on DockerHub
- For example: https://hub.docker.com/r/ndslabs/apiserver/builds/

Official Tagged Version Release (Stable)

Prerequisites:

Ensure that all tests pass
Ensure documentation in Confluence is up-to-date
Checkout your master branch
- git checkout master
Sync with upstream
- git pull upstream master
- git push origin master
Update ALL documentation in GitHub

Process:

Regenerate Swagger API / Client from spec (if the spec has changed)
- apiserver/???: generated Go swagger server
- gui/js/app/shared/api.js: generated AngularJS swagger client
Create a new tag from master in GtiHub for the new version (i.e. 1.0.0, 1.0.1, etc)
1. New versioned Docker images are automatically built from the upstream tags created on GitHub.
2. All new tags that are created will trigger a build.
  - For example: https://hub.docker.com/r/ndslabs/apiserver/builds/
Roll forward version numbers in source and ensure that all values match on upstream master on GitHub:
- Swagger API
  - apis/swagger-spec/ndslabs.yaml: NDS Labs swagger API spec version number
- API Server:
  - apiserver/build.sh: NDS Labs API Server Docker image version tag
  - apiserver/version.go: NDS Labs API / Server version number
- CLI Client:
  - apictl/build.sh: NDS Labs CLI version number
  - apictl/cmd/clientVersion.go: NDS Labs CLI / API version number
- UI Client:
  - gui/Dockerfile.ndslabs-gui: NDS Labs UI / webserver Docker image version tag
  - gui/js/package.json: NDS Labs UI / webserver NPM package version number
  - gui/js/bower.json: NDS Labs UI Angular app Bower package version number
  - gui/js/app/app.js: NDS Labs UI Angular app build version number

Repositories to Tag (in order)

ndslabs (API server / REST API / CLI / UI)
ndslabs-specs (specs)
gluster (global file system)
deploy-tools (ansible scripts)
ndslabs-devenvs (unopinionated developer environments)

NOTE: ndslabs-devenvs contains a large number of cascading images that will quickly fill up the build queue, that's why we do it last