Upgraded builds to use psake #24

Closed
wants to merge 14 commits into
from

Conversation

Projects
None yet
3 participants
@ericnewton76
Contributor

ericnewton76 commented Mar 14, 2013

PSake build script currently supports

  • Build
  • Test

Will support

  • Package
  • NugetPackage[Deploy]

will be able to target multiple framework targets, ie 2.0, 3.5, 4.0 since I see some 4.0 specific pull requests pending.

Perhaps we create a branch in your Repo for this? And you can get comfortable with it before committing to master

@ericnewton76

This comment has been minimized.

Show comment Hide comment
@ericnewton76

ericnewton76 Mar 14, 2013

Contributor

Added nuget pack support. NOTE: assembly signing needs to change to allow principals of the project to have the ability to sign the NugetPackages appropriately.

Next update will include nuget deploy and signing by prinicipals

Contributor

ericnewton76 commented Mar 14, 2013

Added nuget pack support. NOTE: assembly signing needs to change to allow principals of the project to have the ability to sign the NugetPackages appropriately.

Next update will include nuget deploy and signing by prinicipals

@tathamoddie

This comment has been minimized.

Show comment Hide comment
@tathamoddie

tathamoddie Mar 14, 2013

Owner

The build server already does all of this.

When a change is merged to the main repo, it's packed and published in less than a minute.

Tatham Oddie
Tiny phone keyboard = tiny message

On 14/03/2013, at 15:03, "Eric Newton" <notifications@github.commailto:notifications@github.com> wrote:

Added nuget pack support. NOTE: assembly signing needs to change to allow principals of the project to have the ability to sign the NugetPackages appropriately.

Next update will include nuget deploy and signing by prinicipals


Reply to this email directly or view it on GitHubhttps://github.com/tathamoddie/System.IO.Abstractions/pull/24#issuecomment-14885612.

Owner

tathamoddie commented Mar 14, 2013

The build server already does all of this.

When a change is merged to the main repo, it's packed and published in less than a minute.

Tatham Oddie
Tiny phone keyboard = tiny message

On 14/03/2013, at 15:03, "Eric Newton" <notifications@github.commailto:notifications@github.com> wrote:

Added nuget pack support. NOTE: assembly signing needs to change to allow principals of the project to have the ability to sign the NugetPackages appropriately.

Next update will include nuget deploy and signing by prinicipals


Reply to this email directly or view it on GitHubhttps://github.com/tathamoddie/System.IO.Abstractions/pull/24#issuecomment-14885612.

@ericnewton76

This comment has been minimized.

Show comment Hide comment
@ericnewton76

ericnewton76 Mar 14, 2013

Contributor

A little background: build-psake originated from Newtonsoft.Json project. They have to deal with multi-targeted and a more advanced Nuget build.

Since pranavkm is proposing net40 directory changes, this illustrates the eventual need of multi targets.

Its fine if you want a completely separate machine to package the nuget bits, but the other stuff needs to be easier to code/test. I can backtrack a lot of these particular commits but they're very useful.

And personally, it seems better to be a bit more manual (explicit) about pushing an update to the nuget servers since its nearly impossible to delete a bad upload.

Contributor

ericnewton76 commented Mar 14, 2013

A little background: build-psake originated from Newtonsoft.Json project. They have to deal with multi-targeted and a more advanced Nuget build.

Since pranavkm is proposing net40 directory changes, this illustrates the eventual need of multi targets.

Its fine if you want a completely separate machine to package the nuget bits, but the other stuff needs to be easier to code/test. I can backtrack a lot of these particular commits but they're very useful.

And personally, it seems better to be a bit more manual (explicit) about pushing an update to the nuget servers since its nearly impossible to delete a bad upload.

@tathamoddie

This comment has been minimized.

Show comment Hide comment
@tathamoddie

tathamoddie Mar 19, 2013

Owner

Hi Erik,

Some general thoughts:

  • This seems like a good idea. Thank you for approaching it.
  • Consider these points as some context from my side, not criticism or debate about the contents or intention of the pull request. I just don't want to leave you waiting in the dark, wondering what is happening with this PR.
  • I call pull requests with no prior discussion or issue a "surprise pull request". They are often a nice surprise, but they keep me on edge and generally take more reviewing. Surprise pull requests that add or replace significant components keep me really on edge. Surprise pull requests that add or replace significant components and have a large diff leave me in cold sweats, and usually involving me closing the browser tab and walking away for a little while. This approach will always introduce a delay in getting something landed.
  • I will never let a project get into a state that isn't deployable. (A personal learning.) That means I won't land these changes until I have proven the end-to-end process, complete with TeamCity. This means that the dependency on getting this pull request landed is me setting aside some time to tinker with the build server.
  • Packages will continue to be built and published by the build server at http://teamcity.tath.am/project.html?projectId=project9&tab=projectOverview&guest=1. This can be done by invoking specific MSBuild targets in the shared solution, but it has to be able to be executed automatically, end to end, in a repeatable way.
  • I don't want manual publishing to NuGet. If the tests pass in the CI build, it goes to NuGet. Period. If it's broken, we add more tests, fix the issue, then push a new build. I am incredibly passionate about this requirement for open source projects, because having fixes contributed and accepted but unpublished is crap for everyone. Also, I can't be bothered doing anything manually. You'll see that we follow the same approach for http://nuget.org/packages/Neo4jClient and it has over 500 packages published, so it works fine.

-- Tatham

Owner

tathamoddie commented Mar 19, 2013

Hi Erik,

Some general thoughts:

  • This seems like a good idea. Thank you for approaching it.
  • Consider these points as some context from my side, not criticism or debate about the contents or intention of the pull request. I just don't want to leave you waiting in the dark, wondering what is happening with this PR.
  • I call pull requests with no prior discussion or issue a "surprise pull request". They are often a nice surprise, but they keep me on edge and generally take more reviewing. Surprise pull requests that add or replace significant components keep me really on edge. Surprise pull requests that add or replace significant components and have a large diff leave me in cold sweats, and usually involving me closing the browser tab and walking away for a little while. This approach will always introduce a delay in getting something landed.
  • I will never let a project get into a state that isn't deployable. (A personal learning.) That means I won't land these changes until I have proven the end-to-end process, complete with TeamCity. This means that the dependency on getting this pull request landed is me setting aside some time to tinker with the build server.
  • Packages will continue to be built and published by the build server at http://teamcity.tath.am/project.html?projectId=project9&tab=projectOverview&guest=1. This can be done by invoking specific MSBuild targets in the shared solution, but it has to be able to be executed automatically, end to end, in a repeatable way.
  • I don't want manual publishing to NuGet. If the tests pass in the CI build, it goes to NuGet. Period. If it's broken, we add more tests, fix the issue, then push a new build. I am incredibly passionate about this requirement for open source projects, because having fixes contributed and accepted but unpublished is crap for everyone. Also, I can't be bothered doing anything manually. You'll see that we follow the same approach for http://nuget.org/packages/Neo4jClient and it has over 500 packages published, so it works fine.

-- Tatham

@@ -0,0 +1,13 @@

This comment has been minimized.

Show comment Hide comment
@shiftkey

shiftkey Mar 19, 2013

Should this file be in version control?

@shiftkey

shiftkey Mar 19, 2013

Should this file be in version control?

This comment has been minimized.

Show comment Hide comment
@tathamoddie

tathamoddie Mar 19, 2013

Owner

The commit that introduced this file was in a PR that was already landed, but then there's a later changeset in master that backs this file out: 3caefe1

When this PR is landed, the file should remain dead.

@tathamoddie

tathamoddie Mar 19, 2013

Owner

The commit that introduced this file was in a PR that was already landed, but then there's a later changeset in master that backs this file out: 3caefe1

When this PR is landed, the file should remain dead.

+ $name = $build.TestsName
+ $finalDir = $build.FinalDir
+
+ #robocopy "$sourceDir\Google.Maps\bin\Release\$finalDir" $workingDir\Package\Bin\$finalDir /NP /XO /XF *.pri | Out-Default

This comment has been minimized.

Show comment Hide comment
@tathamoddie

tathamoddie Mar 19, 2013

Owner

Google.Maps?

@tathamoddie

tathamoddie Mar 19, 2013

Owner

Google.Maps?

+# robocopy $docDir $workingDir\Package\Source\Doc /MIR /NP /XD .svn | Out-Default
+# robocopy $toolsDir $workingDir\Package\Source\Tools /MIR /NP /XD .svn | Out-Default
+
+# exec { .\Tools\7-zip\7za.exe a -tzip $workingDir\$zipFileName $workingDir\Package\* | Out-Default } "Error zipping"

This comment has been minimized.

Show comment Hide comment
@shiftkey

shiftkey Mar 19, 2013

Do we need 7-Zip included in the repository?

@shiftkey

shiftkey Mar 19, 2013

Do we need 7-Zip included in the repository?

+ $Return.MajorMinorRevision = "1.4.1"
+
+ $Return.Build = Get-BuildTiming
+ $Return.FullString = [String]::Concat($Return.MajorMinorRevision,".",[string]$Return.Build)

This comment has been minimized.

Show comment Hide comment
@tathamoddie

tathamoddie Mar 19, 2013

Owner

This isn't sufficient. It needs to take the build id supplied by TeamCity for traceability, not invent its own.

@tathamoddie

tathamoddie Mar 19, 2013

Owner

This isn't sufficient. It needs to take the build id supplied by TeamCity for traceability, not invent its own.

+}
+
+# Update any (recursively found under $sourceDir) AssemblyInfo.cs files
+function Update-AssemblyInfoFiles ([string] $sourceDir, [string] $assemblyVersionNumber, [string] $fileVersionNumber)

This comment has been minimized.

Show comment Hide comment
@tathamoddie

tathamoddie Mar 19, 2013

Owner

TeamCity already patches the AssemblyInfo files. Once it does so, the rest of the build can be driven off them.

@tathamoddie

tathamoddie Mar 19, 2013

Owner

TeamCity already patches the AssemblyInfo files. Once it does so, the rest of the build can be driven off them.

@@ -0,0 +1,16 @@

This comment has been minimized.

Show comment Hide comment
@tathamoddie

tathamoddie Mar 19, 2013

Owner

.cmd files?

@tathamoddie

tathamoddie Mar 19, 2013

Owner

.cmd files?

[assembly: AssemblyTitle("System.IO.Abstractions.TestingHelpers")]
[assembly: AssemblyDescription("A set of pre-built mocks to help when testing file system interactions.")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("")]
[assembly: AssemblyProduct("System.IO.Abstractions")]
-[assembly: AssemblyCopyright("Copyright © Tatham Oddie 2010")]
+[assembly: AssemblyCopyright("Copyright © Tatham Oddie 2010")]

This comment has been minimized.

Show comment Hide comment
@tathamoddie

tathamoddie Mar 19, 2013

Owner

Encoding is broken here.

@tathamoddie

tathamoddie Mar 19, 2013

Owner

Encoding is broken here.

+//Child projects should use Add Existing, then click Add As Link
+
+[assembly: AssemblyVersion("1.4.1.0")]
+[assembly: AssemblyFileVersion("1.4.1.1728")]

This comment has been minimized.

Show comment Hide comment
@tathamoddie

tathamoddie Mar 19, 2013

Owner

This shouldn't be hardcoded with a revision number.

@tathamoddie

tathamoddie Mar 19, 2013

Owner

This shouldn't be hardcoded with a revision number.

+//Master assembly version files
+//Child projects should use Add Existing, then click Add As Link
+
+[assembly: AssemblyVersion("1.4.1.0")]

This comment has been minimized.

Show comment Hide comment
@tathamoddie

tathamoddie Mar 19, 2013

Owner

Local builds, straight from VS, should be 0.0.0.1 not 1.4.1.0.

@tathamoddie

tathamoddie Mar 19, 2013

Owner

Local builds, straight from VS, should be 0.0.0.1 not 1.4.1.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment