Pipeline setup recommendation

[igiona]

Hi everyone

I'm starting exploring the Nuke build system and so far it looks really great, congrats to the coders 👏 !

I'm hitting now the "pipeline creation" step, and I'm wondering: what are the recommendation here?

Nuke targets are likely depending on each other (e.g. Test => Compile => Restore), these dependencies can be reflected in the pipeline? As per the (very few actually) examples I saw around, most people have a single-step-pipeline which does everything up to deploying... is this really the "nuke approach"?
Ideally, I would prefer to have separated steps in the pipeline to have a better/simpler/more direct overview on what went wrong.

The only way to achieve this that I see would be to remove the Nuke-targets-interdependencies (at least in the build-server use case).
Is there any better way?

Many thanks in advance!
Giona

[valadas]

Well, it is up to you. I used to have multiple pipelines (github actions) based on some branch conditions, etc.

Now I have a CI action only and then in Nuke I do stuff conditionally depending on the branch/tag, etc. I prefer it that way as I have everything in the build.cs now.

[igiona]

Thanks for your answer @valadas .
Sure, I definitely see the value of your current approach. Still I see the value of different steps on the server though.

I was somehow wondering weather Nuke could:

• automatically adapt it's "depends on" at runtime depending on where it runs
• generate the pipeline such as the local and server build work in the same way

The goal surely should be to have everything in build.cs and server/local build that ends with the same results.

[valadas]

Well I don't have your specifics but if you use DependsOn in a semantically correct way, then whatever task you are running in each pipeline should depend on it and there would be no reason to make that conditional...

[igiona]

Consider a pipe which need to run a Build job, a Test job, and a test Coverage.
If I configure Nuke with the proper DependsOn, I would have (pls correct me if I'm wrong):

Test depends on Build
Coverage depends on Test

If I run this in a single pipeline step, Nuke will run:

• Build
• Test
• Coverage

If I split the steps in multiple ones, Nuke will run:

• Build
• Build, Test
• Build, Test, Coverage

The penalty for the multiple Build is probably small (if the steps share the same build output, a thing which I'm not really sure about on Bitbucket pipelines, need to check this).
The penalty for running the Test step 2 times is potentially huge, since Nunit will execute the whole tests twice.

Am I missing something?

[valadas]

Am I missing something?

So I guess my first question is why would you want to split that into different pipepelines ?

Whatever the answer to that is (a condidition) then you can put that condition into Nuke...

Just my opinion...

[igiona]

I guess it's not due to a technical reason, I believe that it makes the developers life's easier when they have to "debug" a pipeline failure.
If the see "oh, I broke the tests" they can directly click on the test-step output instead of having to navigate through a bunch of non-relevant logs.
If this comes at the price of higher Nuke "script" maintenance and higher pipeline time-usage, I guess the single step wins.

Thanks for your time!