full-day workshop: Make the generated devcontainer startup portable and non-blocking

Open
#263 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
flask, python, shell
Domain
developer-experience, devops

Research direction

Start with content/full-day/3-codespaces.md and app/scripts/start-app.sh; inspect how postStartCommand is generated and how the script handles both services. Test with a repository name other than pets-workshop and a Codespace stop/start, verifying lifecycle completion, visible Flask and Astro logs, predictable restarts, and no duplicate processes.

Written by the indexing model from the issue text.

Description

priority: P0

Problem

Step 0 allows a repository name chosen by the learner or workshop leader, but content/full-day/3-codespaces.md hard-codes this startup command:

"postStartCommand": "chmod +x /workspaces/pets-workshop/app/scripts/start-app.sh && /workspaces/pets-workshop/app/scripts/start-app.sh"

It fails when the generated repository is not named pets-workshop. In addition, start-app.sh deliberately waits for both application processes and does not exit, so using it directly as a lifecycle command can leave the Codespaces startup task running indefinitely.

Suggested change

Use the dev container workspace variable or a workspace-relative command, and launch the long-running application through a non-blocking mechanism appropriate for dev containers.

Acceptance criteria

  • The command works for any repository name allowed by Step 0.
  • The dev container lifecycle command completes after starting the services.
  • Flask and Astro logs remain accessible to the learner.
  • Both services restart predictably after a Codespace stop/start.
  • Service cleanup does not leave duplicate processes.
Dominant language
Python
Stars
80
Forks
161
Avg merge
31m
Merged PRs (30d)
1

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github-samples/pets-workshop

All issues in github-samples/pets-workshop

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.