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
- API: docker build -t ndslabs/apiserver:NDS-123 . && docker push ndslabs/apiserver:NDS-123
- GUI: ./build.sh -c && ./release.sh NDS-123 -t
Tag / push new image to DockerHub (issue tag: push, latest: don't push)
Mark ticket as "In Review" and assign to tester

New Stable "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:

Build new docker images from master branch
- API: docker build -t ndslabs/apiserver . && docker push ndslabs/apiserver:latest
- GUI: ./build.sh -c && ./release.sh
Tag / push new image to DockerHub (version tag: don't push, latest: push)
Commit and push new build version / date(s) to upstream master on GitHub

Official Tagged Version Release

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:

Roll forward version numbers in source code and ensure that all values match:
- 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
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
Build new Docker images from master branch
- API: ./build.sh build && ./build.sh release
- GUI: ./build.sh -c && ./release.sh version-number
Tag / push new images to DockerHub (version tag: push, latest: push)
Commit and push new build version / date(s) to upstream master on GitHub
Create a new tag in GtiHub for the new version

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