search

constabulary / gb

gb, the project based build tool for Go
https://getgb.io/
MIT License
2.15k stars 150 forks source link

feat: output action graph without execution #651

Open stephanheinze opened 7 years ago

stephanheinze commented 7 years ago

The dotfile produced by gb build -dotfile build.dot is quite cool.

Given a project with multiple commands (multiple 'main' packages), I'd like find out which of them would be build with next gb build run and which are quite fine against the actual cache.

Is there any chance to give the build command an dry-run option to produce no compiled/linked code but the action graph? Or just the package list of the to-be-build-packages on stdout when dry-run is given but no dotfile requested.

davecheney commented 7 years ago

you can do this with gb list

On Wed, 2 Nov 2016, 01:11 Stephan Heinze notifications@github.com wrote:

The dotfile produced by gb build -dotfile build.dot is quite cool.

Given a project with multiple commands (multiple 'main' packages), I'd like find out which of them would be build with next gb build run and which are quite fine against the actual cache.

Is there any chance to give the build command an dry-run option to produce no compiled/linked code but the action graph? Or just the package list of the to-be-build-packages on stdout when dry-run is given but no dotfile requested.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/constabulary/gb/issues/651, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAcA79h0sRI4qd9WEwnllz6L32S62Nnks5q50iQgaJpZM4KmIUO .

stephanheinze commented 7 years ago

Not exactly: List lists packages imported by the project.

I do not want to know what packages are imported - I want to know what packages will be build.

gb's cool feature is to build only those artifacts that experienced change in source files or in dependencies. Given a gb project providing 2 commands (separate executables) sitting in src/cmd/foo and src/cmd/bar a call of gb build in the project's root will build those 2 commands and pack them into bin/foo and bin/bar. A second call of gb build (without -f) will build nothing. After a change in src/cmd/foo/main.go a third call of gb build will build foo only and leave bar untouched.

I got a project with lot of commands which will be packed into separate docker images in later stages. And I do not want to start all those pipelines - just those with a changed executable and not those which are still up-to-date.

I hope you could follow :-)