Skip to content
This repository has been archived by the owner on Mar 6, 2020. It is now read-only.

feat: output action graph without execution #651

Open
stephanheinze opened this issue Nov 1, 2016 · 2 comments
Open

feat: output action graph without execution #651

stephanheinze opened this issue Nov 1, 2016 · 2 comments

Comments

@stephanheinze
Copy link

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
Copy link
Contributor

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
.

@stephanheinze
Copy link
Author

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 :-)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants