feat: output action graph without execution
Opened this issue · 2 comments
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 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
#651, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAAcA79h0sRI4qd9WEwnllz6L32S62Nnks5q50iQgaJpZM4KmIUO
.
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 :-)