goyek / goyek

Task automation Go library

Home Page:https://pkg.go.dev/github.com/goyek/goyek/v2

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add global state for convenience

pellared opened this issue · comments

Why

Acting on global flow may be:

  • handy when creating "reusable" workflows as we can define tasks on a commonly known shared flow
  • more convenient as usually the program only contains one flow anyway

This is probably why packages like flag and log packages have similar API.

What

  • Add Global() returning the unexported *Flow variable.
  • Add functions for all Flow methods.

After that someone could create some reusable task and flag:

package workflow

var verbose = flag.Bool("v", false, "print all tasks and tests as they are run")

// Test task runs go test with race detector and coverage for all packages.
var Test = goyek.Define(goyek.Task{
	Name:  "test",
	Usage: "go test",
	Action: func(tf *goyek.TF) {
		v := ""
		if *verbose {
			v = "-v"
		}
		Exec(tf, dirRoot, "go test "+v+" -race -covermode=atomic -coverprofile=coverage.out ./...")
	},
})

// Verbose flag is used by test task to control verbosity.
func Verbose() bool {
	return *verbose
}

func init() {
	flag.CommandLine.SetOutput(goyek.Output())
}

Then it could be used like this

package main

import "github.com/myorg/workflow"

func main() {
	goyek.SetDefault(workflow.Test)
	flag.Parse()
	goyek.Main(flag.Args())
}

Nice! I like the simplicity. The difference I see here is you still need to define the task in your main file. That differs from mage in that discovers via a magic comment above import.

Pros and cons of course just comparing. I do like the brevity of the new proposal though!

The difference I see here is you still need to define the task in your main file.

This is not true. The test task is defined in another package (called workflow)

The difference I see here is you still need to define the task in your main file.

This is not true. The test task is defined in another package (called workflow)

Ok. I saw it mentioned in setting as default task. My mistake.

It seems like the compromise for globals is what's needed for this type of useability. I know we typically try to avoid globals but seems like the alternative is magic it seems like the compromise for globals is what's needed for this type of flexibility. Mage choose magic comments and AST parsing. Different approaches.

Not versed in cobra but I could see that model being more well known among Gophers.