Defining Initial Workspace Content
Learn how to structure the `workspace/` directory in your Kit to provide initial files for new Modules.
Defining Initial Workspace Content
When a Module is created from your Kit, it gets its own dedicated Workspace, which is essentially a Git repository. The initial content of this repository is populated from the files and directories you place inside the workspace/
folder within your Kit's source structure.
Purpose of the workspace/
Directory
- Initial State: Provide default configuration files, templates, initial data sets, or scripts that your Module's Tools or Agents might need to function correctly from the start.
- Templates: Include template files (e.g.,
config.json.template
,Dockerfile.template
) that Tools might read, modify, and write back into the Module's live workspace repository. - Examples: Provide example input files or data structures.
- Scripts: Include utility scripts that might be executed by an Tool.
Structure and Content
- Location: Create a directory named
workspace
at the root of your Kit structure. - Contents: Place any files or subdirectories you want to be included in the initial Module workspace inside this
workspace/
directory. The directory structure you create here will be mirrored in the Module's Git repository.
Example Kit Structure showing workspace/
:
When a Module is created from my-data-processor-kit
, its workspace repository (.data/repositories/{module_id}
) will initially contain:
config.json
.gitattributes
input_schemas/event_schema.json
scripts/validate_input.py
- A
.gitignore
file (potentially, based onkit.yaml
settings)
Referencing Workspace Files in kit.yaml
While placing files in workspace/
copies them initially, you can optionally reference specific files or directories within the workspace.files
list in your kit.yaml
. This primarily serves documentation and discoverability purposes (e.g., allowing the ResourceService
to easily list these specific files via the API, which Studio might use).
workspace.files
: List of objects describing key initial files/dirs.path
: Path relative to theworkspace/
directory in your Kit source (and thus relative to the root of the Module's repo).description
: Explains the purpose of the file/directory.
workspace.ignore
: List of patterns added to the.gitignore
file created in the Module's repository, helping keep it clean from logs, temporary files, etc.
Initial Copy vs. Live Files
Remember that the workspace/
directory in your Kit source only defines the initial state. Once a Module is created, its workspace repository is independent. Changes made by Tools within a running Module do not affect the Kit's source workspace/
directory or other Modules created from the same Kit.
Best Practices
- Keep it Minimal: Only include files essential for the Module's initial operation or commonly needed templates. Avoid large datasets or binaries if possible.
- Use Templates: If configuration needs to be customized per-module, provide template files (e.g.,
config.template.json
) and have an initialization Tool read the template, modify it (perhaps with environment variables), and write the finalconfig.json
. - Consider
.gitignore
: Use theworkspace.ignore
setting inkit.yaml
or include a.gitignore
file directly in yourworkspace/
directory to prevent common unwanted files (logs, caches, OS files) from being accidentally committed by Tools. - Document Key Files: Use the
workspace.files
list inkit.yaml
to document the purpose of important initial files.
By carefully defining the initial workspace content, you ensure that Modules created from your Kit start in a consistent and functional state.