fermyon / cloud-plugin Goto Github PK

The actions-rs/* GH actions are no longer maintained and thus flood workflow summaries with deprecation warnings (see fermyon/spin#1697 for some more background).

We should find a suitable substitute (in 1697, we dropped down to invoking the rustup/cargo commands directly.)

This repository has very few unit tests. Ideally, adding a command and new api calls would come with a suite of tests. If we create a trait for the cloud Client, we can use mockall to mock api calls and ensure our commands are sending and handling data as expected.

When using the --since flag, I always get the latest 10 logs, not the logs since the timeframe desired.

When running sqlite commands the name of the database is required. This makes it difficult to run ci deployments using migrations without using awk.

❯ spin cloud sqlite list
Databases (1)
blissful-sheep (default)

❯ spin cloud sqlite execute default @highscore/migration.sql
Error: No database found with name "default"

❯ spin cloud sqlite execute blissful-sheep @highscore/migration.sql

The work around is

❯ spin cloud sqlite execute "$(spin cloud sqlite list | awk '/default/{print $1}')" @highscore/migration.sql

Given the help text below, I would have expected the command to give me the version of the app, not the version of the plugin.

> spin cloud apps list --help
spin-cloud-apps-list 0.2.0 (df0e822 2023-09-13)
List all the apps deployed in Fermyon Cloud

USAGE:
    spin cloud apps list [OPTIONS]

OPTIONS:
        --environment-name <environment-name>
            Deploy to the Fermyon instance saved under the specified name. If omitted, Spin deploys
            to the default unnamed instance [env: FERMYON_DEPLOYMENT_ENVIRONMENT=]

    -h, --help
            Print help information

    -V, --version
            Print version information

> spin cloud apps list -V
spin-cloud-apps-list 0.2.0 (df0e822 2023-09-13)

it would be good to do some pre-deployment validation to help give users information to sign-up for SQLite private beta. We could bake this into spin cloud deploy as @macolso suggests:

NoOps SQL DB is currently in private beta. Please visit our developer documentation for instructions on how to request access: https://developer.fermyon.com/cloud/noops-sql-db

The current instructions for local build and test seem quite manual - would we be open to having an option for spin pluginify (https://github.com/itowlson/spin-pluginify) for local dev? How about if it were in the official plugins registry?

With OCI enabled, I cannot deploy anything unless I add the --insecure flag.

><> cloud login --url http://cloud.local.fermyon.link
What authentication method does this server support?

1. Sign in with GitHub
2. Sign in with a username and password

Enter a number: 1

Copy your one-time code:

g6cHTPH6

...and open the authorization page in your browser:

http://cloud.local.fermyon.link/device-authorization

Waiting for device authorization...
Device authorized!
><> cloud deploy
Uploading registry.cloud.local.fermyon.link/fermyon-developer:0.1.0-rad1a18b4 to Fermyon Cloud...
Error: cannot push Spin application

Caused by:
    0: error sending request for url (https://registry.cloud.local.fermyon.link/v2/fermyon-developer/blobs/uploads/): error trying to connect: tcp connect error: Connection refused (os error 111)
    1: error trying to connect: tcp connect error: Connection refused (os error 111)
    2: tcp connect error: Connection refused (os error 111)
    3: Connection refused (os error 111)

Learn more at https://developer.fermyon.com/cloud/faq

This is resolved if I add the --insecure flag to cloud login.

If the Cloud URL is an HTTP URL, should we assume the OCI registry is also using HTTP? IMO we should probably assume the connection is "insecure" when we're logging in via HTTP.

The cloud api supports defining a name for an application, when creating it. Today this is inferred from the spin.toml file on deployment.

It would be great to be able to define this as part of deployment. E.g. spin cloud deploy --name my-app

For example, Spin's version output:

$ spin --version
spin 1.3.0-pre0 (c2c6e81 2023-05-26)

ref https://github.com/fermyon/spin/blob/c2c6e819b66b4bea407ddde7776b7ec148d86d01/build.rs#L17-L28

--buildinfo, --no-buildinfo , -d/-staging-dir and -e/--deploy-existing-bindle

This was flagged to me by @tschneidereit. It appears that, when you deploy an application, if any required variable is not either set during deployment or already set in the Cloud, the deployment goes ahead anyway, and then fails at runtime when the application requests the required variable.

A possible solution is to ask the Cloud at deploy time what variables are already defined, combine that with the list of variables provided in the deploy command, and cross-check that against the application's required variables. If any are missing, we could prompt for values or fail the deployment.

(There is a possible race condition with doing it on the client, if a user sneakily deletes a variable from the Cloud between the "list variables" query and the deployment, but that's not a big concern.)

Would spin pluginify be a good fit to replace the current script used to create new plugin release manifests? It would be great to use the same tool both in local dev mode and in CI.

We'd need pluginify to:

• Create a manifest with all supported os/arch combos for a given release version and download url (not sure if this can already be accomplished by the tool today)
• Support overriding the following values in spin-pluginify.toml when creating a manifest as described above: version and homepage (to support canary releases for the former and support publishing the plugin from forks for the latter)

Thoughts @itowlson @karthik2804 ?

Ran into this accidentally while trying to fix the same (?) problem with cloud-start:

error[E0635]: unknown feature `proc_macro_span_shrink`

Seems to be this bug in proc-macro2: dtolnay/proc-macro2#398

...but cargo update -p proc-macro2 causes a whole host of other errors, so it looks like fixing this one might be harder than fixing cloud-start.

When logging into a Fermyon Cloud instance that uses HTTP, spin deploy should be reaching out to http://registry..., not https://registry....

><> spin login --url http://cloud.local.fermyon.link

Copy your one-time code:

Zbrbrb0g

...and open the authorization page in your browser:

http://cloud.local.fermyon.link/device-authorization

Waiting for device authorization...
Device authorized!
><> spin deploy
Uploading spin-key-value version 1.0.0 to Fermyon Cloud...
Error: cannot push Spin application

Caused by:
    0: error sending request for url (https://registry.cloud.local.fermyon.link/v2/spin-key-value/blobs/uploads/): error trying to connect: tcp connect error: Connection refused (os error 111)
    1: error trying to connect: tcp connect error: Connection refused (os error 111)
    2: tcp connect error: Connection refused (os error 111)
    3: Connection refused (os error 111)

Learn more at https://developer.fermyon.com/cloud/faq

https://github.com/fermyon/cloud-plugin/actions/runs/8351045669/job/22858794915

Error occurs after “create plugin manifest”:

Error: Failed to CreateArtifact: Received non-retryable error: Failed request: (409) Conflict: an artifact with this name already exists on the workflow run

looks like there are still two actions uploading to the “cloud” artifact.

If I cancel the spin deploy command before it finishes, the deployment can end up in an incomplete state. The bindle may be uploaded, but no application has been created.

We should figure out a way to capture that signal and roll back any changes (if possible).

I can spin login but not logout.

Current workaround is messy - looking through chats I can see some discussion of this - and found this to be true:

we use dirs::config_dir (https://crates.io/crates/dirs) for this

dirs::config_dir();
// Lin: Some(/home/alice/.config)
// Win: Some(C:\Users\Alice\AppData\Roaming)
// Mac: Some(/Users/Alice/Library/Application Support)

I's like to just get the latest 100 log lines, but there is no flag to do that in cloud logs today. I can only rely on --since which expects a time frame.

The --environment-name option originally existed for spin deploy, to allow users to choose between Fermyon Platform instances. In the cloud plugin, the only instance of the cloud is, er, the cloud, and the only case for custom environments is for folks within Fermyon working on the cloud. Hiding the option would get a wordy and obscure option out of users' faces; we could retain it for dev-test purposes but document it in the repo rather than in the CLI.

The "Run Rust audits" action has been failing for several weeks now. it is failing because it is installing cargo vet 0.5.0, however the config files all require v0.7.0. The latest version is v0.8.0.

fermyon/spin#1460 raises a similar issue - we should figure out a way to ensure the vetted list is maintained, or drop it from the project.

Take an app named var with a host variable that simply prints the host value:

...
[variables]
host = {required = true}

[[component]]
id = "hello"
source = "target/wasm32-wasi/release/http_rust.wasm"
description = "A simple component that returns hello."
[component.trigger]
route = "/hello"
[component.config]
host = "{{ host }}"

If you delete the variable with spin cloud variables delete host --app var, you should no longer see it in spin cloud variables list --app var and the app will throw a Not Found error as expected. However, when you reset the variable (spin cloud variables set host=again --app var, while the variable can be listed via the CLI, the app continues to throw a Not Found error.

Note: this is using this version of the plugin #16

Currently, Spin appears to be - from code - sending e.g. cloud/1.3.0 as the user-agent. This plugin will also - currently - be sending cloud/*. It would be nice if it sent something more detailed, like cloud-plugin/${CARGO_PKG_VERSION} spin/${SPIN_VERSION} (SPIN_VERSION is set by the plugin runner).

from fermyon/installer#128

If the user runs spin login --url (which is still allowed), it drops them prompt_for_auth_method (https://github.com/fermyon/cloud-plugin/blob/main/src/commands/login.rs#L430-L442).

This asks them to choose 1 or 2. If they choose 2, it prints "invalid input" and asks again.

https://github.com/fermyon/cloud-plugin/actions/workflows/release.yml

It's having a problem overwriting the canary release asset.

From spin @ main after adding default for base from fermyon/spin#1803 :

➜  http-rust git:(main) ✗ spin deploy
Warning: You're using a pre-release version of Spin (1.6.0-pre0). This plugin might not be compatible (supported: >=1.3). Continuing anyway.
Error: Cannot read spin.toml manifest from "spin.toml"

Caused by:
    could not load application trigger parameters: missing field `base` at line 14 column 1

Learn more at https://developer.fermyon.com/cloud/faq

cc/ @lann

I just installed Spin in WSL (Ubuntu 20.04 on Windows), and am getting this error on spin login:

/home/janpio/.local/share/spin/plugins/cloud/cloud: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /home/janpio/.local/share/spin/plugins/cloud/cloud)

Am I doing it wrong (besides using Windows...)?
Any idea how I can overcome this?

• Spin version (spin --version): spin 1.5.0 (ca08dd9 2023-09-13)
• Installed plugin versions (spin plugins list --installed):

cloud 0.2.0 [installed]
js2wasm 0.6.0 [installed]
py2wasm 0.3.0 [installed]

In reference to #8. A command to list all application in the cloud, would be good, to easily retrieve a name of an existing application. E.g., spin cloud app list.

We are deprecating this terminology due to confusion over "NoOps SQL" and "NoSQL."

The Spin CLI recently added an environment variable SPIN_ALWAYS_BUILD (also available via a spin up --build option) to force a spin build before running.

Could we also support this on spin cloud deploy please?

Spin plans to release SQLite support in v1.4. At that stage, Cloud will not yet support SQLite. Therefore, cloud deploy should prevent deployment of applications that use SQLite databases (that is, where any component declares a non-empty sqlite_databases list in the manifest).

• org.freedesktop.secrets DBus API on Linux (supported by Gnome and KDE at least)
• macOS Keychain
• Windows Credential Manager

Is your feature request related to a problem? Please describe.
I can't clean up a deployment I created within the workflow for the CLI

Describe the solution you'd like
I would like to be able to run "spin destroy" and have my deployment removed from Fermyon Cloud

Describe alternatives you've considered
The only alternative is logging into the UI and doing it manually today. A plugin could be created to handle this (and other cloud tasks like listing, etc). I think this should either be in core CLI or all the cloud stuff including this moved off.

It would be beneficial to be able to tail logs from the CLI when debugging issues, rather than needing to open the Cloud UI - especially when iterating on a deployment.

Example UX:

$ spin cloud logs my-app-name --tail
# continuously tail logs until interrupted 

$ spin cloud logs my-app-name --since=TIMESTAMP
# fetch all available logs since the given timestamp and then exit

$ spin cloud logs my-app-name --reverse
# fetch recent logs with the _newest logs first_

The following scenarios require terminal interaction where a flag such as --accept-defaults should be provided for CI scenarios:

• spin cloud deploy for an app with entries in sqlite_databases (you are prompted to choose a DB)
• spin cloud link sqlite when updating a link
• spin cloud sqlite delete you are prompted to confirm your choice to delete the database

When I deploy an app I see this success message:

Deploying...
Waiting for application to become ready... ready
Available Routes:
  fileserver: https://fw2.fermyon.app (wildcard)

Terminology
This information about component routes lists things in a similar way to what spin does locally with spin up (talking about fileserver, routes). Because this app is now deployed and publicly available, the terminology here might reflect that?

Cloud URL
It would be nice to reference the management URL for the app in the new structure of the Cloud UI, i.e. https://cloud.fermyon.com/app/<appname>/

E.g. deploy success could look something like

Deploying...
Waiting for application to become ready... ready

Available Routes:
  View application:         https://fw2.fermyon.app (wildcard)
  Manage application:       https://cloud.fermyon.com/app/<appname>/

  ^                         ^ (bonus points for tabular indentation formatting)

Works fine locally with spin up but the deploy to cloud fails (see below)

mackenzieolson@MacKenzies-MacBook-Air spin-todo % spin cloud deploy --variable sqlite_username="REMOVED" --variable sqlite_password="REMOVED"
Warning: You're using a pre-release version of Spin (1.6.0-pre0). This plugin might not be compatible (supported: >=1.3). Continuing anyway.
Checking status (https://cloud.fermyon.com/)

Uploading todo-v2 version 0.1.0-r88287985 to Fermyon Cloud...
Deploying...
App "todo-v2" accesses a database labeled "default"
Would you like to link an existing database or create a new database?: Use an existing database and link app to it
Which database would you like to link to todo-v2 using the label "default": amiable-kiwi
App "todo-v2" accesses a database labeled "default"
Would you like to link an existing database or create a new database?: Use an existing database and link app to it
Which database would you like to link to todo-v2 using the label "default": amiable-kiwi
Error: Failed to link database "amiable-kiwi" to app "todo-v2"

Caused by:
    This database and app have already been linked with this label.

Learn more at https://developer.fermyon.com/cloud/faq

[[component]]
id = "todo-api"
source = "target/wasm32-wasi/release/todo.wasm"
allowed_http_hosts = []
sqlite_databases = ["default"]
[component.trigger]
route = "/api/..."
[component.build]
command = "cargo build --target wasm32-wasi --release"
watch = ["src/**/*", "Cargo.toml"]

[[component]]
source = { url = "https://github.com/fermyon/spin-fileserver/releases/download/v0.0.2/spin_static_fs.wasm", digest = "sha256:65456bf4e84cf81b62075e761b2b0afaffaef2d0aeda521b245150f76b96421b" }
id = "fileserver"
files = [{ source = "static", destination = "/" }]
[component.trigger]
route = "/..."

[variables]
sqlite_username = { required = true }
sqlite_password = { required = true }

[[component]]
id = "sql-cli"
source = { url = "https://github.com/karthik2804/spin-sqlite-web-cli/releases/download/v0.0.1/spin-sqlite-web-cli.wasm", digest = "sha256:e0fb024ffaa68e53118a6b45636161d2a43543cf2bd0b6d027d01a34f4ee56e4" }
sqlite_databases = ["default"]
[component.trigger]
route = "/internal/sqlite/..."
[component.config]
sqlite_username = { required = true }
sqlite_password = { required = true }

Describe the bug
The text description for the prompt What would you like to name your database? is overlapping the text input when using the spin deploy command.

Frequency of the bug
Please check one:

• Consistent repro
• Intermittent repro
• No repro

Set-up information
Please share the version of Spin used when the bug occurred. You can find the version of Spin by running spin -V.

spin -V
spin 2.6.0-pre0 (VERGEN_IDEMPOTENT_OUTPUT VERGEN_IDEMPOTENT_OUTPUT)

To Reproduce
Steps to reproduce the behavior:

1. spin deploy

Expected behavior
The ]: should be at the end of the text rather than in the middle of the description.

Screenshots
If applicable, add screenshots to help explain your problem.
(Remember to remove any personally-identifiable information.)
This is the initial problem before typing anything.

This is when I ran it again and typed: TESTKEYVALUESTORENAMEHERE

Additional context
I have had it use some of this text in the name of the keystore, so it is pulling some of these characters into the prompt value.
If I use the backspace the text is removed.

https://github.com/fermyon/spin/blob/b1ac4d8307948bbcd833fc689be3471f8fa174a0/src/commands/deploy.rs#L231

This is a problem in the following scenario:

1. Change application name in spin.toml
2. Run spin deploy
3. Uses old name to find the app id when we expected it to use the new name

Although users will typically need to run spin build before deploying anyways, this is a subtle and confusing bug I think we should avoid.

CC @bacongobbler

I have an application deployed to Fermyon Cloud with a custom domain:

When I call spin deploy, I see the default fermyon.app domain URL.

><> spin deploy
Uploading spin-hello-world version 1.0.0-rc3fe1b7e to Fermyon Cloud...
Deploying...
Waiting for application to become ready........ ready
Available Routes:
  hello: https://spin-hello-world-bacongobbler2.fermyon.app/hello
    A simple component that returns hello.

The expected behaviour should be to see the custom domain:

><> spin deploy
Uploading spin-hello-world version 1.0.0-rc3fe1b7e to Fermyon Cloud...
Deploying...
Waiting for application to become ready........ ready
Available Routes:
  hello: https://helloworld.bacongobbler.com/hello
    A simple component that returns hello.

move async fn get_channel_id_cloud to cloud crate

#58 (comment)

Currently, the release.yml workflow deletes and recreates the canary release first thing, prior to any of the artifacts being ready for attaching. This presents a lengthy window when there are no binaries or cloud.json files attached to the release. This presents problems as the install script for Spin can be used to specify that canary is the desired Spin release, along with all of the default plugins, which includes this one. If the script is run while CI is in progress, some of the expected assets may not be available and thus the script may error out. (See also fermyon/spin#1771)

Update the workflow such that the canary release is only recreated once all assets are ready to be uploaded. There may still be a window of exposure here, but at least it will be much shorter. An effort to fully eliminate, such as using a CDN, is outside of the scope of this ticket.

Did this Rust code:

pub async fn post(req: Request, _params: Params) -> Result<Response> {
    println!("POSTED to INBOX");
    for n in 1..20 {
        println!("{n}: ######################");
    }
...
}

So every time when my post method is hit by request, I am supposed to see 20 of {n}: #### lines.
However actually I am just seeing only first 10 lines.
Guessing --tail option's default 10 value is taking over --follow thing.
Following is working but only showing 10 lines every time when I get new logs.
Tried with both --tail and --follow options (spin cloud logs --follow --tail 100) but still getting only 10 lines.

Discord thread here:
https://discord.com/channels/926888690310053918/1024646765149950022/1186957181887729674

it will be useful to support setting an env variable which can be consumed by spin cloud deploy to do the deployment.