Skip to content
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

'Simple' artifacts based on package specifications #160

Open
hbjydev opened this issue Feb 16, 2025 · 1 comment
Open

'Simple' artifacts based on package specifications #160

hbjydev opened this issue Feb 16, 2025 · 1 comment
Labels
enhancement New feature or request

Comments

@hbjydev
Copy link
Member

hbjydev commented Feb 16, 2025

It'd be cool to have a sort of file spec for building simple Vorpal artifacts, similar in nature to RPM specs files.

The idea, using the artifact structure in the README as a base for this, would be a file that looks like this:

# ./Vorpalfile
vorpalfile = 1

name = "example"
systems = ["aarch64-linux", "aarch64-macos"]

[[sources]]
name = "example"
path = "."

[[steps]]
entrypoint = "/bin/bash"
script = 'echo "hello, world!" > $VORPAL_OUTPUT/hello_world.txt'

Then, you could just use Vorpal's CLI to read this as a form of SDK input, sort of like this;

$ vorpal artifact --from-file=./Vorpalfile
...

This would be an interesting thing to play with I think, and would probably help simpler projects adopt Vorpal, before they need to adopt an SDK.

@hbjydev hbjydev added the enhancement New feature or request label Feb 16, 2025
@erikreinert
Copy link
Member

Thank you for the suggestion! This is an interesting idea and I have toyed around having a "static" interface that doesn't require the SDK (it's an attractive idea).

With that being said, the SDK is kind of required right now. Why? Because it does all of the source and artifact configuration hashing before handing them off to the CLI via the GRPC service. When the SDK runs in the language of your choice, it has logic in it to transform ArtifactSource types to ArtifactSourceId types then adds those ArtifactSourceId transforms to the Artifact configurations before transforming those configurations to ArtifactId types:

flowchart LR
    A[ArtifactSource] --> B[ArtifactSourceId]
    C[ArtifactSource] --> D[ArtifactSourceId]
    B --> E[Artifact]
    D --> E[Artifact]
    E --> F[ArtifactId]
Loading

The reason the ArtifactSourceId types are injected into the Artifact configuration is so when evaluated to an ArtifactId it is consistently hashed properly. This was basically inspired somewhat by Input and Output types in Pulumi.

So, why is all of this done in the SDK? Because the SDK provides a GRPC service which basically serves as a data store for the CLI to use. To de-duplicate (since artifacts can reference artifacts), we use the ArtifactId and ArtifactSourceId as look ups and provide a map of references for the entire configuration.

Here are some places to note:

Let me know if this helps!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants