Skip to content

Commit

Permalink
refactoring scripts so the build server can run each in-step
Browse files Browse the repository at this point in the history
  • Loading branch information
@shiftkey
shiftkey committed Nov 26, 2013
1 parent d7634c1 commit 7c64e06
Show file tree
Hide file tree
Showing 3 changed files with 61 additions and 12 deletions.
13 changes: 13 additions & 0 deletions build.cmd
View file
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,19 @@ IF NOT [%1]==[] (set TARGET="%1")
SET BUILDMODE="Release"
IF NOT [%2]==[] (set BUILDMODE="%2")

:: because we want to run specific steps inline on qed
:: we need to break the dependency chain
:: this ensures we do a build before running any tests

if TARGET=="Default" (SET RunBuild=1)
if TARGET=="RunUnitTests" (SET RunBuild=1)
if TARGET=="RunIntegrationTests" (SET RunBuild=1)
if TARGET=="CreatePackages" (SET RunBuild=1)

if "%RunBuild%"=="" (
"tools\FAKE.Core\tools\Fake.exe" "build.fsx" "target=BuildApp" "buildMode=%BUILDMODE%"
)

"tools\FAKE.Core\tools\Fake.exe" "build.fsx" "target=%TARGET%" "buildMode=%BUILDMODE%"

rem Bail if we're running a TeamCity build.
Expand Down
17 changes: 12 additions & 5 deletions build.fsx
View file
Original file line number Diff line number Diff line change
Expand Up @@ -131,14 +131,21 @@ Target "CreateOctokitReactivePackage" (fun _ ->

Target "Default" DoNothing

Target "CreatePackages" DoNothing

"Clean"
==> "AssemblyInfo"
==> "CheckProjects"
==> "BuildApp"
==> "UnitTests"
==> "IntegrationTests"
==> "CreateOctokitPackage"
==> "CreateOctokitReactivePackage"
==> "BuildApp"

"UnitTests"
==> "Default"

"IntegrationTests"
==> "Default"

"CreateOctokitPackage"
"CreateOctokitReactivePackage"
==> "CreatePackages"

RunTargetOrDefault "Default"
43 changes: 36 additions & 7 deletions script/cibuild.ps1
View file
Original file line number Diff line number Diff line change
Expand Up @@ -35,6 +35,17 @@ function Die-WithOutput($exitCode, $output) {
exit $exitCode
}

function Dump-Error($output) {
$exitCode = $LastExitCode

$errors = $output | Select-String ": error"
if ($errors) {
$output = "Likely errors:", $errors, "", "Full output:", $output
}

Die-WithOutput $exitCode $output
}

function Run-Command([scriptblock]$Command, [switch]$Fatal, [switch]$Quiet) {
$output = ""
if ($Quiet) {
Expand Down Expand Up @@ -81,16 +92,34 @@ else {

Write-Output "Building Octokit..."
Write-Output ""
$output = .\tools\FAKE.Core\tools\Fake.exe "build.fsx" "target=Default" "buildMode=Release"
$output = & .\tools\FAKE.Core\tools\Fake.exe "build.fsx" "target=BuildApp" "buildMode=Release" 2>&1
if ($LastExitCode -ne 0) {
$exitCode = $LastExitCode
Dump-Error($output)
}

$errors = $output | Select-String ": error"
if ($errors) {
$output = "Likely errors:", $errors, "", "Full output:", $output
}
Write-Output "Running unit tests..."
Write-Output ""
$output = & .\tools\FAKE.Core\tools\Fake.exe "build.fsx" "target=UnitTests" "buildMode=Release" 2>&1
if ($LastExitCode -ne 0) {
Dump-Error($output)
}

Die-WithOutput $exitCode $output
Write-Output "Running integration tests..."
Write-Output ""
$output = & .\tools\FAKE.Core\tools\Fake.exe "build.fsx" "target=IntegrationTests" "buildMode=Release" 2>&1
if ($LastExitCode -ne 0) {
Dump-Error($output)
}

Write-Output "Creating NuGet packages..."
Write-Output ""
$output = & .\tools\FAKE.Core\tools\Fake.exe "build.fsx" "target=CreateOctokitPackage" "buildMode=Release" 2>&1
if ($LastExitCode -ne 0) {
Dump-Error($output)
}
$output = & .\tools\FAKE.Core\tools\Fake.exe "build.fsx" "target=CreateOctokitReactivePackage" "buildMode=Release" 2>&1
if ($LastExitCode -ne 0) {
Dump-Error($output)
}

$exitCode = 0
Expand Down

12 comments on commit 7c64e06

@forki
Copy link
Contributor

@forki forki commented on 7c64e06 Nov 27, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like reinventing the target dependencies in powershell.
I assume it has something to do with QED, but can you explain the problem? Maybe we can find a solution in FAKE.

/cc @half-ogre

@shiftkey
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@forki I wanted to run build steps independent of eachother, for a couple of reasons:

  • hide the build output if the step is successful
  • running steps explicitly makes it easier to identify the step that fails, and then show the output for that specific step
  • tweaking builds steps to create a shorter build step when running locally

@forki
Copy link
Contributor

@forki forki commented on 7c64e06 Nov 27, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hide the build output if the step is successful

That's interesting. We tried to cache output data, but in practice we sometimes look on the live output in order to identify problems. At the moment I tend to trace as much as possible. What's the reason you want to hide it?

@shiftkey
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm making a broad generalization here that "on the build server you only really care about output when things go wrong"

@forki
Copy link
Contributor

@forki forki commented on 7c64e06 Nov 27, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep that's what I meant. But adding another possible error source is maybe not a good idea.

That said, if we want to support parallel targets again (see fsprojects/FAKE#201) then caching the target output is one step in this direction.

We could support such a mode in FAKE if that helps.

@shiftkey
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I do love the goal of having one big build chain that runs every time, the way it enforces prerequisites means that I can't run individual steps.

It's a bit Danger Zone but I'm not that fussed by it.

Thoughts?

@half-ogre
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm making a broad generalization here that "on the build server you only really care about output when things go wrong"

I don't really feel this way. When the build is green, I ignore it all, so if it's there it'll just be ignored anyway.

@shiftkey
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So do we actually care about the build output being nicely formatted like this?

STEP: Running build command.
Running powershell.exe -ExecutionPolicy RemoteSigned .\script\cibuild.ps1 in C:\Users\half-ogre\GitHub\qed\bin\Debug\.repositories\octokit\octokit.net
Installing FAKE...

Installing 'FAKE.Core 2.2.0.0'.
Successfully installed 'FAKE.Core 2.2.0.0'.
Building Octokit...

Running unit tests...

Running integration tests...

Creating NuGet packages...
Done

How would you like it to be presented?

@half-ogre
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shiftkey I don't feel strongly about it, at least yet. At the moment I just want to see it working.

@forki
Copy link
Contributor

@forki forki commented on 7c64e06 Nov 28, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought about this for a while and I think it's not good to hide build output. When something goes wrong I need the whole output since the error is not always in the last target but often hidden somewhere else.

I propose a different strategy. Teamcity uses different tracing levels to indicate the importance of a build output line. By default only important lines and errors are shown. But if you want you can always press "display all messages".

@forki
Copy link
Contributor

@forki forki commented on 7c64e06 Nov 28, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw: a lot of the FAKE tasks are already optimized in this way.

@haacked
Copy link
Contributor

@haacked haacked commented on 7c64e06 Dec 2, 2013

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I propose a different strategy. Teamcity uses different tracing levels to indicate the importance of a build output line. By default only important lines and errors are shown. But if you want you can always press "display all messages".

I like that.

Please sign in to comment.