Turbo-360 Deployment Support

[Sakelun]

This pull requests adds support for Command Line Interface (CLI) deployment to Turbo 360.

Features

Two additional processes have been added to the build procedure for net.create.

Packaging for Turbo 360

NPM script: npm run package-turbo360 [template]

This process will prepare a package suitable for deployment to Turbo 360 and local testing (using the Turbo 360 URSYS infrastructure).

This process relies on the existing standalone package capability to create suitable bundle for hosting. This bundle is incorporated with a Turbo 360 base template that has been customized for net.create separate repository to do the following:

• Adjust the URSYS configuration to support the Turbo 360 URSYS backend
• Provide any needed functionality that is not implemented through URSYS

Deployment to Turbo 360

NPM script: npm run deploy-turbo360

This process will replace the code-base of an existing Turbo 360 project with a package created by the Turbo 360 packaging step.

Testing

Pre-requisites

• Review the README-Turbo360.md document; these steps are paraphrased from this document.
• Create a Turbo 360 portal account if you do not already have one
• Create a Turbo 360 project that will be the target of the deployment
• Log in to Turbo 360: npx turbo login

Steps

1. Prepare the net.create codebase as described in the main README.md and ensure it is working by using npm run dev to test the local behavior when a local URSYS instance is used
2. Run the Turbo 360 packaging script: npm run package-turbo360. If you wish to use a template, append the template name to the end of the command, e.g. npm run package-turbo360 some-template
3. After packaging is successful, you may deploy to Turbo 360 by running npm run deploy-turbo360. You will be prompted to select a Turbo 360 Project to deploy to; select the project that was prepared during the Pre-requisites. This process will take several minutes.
4. When deployment is complete, the tool will report the staging URL. Visit this URL and confirm that you are able to log in and that it works as expected. Further confirm the application functionality by logging in as a student.

Technical Notes

The primary changes introduced by this PR comprise updates to the net.create build scripts to support Turbo 360 packaging and deployment and the introduction of additional URSYS configuration parameters to add an optional HTTPS requirement for the web socket, configure a preamble message, and disable native heartbeat support (for now).

[Sakelun]

Remaining steps:

• Provide README-Turbo360.md document.
• Change dist folder to dist_turbo360

[dsriseah]

Sri Update February - It looks fine to me, though I want to make some changes to the working directories it uses, and also evaluate the naming of scripts that the package scripts invoke turbo. I'll make these changes and submit them.

[dsriseah]

Abbreviated Test Instructions

• First, make sure NetCreate runs properly with npm run dev
• Make sure you're logged-in to your Turbo360 account
• npm run package-turbo360 - this builds netcreate public and creates a dist directory with turbo-specific files along with the netcreate public
• npm run deploy-turbo360 - the uploads the contents of dist to Turbo360 server, prints URL

Technical Notes

• Turbo360 version relies on having its own express router (put into dist from https://github.com/Vertex-Labs/base-template-netcreate.git) which provides NetCreates global connection vars (Our index.ejs file)
• Turbo360 adds wss (address of socket server, preamble, and heartbeat to existing parameters. The effect of wss is to override uport if it exists, which allows the Turbo version of the appserver to substitute its own endpoint for websocket connections.

[dsriseah]

Issues noted about the PR description

• The first step "prepare the net.create codebase..." is pretty ambiguous. I think it is just saying "make sure NetCreate is functioning properly" rather than implying some specific step out of the giant README. I had to read the build script to determine what it actually meant me to do.
• Review the README-Turbo360.md...there is no such file in the repo

[dsriseah]

I'd like to change the dist directory name to dist_turbo360 to make it clear that it's specifically for turbo360. That's because our codebase should be platform agnostic and unambigious.

• dist is a convention used for node package.json mainfiles entries
• we'd probably want to support other build targets

[dsriseah]

In the code:

  fs.moveSync('./dist/public/index.ejs', './dist/views/home.html');
  fs.removeSync('./dist/public/index.html');

Is there a reason for doing this in code rather than have it be arranged this way by default in https://github.com/Vertex-Labs/base-template-netcreate?

[Sakelun]

@dsriseah It has been some time, so I don't recall the specific reasons, but I suspect it has is because content from the public folder might be exposed directly as static content rather than rendered through the EJS rendering engine. The net.create template is based on a more generic Node/Express template so it adopts the same conventions for consistency (usage of the views folder, the home filename).

[benloh]

Adding some notes from this Slack conversation so that I can find this again and don't have to redo this check again.

Much of this needs to be re-confirmed, but logging it for reference later.

Two issues

• After deployment, some instances might still be using a cached version of the app. This seems to vary across region. This will probably be fixed later. Try different locales to verify.
• There is possibly a disconnect between the database being specified in the app-config/netcreate-config.js file and what T360 actually runs. See Slack #1 and Build System: Update NodeJS, Build Directories #2](https://inquirium.slack.com/archives/C05Q8LY4H1D/p1740151214407859)

The behavior of the T360 implementation had assumed that templates and database files were primarily being loaded and updated via the admin interface (More > Edit Templates and More > Import / Export). This needs to be reconciled with the behavior of the local app. The proper solution is to probably to rethink the overall interface.

[benloh]

NOTE there are changes to index.ejs in d5631b5
Specifically, these lines have been removed:

  <script src="/scripts/ursys-core.js"></script>
  <script src="/scripts/ursys-addons.js"></script>