NgSysV2-4.3: Automated Svelte Pre-render Builds

This post series is indexed at NgateSystems.com. You'll find a super-useful keyword search facility there too.

Last reviewed: Nov '24

1. Introduction

Post 4.2 floated the concept of pre-rendering a web page. The idea was that if a page never changes (or, at least, doesn't change too often) then it might as well be turned into HTMl during the project's "build".

This is fine but, if the underlying data changes too often, running builds to bring pre-rendered pages up to date manually will become annoying. Automation is surely the answer.

You might tackle this in several ways, but I recommend using a script to run the build/deploy sequence and then getting the Windows scheduler to run this automatically

2. A Powershell Build/Deploy script

Here's a ps1 script you might use:

$projectId = [myProjectId]
$projectPath = [myProjectPath]

# Define log file path
$logPath = "$projectPath\log.txt"

# Overwrite the log file with a timestamp at the beginning
$timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
"Log started at $timestamp" | Out-File -FilePath $logPath -Force

# Set the project ID
gcloud config set project $projectId

# Redirect output to log file
try {

    cd $projectPath 2>&1 | Out-File -FilePath $logPath -Append

    npm run build | Out-File -FilePath $logPath -Append

    # Fetch all versions ordered by creation date, excluding the latest 10
    $oldVersions = gcloud app versions list  `
        --sort-by="~version.createTime" `
        --format="value(version.id)" | Select-Object -Skip 10

    # Delete the old versions if there are any
    if ($oldVersions.Count -gt 0) {
        "Deleting old versions..."| Out-File -FilePath $logPath -Force
        $oldVersions | ForEach-Object {
            gcloud app versions delete $_ --quiet 2>&1 | Out-File -FilePath $logPath -Append
        }
    } else {
        "No old versions to delete. The limit of $MaxVersions is not exceeded." | Out-File -FilePath $logPath -Force
    }

    gcloud app deploy build/app.yaml --quiet 2>&1 | Out-File -FilePath $logPath -Append

    } catch {
    "An error occurred: $_" | Out-File -FilePath $logPath -Append
}

In this script, [myProjectId} is your Google projectId - eg "svelte-dev-80286"
and [myProjectPath] is the full pathname for your VSCode project - eg "C:\Users\mjoyc\Desktop\GitProjects\svelte-dev". The output log.txt file ends up in the root of your VSCode project folder

The script looks more complicated than you might have expected. Here are the reasons for this:

Because you intend to schedule the script automatically, you need to maintain a log file to tell you what has gone wrong if it errors. This alone adds much unavoidable"clutter". But there's also a strange "version deletion" section. You need this because, each time you run a "build", Google will create a new version in cloud storage. There is a default maximum to the number of versions you can create. I added this section when my system errored when the version count reached 200.

In the script above, I limit the number of versions maintained to just 10 (I'm paying for my App run hosting now!).

The most direct way of testing the script file in a VSCode terminal session is to select its contents, paste it into the session and press return. But for production purposes, you need some automation.

3. Configuring a Windows Schedule to run the PowerShell script

Here's a procedure for registering a Windows Scheduler task to run the build script.

1. Type "Task Scheduler" in the Windows search bar and open the app.
2. In the Actions menu, click on “Create a Basic Task”.
3. Supply a name and description for the task
4. On the Triggers tab, Select the interval you want to run the program, such as “Daily”, “Weekly”, etc.
5. Specify the start date/time and frequency for the task.
6. Select the “Start a program” option button.
7. Now, in the “Start a Program” window: In Program/script: Use "browse" to help you enter the path of Windows PowerShell, eg: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe In Arguments: Enter the full path of the script. eg: [full path to the script][my script filename].ps1 In “Start in”: Enter the folder path where the script is located. eg “[full path to the script]”
8. In the next window, select the checkbox “Open the Properties dialog for this task when I click Finish”, and click the Finish button.
9. In the General tab of the properties dialogue, ensure that the “Run when user is logged on or not” and “Run with highest privileges” checkboxes are selected. This ensures you are running the script with Administrator rights.
10. Click the OK button and confirm your right to save your new scheduler task by responding to a login prompt with your Microsoft username and password for your machine.
11. Test the new task by opening the Task Schedule Library, right-clicking on the task's entry here and selecting "Run"

I use a Windows Scheduler task created using the above procedure to run a nightly build for the pre-rendered "ngatesystems.com" keyword-search page. Though new posts are now added only rarely, I'm still making regular edits to existing pages. The nightly run arrangement means the search page is never more than a day behind the live data.