WickedSpooky.ai: Creating Git and GitHub Releases
Three different things
The release/ folder is a working place for deployment artifacts and their evidence. A Git tag names an exact repository revision. A GitHub Release publishes a version, release notes and downloadable assets attached to a tag. Creating a folder alone does not create a GitHub Release or deploy Amplify.
This guide applies to the current static WickedSpooky.ai website. Amplify still uses manual ZIP uploads until the Git-connected workflow is configured. QA/UAT is tested on iLab; Production receives the same accepted archive. The proposed qa/main Git workflow is not yet established.
Create the folder and commit in VS Code
Open the local wickedspooky.ai checkout with File > Open Folder in VS Code. Confirm the intended branch in the status bar. In Explorer, create release/ at repository root alongside public/ and scripts/, then create release/README.md describing the archive workflow. Git tracks files, so an empty folder will not appear in a commit.
Open Source Control with Ctrl+Shift+G, review each changed file, stage the intended files with the plus button, enter a clear commit message and choose Commit. From the Source Control menu choose Push; use Publish Branch if the branch has no upstream. Sign in to GitHub when prompted. A commit is local until it is pushed. Fetch and review incoming changes before incorporating them; avoid blindly syncing a release candidate after it has been tested.
Keep generated ZIPs out of routine Git history. Add release/*.zip to the repository .gitignore. Store downloadable ZIP files as GitHub Release assets instead. Keep the release README and small release records in Git; generated binary archives otherwise inflate history and can drift from source.
Build the archive from the accepted checkout
In VS Code, select the candidate branch and confirm Source Control has no pending source changes. Update from GitHub before testing and record the commit SHA from Source Control Graph or git rev-parse HEAD. Regenerate lessons when their source changed and run the existing verification before declaring the candidate ready.
Choose Terminal > New Terminal in VS Code and use PowerShell at repository root. Run the following. Replace the example version with your chosen version; do not overwrite an already published release artifact.
$releaseVersion = 'v0.1.0'
$releaseZip = Join-Path 'release' ('wickedspooky-ai-' + $releaseVersion + '.zip')
Compress-Archive -Path public\* -DestinationPath $releaseZip
Get-FileHash -LiteralPath $releaseZip -Algorithm SHA256The wildcard packages the contents of public/, giving index.html at archive root. Packaging the public directory itself recreates the confirmed nested-folder outage. Inspect the archive before uploading: index.html, assets/ and labs/ must appear directly at its root. Remove build scripts and unnecessary editor/generated scratch files from the deployment package; retain required static styles, images, lesson downloads and diagrams. Do not place credentials, private operating documents or repository-root scripts in the archive.
The previously prepared corrected ZIP is a recovery artifact. To claim a versioned release corresponds exactly to Git, rebuild it from the selected clean checkout and record its revision and checksum.
Test the candidate on iLab
Upload the archive to the ilab hosting branch. Verify both its default Amplify URL and ilab.wickedspooky.ai at /, /impact.html and /labs/creator/. Check assets, navigation, hover descriptions, diagrams/source fallback and a narrow-screen view. Record the archive checksum, source commit, deployment job, tested URLs, result and acceptance date.
If the qa/main branch workflow is in place, promote the accepted source to main through a reviewed pull request. If that produces a different release revision, validate the exact main revision and rebuild its archive before publishing. Until that workflow exists, explicitly record which current branch/revision was accepted; do not imply that a qa approval gate already exists.
Create the version tag and GitHub Release
On GitHub, open the wickedspooky.ai repository, choose Releases, then Draft a new release. Choose a tag such as v0.1.0. For a new tag, select the accepted release target. Confirm it is the intended commit; selecting a branch means its current head, which may have advanced since testing. Use an exact commit through a supported Git tag workflow when necessary.
In the VS Code integrated terminal, first verify HEAD is the accepted revision and that its source commit has been pushed using Source Control > Push. These commands create an annotated tag and push only that tag. Pushing a branch does not automatically push all tags:
git rev-parse HEAD
git tag -a v0.1.0 -m "WickedSpooky.ai v0.1.0"
git push origin v0.1.0Back in the GitHub release draft, select that existing tag. Give the release a clear title and notes describing changes, validation, known issues, source SHA and ZIP SHA256. Upload the tested deployment ZIP as an asset. GitHub's automatic Source code ZIP is the repository source archive; it is not the Amplify deployment ZIP because the site lives beneath public/.
Use a prerelease designation for an unaccepted candidate. Publish an accepted version when the notes and archive are ready. Publishing the release does not upload it to a manual Amplify environment. Never move a published version tag to different code; issue a new version for corrections.
Promote and retain rollback evidence
Download the uploaded release asset and confirm its checksum. Deploy that same archive to production, then verify its default URL and wickedspooky.ai. Record the production deployment job and outcome. A published release may exist before production deployment; its notes should state the actual status rather than claim the site is already restored.
Retain the last accepted Release asset and deployment record. Roll back by uploading that verified previous archive to the existing hosting branch, then checking the site. Do not delete the branch or rename it as rollback. Keep source history intact and document any corrective release.
References
VS Code: Source control, commits and pushing