Skip to content

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.

Sign up for GitHub

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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
+146 −0
Open

Spin Improvement Proposal: Supporting multiple build profiles #3075

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
fb1558d
Spin Improvement Proposal: Supporting multiple build profiles
tschneidereit Apr 1, 2025
b3c8ef5
Address review feedback
tschneidereit Apr 5, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
141 changes: 141 additions & 0 deletions docs/content/sips/023-build-profiles.md
View file
Open in desktop
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>)

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" }
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
Copy link
Collaborator

Choose a reason for hiding this comment

The 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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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 spin up imply spin build.

This is the behavior cargo run has, and it makes sense to me. Cargo of course has the benefit of having much deeper understanding of what a build implies, but maybe that's not actually key here?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

spin up isn't like cargo run though. It's more like wasmtime run. It cares only about the presence of the binary; its job is to get the binary up and running as quickly as possible.

(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.

## 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.

## 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.

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`.

I’m not proposing this alternative because the benefits seem much smaller than the downsides.
Loading