Skip to content

Chapter D: Build VASL Versions.

Jump to bottom
Doug Rimmer edited this page Oct 29, 2025 · 2 revisions

Creating New VASL Versions: WorkFlow Process

These steps apply whether creating an official release or beta version.

The following steps a required to trigger the workflow process on Github which is used to

  1. run a number of tests on the source code prior to building,
  2. build the module
  3. publish the module on Github
  4. in the future, publish the module on VASL.info

Once any local changes have been pushed to Github:

  1. Merge all branches and commits that should be incorporated in the release into the develop branch. Do this by creating a new PR and pulling changes from the branch containing the changes into develop.

  2. Create a new temporary branch from develop to prepare for the release. This branch is where the release number (in the POM and buildFile) and release information/number (in release-notes.md) should be checked and updated if not already done.

  3. Once ready, attempt to merge this temporary branch into production via a pull request. This will trigger the workflow and run some tests.

  4. Most likely some tests will fail. Click the link and see what failed and fix what needs fixing. To make changes to the code, do so in the dev environment and push/pull the changes through to develop and then into the temp branch. There is no need to delete the temp branch. When changes are pulled from develop into the tempoarary branch, the workflow tests will be re-trigged. It may take several iterations before all tests are passed.

  5. Once the PR passes all tests, notify all vasl developers that there is a PR ready to go and wait several days to allow others to review the draft PR.

  6. After sufficient time, proceed with the merge into production which should then generate your new release. It takes a few minutes for the new release to show up on the Github VASL Releases page. You will also receive a message that the attempt to add the release to the VASL.info website has failed. This is not a problem at this point in time; when we are fully confident in the workflow process, we can attempt to fix this.

  7. The release will appear on the releases page as a draft and the entry needs to be edited to confirm it as a pre-release or published version and then published. To do so, go to the vasl home page on GitHub. On the right side of the page you will see a Releases section. Click and go to the releases home page. You should see the release as a draft. Scroll down. At the bottom of the draft select release as pre-release. Then select Publish or Release or whatever it says. This may be up at the top of the draft.

  8. Current practice is to update the coop.htm page in the vasl website repo, which is where users will be directed to trigger the download. Once you do a PR into gh-pages, it takes 10-15 minutes for the changes to go live on vasl.info.

Clone this wiki locally