Better UX for gale as lib

[aweris]

Currently gale executed by it's own wrapper like:

Current usage of gale:

gale.New(&cfg, client).
	WithModifier(func(container *dagger.Container) (*dagger.Container, error) {
		// create a file in the container to use for artifact upload
		container = container.WithNewFile("/foo/bar.txt", dagger.ContainerWithNewFileOpts{
			Contents:    "Hello World",
			Permissions: 0600,
		})

		// bind artifact service to the container
		container = container.WithServiceBinding("artifact", services.ArtifactService(client))

		// mock run id and runtime variables
		container = container.WithEnvVariable("GITHUB_RUN_ID", "1")
		container = container.WithEnvVariable("ACTIONS_RUNTIME_TOKEN", "test")
		container = container.WithEnvVariable("ACTIONS_RUNTIME_URL", "http://artifact:8080/")

		// enable debug mode
		container = container.WithEnvVariable("RUNNER_DEBUG", "1")

		return container, nil
	}).
	WithStep(&model.Step{Uses: "actions/upload-artifact@v2", With: map[string]string{"name": "test", "path": "/foo/bar.txt"}}, false).
	WithStep(&model.Step{Uses: "actions/download-artifact@v2", With: map[string]string{"name": "test"}}, false).
	WithStep(&model.Step{Run: "cat bar.txt"}, false).
	Exec(context.Background())

This approach creates relatively simpler usage for when working on Github Actions but it makes really hard to combine with dagger.Container workflows or use custom action support in your container.

Instead of using the wrapper option, we could use a collection of atomic operations like:

dagger.Container().
  From(image).
  With(gale.AddStep(&gale.Step{...}).
  With(gale.AddStep(&gale.Step{...}).
  With(gale.Exec{...}).
  Stdout(ctx)

[aweris]

Some thoughts about the topic. Just random thoughts about gale on a higher level. Not finalized version yet

Improve DX of the project

The easiest method for setting up the dagger container is utilizing the 'dagger.WithContainerFunc' function. This function requires a function that will be executed using the 'dagger.With' function.

The easiest method to standardize this process in the library is to create an interface that includes WithContainerFunc, and then implement this interface for all configurable components in the gale like:

Interface:

// Configurator defines an interface that can be implemented to configure the container.
type Configurator interface {
	// WithContainerFunc is a function that can be used to configure the container.
	WithContainerFunc(*dagger.Container) *dagger.Container
}

An element:

var _ Configurator = new(Job)

type Job struct {
	// job-related data
}

func (j *Job) WithContainerFunc(container *dagger.Container) *dagger.Container {

	// configure the container here

	return container
}

A simple wrapper to improve readability:

func Configure[T Configurator](t T) dagger.WithContainerFunc {
	return t.WithContainerFunc
}

Usage:

container = container.With(gale.Configure(job))

Topics

These is the main topics we should consider when we re-design DX of the library.

Environment

The execution environment contains tools, services, and configurations to run Github Actions Workflows. This is the part eventually integrated with #project-gale

Configuration

Configuration of the execution environment, repository, and workflow. This is one of the most complicated parts of the library. We need this to customize the environment and keep it in sync with actual GHA runners.

Job

Representation of the Github Actions Job in gale. Mostly Load / Build or Customize Github Actions Jobs with gale compatible format. We should re-think our interactions with jobs here as well.

Step

Representation of the Github Actions steps. Atomic execution unit for gale. This can be part of the custom action, job, or individual executor for gale environment.

[aweris]

it's not meaningful anymore