-
Notifications
You must be signed in to change notification settings - Fork 282
Spin Improvement Proposal: Supporting multiple build profiles #3075
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,141 @@ | ||
title = "SIP 023 - Build profiles" | ||
template = "main" | ||
date = "2025-03-31T12:00:00Z" | ||
|
||
--- | ||
|
||
Summary: Support defining multiple build profiles for components, and running a Spin application in with those profiles. | ||
|
||
Owner(s): [till@fermyon.com](mailto:till@fermyon.com) | ||
|
||
Created: March 31, 2025 | ||
|
||
# Background | ||
|
||
Building and running individual components or entire applications in configurations other than the default one is currently difficult to do with Spin: one has to manually edit the `[component.name.build]` tables for some or all components. This is laborious and error-prone, and can lead to accidentally committing and deploying debug/testing/profiling builds to production. | ||
|
||
# Proposal | ||
|
||
This very simple proposal contains three parts: | ||
|
||
1. Adding an optional `[component.name.profile.profile-name]` table to use for defining additional build profiles of a component | ||
2. Adding a `-profile [profile-name]` CLI flag and `SPIN_PROFILE` env var to `spin {build, watch, up}` to use specific build profiles of all components (where available, with fallback to the default otherwise) | ||
3. Adding a (repeatable) `-component-profile name=[profile-name]` CLI flag and `SPIN_COMPONENT_PROFILE="name=[profile-name],..."` env var to use specific profiles for specific components | ||
|
||
## Example | ||
|
||
The following `spin.toml` file shows how these parts are applied: | ||
|
||
```toml | ||
# (Source: <https://github.com/fermyon/ai-examples/blob/main/sentiment-analysis-ts/spin.toml>) | ||
tschneidereit marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
spin_manifest_version = 2 | ||
|
||
[application] | ||
name = "sentiment-analysis" | ||
version = "0.1.0" | ||
authors = ["Caleb Schoepp <caleb.schoepp@fermyon.com>"] | ||
description = "A sentiment analysis API that demonstrates using LLM inference and KV stores together" | ||
|
||
[[trigger.http]] | ||
route = "/api/..." | ||
component = "sentiment-analysis" | ||
|
||
[component.sentiment-analysis] | ||
source = "target/spin-http-js.wasm" | ||
allowed_outbound_hosts = [] | ||
exclude_files = ["**/node_modules"] | ||
key_value_stores = ["default"] | ||
ai_models = ["llama2-chat"] | ||
|
||
[component.sentiment-analysis.build] | ||
command = "npm run build" | ||
watch = ["src/**/*", "package.json", "package-lock.json"] | ||
|
||
# Debug build of the `sentiment-analysis` component: | ||
[component.sentiment-analysis.profile.debug] | ||
source = "target/spin-http-js.debug.wasm" | ||
|
||
[component.sentiment-analysis.profile.debug.build] | ||
command = "npm run build:debug" | ||
watch = ["src/**/*", "package.json", "package-lock.json"] | ||
|
||
[[trigger.http]] | ||
route = "/..." | ||
component = "ui" | ||
|
||
# The `ui` component doesn't have a debug build, so the release build will always be used. | ||
[component.ui] | ||
source = { url = "<https://github.com/fermyon/spin-fileserver/releases/download/v0.0.1/spin_static_fs.wasm>", digest = "sha256:650376c33a0756b1a52cad7ca670f1126391b79050df0321407da9c741d32375" } | ||
tschneidereit marked this conversation as resolved.
Show resolved
Hide resolved
|
||
allowed_outbound_hosts = [] | ||
files = [{ source = "../sentiment-analysis-assets", destination = "/" }] | ||
|
||
[variables] | ||
kv_explorer_user = { required = true } | ||
kv_explorer_password = { required = true } | ||
|
||
[[trigger.http]] | ||
component = "kv-explorer" | ||
route = "/internal/kv-explorer/..." | ||
|
||
[component.kv-explorer] | ||
source = { url = "<https://github.com/fermyon/spin-kv-explorer/releases/download/v0.10.0/spin-kv-explorer.wasm>", digest = "sha256:65bc286f8315746d1beecd2430e178f539fa487ebf6520099daae09a35dbce1d" } | ||
allowed_outbound_hosts = ["redis://*:*", "mysql://*:*", "postgres://*:*"] | ||
# add or remove stores you want to explore here | ||
key_value_stores = ["default"] | ||
|
||
# Uses a pre-built debug version of the component. | ||
[component.kv-explorer.profile.debug] | ||
source = { url = "<https://github.com/fermyon/spin-kv-explorer/releases/download/v0.10.0/spin-kv-explorer.debug.wasm>", digest = ".." } | ||
|
||
[component.kv-explorer.variables] | ||
kv_credentials = "{{ kv_explorer_user }}:{{ kv_explorer_password }}" | ||
|
||
``` | ||
|
||
The application defined in this manifest can be run in various configurations: | ||
|
||
- `spin up`: uses the release/default builds for everything | ||
- `spin up --profile debug`: uses builds of the profile named `debug` of all components that have them, default builds for the rest | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My worry here is the disconnection between the build and run steps. I know that in three months I will be tweaking an app and wondering why my changes aren't showing and it will be because I am building release and running debug or something. This was one of the concerns that stopped us doing this before (maddeningly, I can no longer find the discussion, sorry). Do you believe this is a false consideration, or do you have ways to mitigate it? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yeah, that's a very good point. One, and perhaps the only real one, option is to make This is the behavior There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
(At least that's how it is today. We can, of course, change that; but making it default to building would be a breaking change for certain scenarios. Which is not a blocker, but we'd want to socialise it well in advance of the change.) I'd be concerned about a philosophy of "build everywhere." Okay, I built it to make sure that it typechecked and was warning free, now let me run it, huh, looks like it built again. Push it to a registry, built again; deploy it, built again. For sure Rust components will fairly quickly (and fairly quietly) figure out that the build is a no-op. But rebuilding a single minimal JS component (with no changes) takes more than half a second on my computer, and produces 2/3 of a screen of npm spew Maybe that's an extreme case but it does give me collywobbles about defaulting to rebuilding with every single operation. I do appreciate the consistency guarantees it provides though - after all, even today we have a risk of "oops I forgot to build before pushing"! |
||
- `spin up --component-profile sentiment-analysis=debug`: uses the debug build of just the `sentiment-analysis` component, default builds for everything else | ||
|
||
## Profile-overridable fields | ||
|
||
This proposal is focused on build configurations. As such, the fields that are supported in `[component.component-name.profile.profile-name]` tables are limited to: | ||
|
||
- `source` | ||
- `command` | ||
- `watch` | ||
|
||
This set can be expanded in changes building on this initial support, as adding additional fields should always be backwards-compatible. | ||
|
||
## Profiles are all-or-nothing | ||
|
||
When running an application with a named profile applied, components that don’t define that profile fall back to the default build configuration. The same isn’t true for individual keys in a profile: if e.g. a profile contains the `source` field but no `command` field, running `spin build` will not try to run the default configuration’s build command. | ||
tschneidereit marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## Local testing only | ||
|
||
At least for now, this proposal is focused entirely on local testing: deployment through plugins is not proposed to gain support for a `--profile` flag. | ||
tschneidereit marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
## Backwards-compatibility | ||
|
||
This proposal should be fully backwards-compatible. | ||
|
||
## Implementation concerns | ||
|
||
I can't see any major implementation concerns: this should hopefully be pretty straightforward. | ||
|
||
## Alternatives considered | ||
|
||
Instead of adding generalized profiles support, we could add just a hard-coded `debug` profile. This would simplify the syntax a little bit, but at the cost of flexibility. | ||
tschneidereit marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
We could do so by using syntax such as | ||
|
||
```toml | ||
[component.sentiment-analysis.debug] | ||
... | ||
``` | ||
|
||
and changing the `--profile [profile-name]` flag to instead be `--debug`, and `--component-profile sentiment-analysis=debug` be `--debug-component sentiment-analysis`. | ||
tschneidereit marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
I’m not proposing this alternative because the benefits seem much smaller than the downsides. |
Uh oh!
There was an error while loading. Please reload this page.