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  NDS-174 - Getting issue details... STATUS )
     • 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