Issue to release with GitHub

Prepare the sample and its checks

This time you will take a small fix beyond your own computer. You will publish the sample to GitHub, report its temperature bug, and watch a test fail before fixing it. The same test will run locally and on GitHub, so you can compare the results.

The walkthrough uses GitHub. Other providers have different review and automation screens in Zide.

1. Click File in the menu bar, then click Open Project. On the Open Project screen, scroll to Sample Projects.
2. Find the Sample weather web page card and click its New Sample Project button.
3. In the dialog, type weather-devops in Folder Name. Click Browse… beside Parent Folder and select a folder for the sample. Check the destination path, then click Create Sample.
4. When the new project opens, its file list is open by default. If it is not visible, click Files in the activity bar. In the file list, click index.html. Click Preview in the file toolbar, then Open in Browser. The page should show 130°F. The sample observation is 12.5°C, which should display as 55°F. Leave the unfinished forecast alone for this tutorial.
5. Click the weather check kit download link. Open the ZIP in your file manager and extract it. Copy its scripts folder, .github folder, and TUTORIAL-CHECKS.md file into weather-devops, beside index.html. Do not leave them inside an extra weather-checks folder.
6. Confirm the sample now contains scripts/weather.test.cjs and .github/workflows/weather-checks.yml. Keep the leading dot in .github; your file manager may hide that folder until you turn on hidden files.
7. Return to the weather-devops Project Tab. Click Tools in the menu bar, then New Terminal. The terminal opens in this sample’s folder. Type each command below and press Enter after each one:

node --version
node --test scripts/weather.test.cjs

Expect two passing tests and one failing test. The failure is named current conditions convert Celsius once; its first assertion shows 130°F where 55°F is expected. The kit checks the actual current-conditions renderer, which the sample’s original tests.html does not cover.

Click Git in the menu bar, then Staging. Click each of the three added files under Unstaged to read its contents. Click the Stage icon beside each file; hover over the icons to find its label. Type Add weather regression checks in Commit message, then click Commit.

Leave the bug in place for now. The failure gives you something specific to find in GitHub Actions, which runs checks automatically when code is pushed. This is the continuous integration, or CI, part of the tutorial.

Before continuing, look for two passes and one failure in the terminal, and no files left in Staging. A missing file or an unrecognized node command is a setup problem, not the failure we want.

Publish and connect DevOps

Connect your GitHub account

If GitHub is already connected in Zide, skip to publishing below.

1. Press Ctrl+, on Windows/Linux or Cmd+, on macOS to open Settings.
2. Click Git Accounts in Settings, then click Connect account.
3. In the account dialog, click GitHub. Copy the one-time code that appears, then click Open in browser.
4. Follow GitHub’s sign-in and authorization screens. Paste the code when asked and authorize Zide for the account you intend to use.
5. Return to Zide and click Done. Check that your GitHub account appears in Git Accounts.

Publish the sample

1. Click the weather-devops Project Tab. Click File in the menu bar, then Publish Project.
2. In the dialog, check that Local Folder is your sample. Select your GitHub account in Account and your personal account as the destination owner.
3. Type weather-devops-practice in Repository Name, or another unused name. Select Private or Public according to who should see the practice repository. Click Publish.
4. In your browser, open the new repository under your GitHub account. Check the branch selector above the file list: the default branch should be main. The supplied workflow runs on pushes to main and pull requests targeting main. If your branch has another name, edit both main entries in .github/workflows/weather-checks.yml, save, commit, and click Push in Zide’s project header.
5. Click DevOps in the menu bar, then Configure. Check that Issue Tracking, Code Review, Automation, and Release Management show GitHub and this practice repository. If a category points elsewhere, select the practice repository as its source and your connected account. Click Done.
6. Click DevOps again, then Actions. Wait for the Weather checks run from the initial push. It should fail at the same assertion as your local run.

Connecting an account tells Zide who you are. Configuring a DevOps source tells it which repository’s issues, reviews, or runs to show. With just one remote, those choices may already be set for you.

The workflow uses Node.js 22 and runs the same command as your terminal. It triggers again when you open or update a pull request to the default branch. See GitHub’s workflow syntax if you want to extend its triggers later.

Actions should show a failed Weather checks run for this repository. That failure is expected. If there is no run, check the troubleshooting table at the end before continuing.

Write an issue with a verifiable result

Click DevOps in the menu bar, then New Issue. In the tab that opens, type Fix current temperature conversion in Title. Click Copy text below and paste it into Description:

Open index.html from a fresh weather sample.
Current conditions show 130°F for the 12.5°C sample observation.
Expected result: 55°F after rounding, with Celsius converted only once.

Acceptance checks:
- node --test scripts/weather.test.cjs passes all three tests.
- index.html shows 55°F without changing the sample observation.
- The existing browser checks in tests.html still pass.

Keep the unfinished forecast outside this change.

Click Create Issue. Zide opens the new issue. Write down its number, such as #1; you will use that number in the pull request description. Leave the issue tab open so you can refer to its acceptance checks while reviewing the fix.

Reference image from another repository. Use the issue number and title you just created, not the examples in the image.

Check that the issue title and description match what you entered. The number assigned by GitHub may differ from the examples here.

Create a branch and open a failing pull request

A pull request, or PR, asks to merge one branch into another after review. You will create a branch for the fix and open its PR before changing the code, so you can see the failed check turn green.

1. Click Branch in the project header. Confirm the current branch is main, then click New branch…. Type fix-weather-temperature in the branch-name field and click Create & Switch. Check that the project header now shows that branch.
2. If the file list is not visible, click Files in the activity bar. In the list, click README.md, then Edit in its toolbar. At the end, add a Development checks heading, the command node --test scripts/weather.test.cjs, and a note that the temperature bug is tracked by your issue number. Save with Ctrl+S or Cmd+S.
3. Click Staging and click README.md to review the diff. Click Stage beside it, type Document weather regression check in Commit message, and click Commit. This gives the branch a change to review while the bug still exists.
4. Click Push in the project header. If asked for a remote, select origin. This is the name Zide gave the GitHub connection. If asked to set an upstream, accept the matching fix-weather-temperature branch so later pushes go to the same place.
5. Click DevOps in the menu bar, then New PR. In the new tab, select main as the base branch, which will receive the change. Select fix-weather-temperature as the compare branch, which contains your work. Type Fix current temperature conversion in Title.
6. In Description, add Closes #N, replacing N with the actual issue number. State that the regression is currently failing and that the fix will follow on this branch. Click Create Pull Request.

The new PR opens after creation. Click Checks near its header and wait for the weather check to finish. Do not merge yet. New commits pushed to this branch will update this same PR.

The PR should show your README change and a failed weather check. The code is still wrong; the next step is to read why the test failed.

Investigate the failed run

1. Click DevOps in the menu bar, then Actions. Click Show filters and type fix-weather-temperature in Branch. Find the new run whose event is pull_request.
2. Click that run. Check its branch and commit, then click the Weather checks job to expand its steps and logs. Find Test weather rendering.
3. Find the failing assertion. It should match the local failure: the renderer outputs 130°F, not 55°F.
4. Leave the run tab open. If you need help understanding the failure, you can copy the assertion text into the Zide Assist conversation in the next section.

Reference image from a different project. Its check names, results, and terminal output are not the results of this exercise.

Rerunning this commit will produce the same failure. The test is catching a code bug, so the next step is to change the code.

Find current conditions convert Celsius once in the log, with 130°F as the actual result and 55°F as the expected result. If a different step failed, resolve that failure first.

Fix the code and push the result

Check that the project header still shows fix-weather-temperature. You can ask Zide Assist to fix the bug or make the one-line edit yourself. For the manual route, skip to the code snippet below.

To ask Zide Assist, click Assist in the menu bar, then New Session Tab. Click the model name in the new session’s toolbar and select an available model. Click Copy text below, paste the prompt into the session’s message field, and click Send. The prompt includes the files and task, so attaching the GitHub issue is not required.

Fix the current-temperature bug in this weather sample.
The 12.5°C observation displays as 130°F; it should display as 55°F.
Read data/observations.js, src/temperature.js, src/weather.js,
and scripts/weather.test.cjs before editing.
Make the smallest source change so the temperature is converted exactly once.
Do not change the data, weaken the tests, implement the forecast, or add dependencies.
Run node --test scripts/weather.test.cjs and report the result.
Do not commit, push, merge, or publish a release. I will review the change first.

For a manual fix, start in the file list. If it is not visible, click Files in the activity bar. Expand src and click weather.js, then click Edit in its toolbar. The file converts reading.tempC to Fahrenheit, then passes that value to Weather.formatTemperature, which converts it again. Replace the line that starts with const tempNow with:

const tempNow = reading.tempC;

If you made the edit yourself, save with Ctrl+S or Cmd+S. If you sent the prompt, wait for Zide Assist to finish and read its reply. Then check the result yourself:

1. Click the Terminal content tab you opened earlier. Type node --test scripts/weather.test.cjs and press Enter. Expect three passing tests and no failures.
2. Refresh the sample’s index.html. Current conditions should show 55°F. The forecast remains unfinished by design.
3. If the file list is not visible, click Files in the activity bar. In the list, click tests.html, then Preview and Open in Browser. Confirm its existing checks still pass.
4. Edit the README’s status note to say that the regression check now passes, then save. Click Staging and click each changed file to review its diff. The source fix should leave the observations and supplied tests intact.
5. Click Stage beside each reviewed file. Type Fix current temperature conversion in Commit message, click Commit, then click Push in the project header.

Click the PR’s content tab and click Checks. Wait for the new run, then check that it belongs to your latest commit. A green result for an older commit does not validate new changes.

You should now have three passing local tests, 55°F in the browser, and a passing check on the updated PR. If any of those differs, investigate it before merging.

Review and merge the pull request

In the PR tab, click Changes and read the diff for src/weather.js and README.md. Compare them with the issue’s acceptance checks. Click Conversation to read the description and discussion, then Checks to confirm the latest result.

If your repository requires another person’s approval, wait for that review. Your own inspection or an AI response does not satisfy a required GitHub approval.

In Conversation, click the pencil button beside the description; its tooltip says Edit description. Replace the note about the pending fix with what changed and which checks passed. Keep Closes #N with the correct issue number, then click Save.

When the required checks and reviews pass, find the PR’s merge controls. Click Merge to select a merge commit, then click Merge pull request and confirm if prompted. If that method is disabled, read the reason and select an allowed method such as Squash. Do not bypass a required check or review.

After the merge:

1. Confirm the PR says Merged. Check that the issue closed. GitHub links closing keywords to merges into the default branch; automatic closure also depends on the repository’s setting. See linking a pull request to an issue.
2. Click Staging and confirm both file groups are empty. Click Branch in the project header, click the main row, then click Switch to main. Check that the header now shows main. Click Pull in the project header to bring in the GitHub merge.
3. Run the local checks and refresh index.html on main.
4. Click DevOps, then Actions. In the filters, replace fix-weather-temperature with main so the new push run is visible. Wait for it to pass. If it fails, investigate before making a release.

Merging the hosted PR updates the remote repository. Pulling updates your local checkout. If you chose a QuickTree for this exercise instead, pull the parent branch after the hosted merge and verify it; do not merge the same task again through Finish before cleanup.

On main, the browser should still show 55°F and the tests should pass. The PR is marked Merged. These are the files you will include in the release.

Draft and publish a practice release

A GitHub release groups a Git tag, notes, and downloadable assets. This exercise publishes the sample’s source. It does not deploy the weather page to a website or build an application installer.

1. Click DevOps in the menu bar, then New Release. The release form opens in a content tab.
2. Enter a new Tag, such as v0.1.0-tutorial, and set Target branch (for new tag) to main.
3. Set Release title to Weather tutorial 0.1.0.
4. In Release notes, describe the corrected temperature, include the actual PR and issue numbers, and state that the forecast is still unfinished.
5. Select This is a pre-release and leave Set as the latest release off. Click Save as draft.
6. Click DevOps in the menu bar, then Releases. Click your draft release in the list. Check its repository, tag, and notes. Click Edit if anything needs correction. When the draft is ready, click Publish.
7. In the published release’s Assets section, click the download icon beside the source-code ZIP. Extract it in your file manager and open src/weather.js. Confirm that tempNow receives reading.tempC directly. This checks that the release contains your fix.

Your release now points to the reviewed code, and its notes identify the issue and PR. Keep it as a practice example; there is no need to make it the repository’s latest release.

Recover and repeat

What you see	What to check
Local tests cannot start	Run node --version, check the terminal folder, and confirm the kit’s files were extracted beside index.html.
No DevOps items	Click DevOps in the menu bar, then Configure. Check the source and account for the missing category.
No Actions run	Confirm Actions is enabled for the repository and that the committed workflow is in .github/workflows/. Check its branch filters. Organization policies can restrict which actions run.
Push rejects the workflow file	Read the authentication error. The GitHub credential must be allowed to update workflow files; reconnect with the needed access.
Green locally, red remotely	Compare commits, inspect the failed step, and verify that all reviewed files were committed and pushed.
Merge is unavailable	Read the PR’s reason. Resolve conflicts, wait for checks, or obtain the required review.
Issue stays open	Check the exact issue number, closing keyword, default branch, and repository auto-close setting. Verify the fix before closing it manually.
Release tag already exists	Choose a new practice tag. Do not move an existing published tag for this exercise.

For another rehearsal, create a new sample folder and practice repository with a new name. This restores the deliberate bug without rewriting the completed repository’s history.