Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

    • kubeadm-bootstrap and kubeadm-terraform
  1. Roll versions forward
    1. ndslabs
      1. gui/swagger.yaml: NDS Labs swagger API spec version number
      2. apiserver/build.sh: NDS Labs API Server Docker image version tag
      3. gui/Dockerfile: NDS Labs UI / webserver Docker image version tag
      4. gui/package.json: NDS Labs UI  / webserver NPM package version number
      5. gui/ConfigModule.js: NDS Labs UI Angular app build version number
    2. workbench-helm-chart
      1. values.yaml: NDS Labs API Server + UI Docker image version tags
    3. kubeadm-bootstrap
      1. install-kubeadm.bash: Kubernetes / Docker version numbers
      2. init-master.bash: Helm version numbers
    4. kubeadm-terraform
      1. kubeadm-bootstrap git release/tag: assets/bootstrap.sh
  2. PR from release branch to master
    1. Thorough testing, then more testing, then merge to master
  3. Tag master with new version number (freshly tested and stable)
    1. Any new merges and tags will trigger new Docker images to be built
  4. Wait for newly-tagged resources to automatically finish building and pushing Docker images
    1. Run a quick smoke test with newly-tagged resources
    2. Fix any last-minute errors directly on master and recreate release
  5. Backport any missing changes from master release-x.x.x into develop
    1. This should include, at the very least, rolling a commit from the release branch that rolls forward to new version numbersRemember to "Rebase and merge" to avoid adding an additional merge commit
    2. git checkout develop && git pull origin master && git push origin develop? Why does this not work with a PR...
Legacy Process
  1. Regenerate Swagger API / Client from spec (this can be skipped if the spec has not changed)
    • apiserver/???: generated Go swagger server
    • gui/js/app/shared/api.js: generated AngularJS swagger client 
  2. Roll forward version numbers in ndslabs-deploy-tools and ensure that all values match the version number you are about to create:
    • roles/cluster-backup/defaults/main.yml
    • roles/ndslabs-api-gui/defaults/main.yml
    • roles/k8s-nagios-nrpe/defaults/main.yml
    • roles/k8-glfs-server-pods/defaults/main.yml
    • roles/k8-glfs-client-set/defaults/main.yml
  3. Create a new tag from master in GitHub for the new version (i.e. 1.0.0, 1.0.1, etc):
    1. Repositories should be tagged in the following order when possible:
      1. ndslabs (API server / REST API / CLI / UI)
      2. ndslabs-specs (service specs - starting with 1.2.0, this can be versioned separately from Workbench, but it should be noted upon a new release which version of Workbench the specs release will target)
      3. workbench-helm-chart (Helm deployment to Kubernetes)
      4. gluster (global file system - deprecated, no longer used)
      5. cluster-backup (cron job for backing up glfs / etcd / kubectl dump - starting with 1.2.0, this can be versioned separately from Workbench)
      6. ndslabs-nrpe (nagios monitoring - these can now be versioned separately from the rest of Labs Workbench)
      7. ndslabs-startup (dev-cluster startup - deprecated, no longer used)
      8. ndslabs-deploy-tools (ansible scripts - deprecated, no longer used)
      9. kubeadm-bootstrap (kubernetes deployment scripts - versioned separately, but it should be noted upon a new release which version of Workbench the release will target)
      10. kubeadm-terraform (terraform deployment procedure - versioned separately, but it should be noted upon a new release which version of Workbench the release will target)
      11. ndslabs-devenvs (developer environments - these can now be versioned separately from the rest of Labs Workbench)
        • 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
    2. New versioned Docker images are automatically built from the upstream tags created on GitHub.
    3. All new tags that are created will trigger a build
  4. 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 (deprecated - use the file below instead)
      • gui/swagger.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 file no longer exists
    • CLI Client:
      • apictl/build.sh: NDS Labs CLI version number file no longer exists
      • apictl/cmd/clientVersion.go: NDS Labs CLI / API version number file no longer exists
    • UI Client:
      • gui/Dockerfile: NDS Labs UI / webserver Docker image version tag
      • gui/package.json: NDS Labs UI  / webserver NPM package version number
      • gui/bower.json: NDS Labs UI Angular app Bower package version number file no longer exists
      • gui/ConfigModule.js: NDS Labs UI Angular app build version number

...