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
- Fork repo (if applicable)
- Press "Fork" in GitHub UI
- 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
- Ensure correct branch and sync with upstream before making additional changes
- git checkout master
- git pull upstream master
- Create a branch named after the Story (for example
NDS-174
-
Getting issue details...
STATUS
)
- git checkout -b NDS-174
- Make any necessary modifications locally on your branch
- Stage any modified files for commit
- git add path/to/modified/file.ext
- Commit any modifications to your local branch with a comment
- git commit -m "A comment about this commit"
- Push any local commits back up to your remote branch (your forked repo)
- git push origin NDS-174
- 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"
- Fork repo (if applicable)
- Docker Workflows: Push any necessary test images to Docker Hub
- Build test image
- docker build -t ndslabs/apiserver:dev .
- Tag test image with Story id (i.e. NDS-174)
- docker tag ndslabs/apiserver:dev ndslabs/apiserver:NDS-174
- Push test image to Docker Hub
- docker push ndslabs/apiserver:NDS-174
- Build test image
- 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)
- New versioned Docker images are automatically built from the upstream tags created on GitHub.
- 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
- Swagger API
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