Make first release
donny-dont opened this issue · comments
After talking with @bradrydzewski there are a couple things to keep in mind here before doing an official release.
Should this be drone-plugin-urfave?
The stuff in pkg/plugin is agnostic. It was created from talking to Brad about a low level starting point for plugins. If there does become a plugin-lib in the Drone org then I would assume that this would just target that for the data types.
Should the flag handling be simplified?
Currently there's a ton of const FooFlag names everywhere. Is this useful?
Should there just be a Flag that has everything in it vs having a bunch of little functions that build up to that?
Port some plugins
I plan on migrating drone-slack-blame and drone-github-release to use the library and rewrite drone-nuget to work on Windows. If anyone else could give other plugins a go then we can probably figure out what is and isn't used and modify the library accordingly.
Other stuff
Add as it comes up during development
I would also recommend some minor style changes to the API
package urfave
var Flags = []cli.Flag{ ... }
type Build struct {...}
type Commit struct {...}
type Repo struct {...}
type Stage struct {...}
type Step struct {...}
type System struct {...}
type Semver struct {...}
type Pipeline struct {
Build Build
Commit Commit
Repo Repo
Stage Stage
System System
Semver Semver
}
func FromContext(c *cli.Context) Pipeline {
return Pipeline{
Build: toBuild(c),
Repo: toRepo(c),
...
}
}
func toBuild(c *cli.Context) Build { ...} // return build from urfavecli context
func toCommit(c *cli.Context) Commit { ...}
func toRepo(c *cli.Context) Repo { ...}
func toStage(c *cli.Context) Stage { ...}
func toStep(c *cli.Context) Step { ... }
func toSystem(c *cli.Context) System { ... }
func toSemver(c *cli.Context) Semver { ... }
the end-user of this library would then do this:
Flags: append(urfave.Flags, []cli.Flag{
// my custom flags
}...)
and then
func run(c *cli.Context) {
pipeline := urfave.FromContext(c)
// parse custom flags
// do stuff ...
}
I would prefer to drop the const flag name definitions. Beside that, we could drop the whole FromContext stuff if we use https://godoc.org/github.com/urfave/cli#StringFlag, than we just need to pass the struct of the environment/settings.
After getting to #4 the consts make sense again, that way you can directly see if you try to show a flag that doesn't exist and you could use auto completion.
Question is if we really always want to show this big bunch of options. #4 would simply help to show only specific options.
I also never used all these constants within my projects, but I get that @donny-dont would like to use his IDE for autocompletion and validation that he is using the right flag names.
#7 is pretty nearby to what @bradrydzewski would like to see I think :)
Let's close this issue, we got it working so far :)