CI and Build server - Githubissues

mauroservienti commented 10 years ago

As part of the release management improvements (#80 & #82)

micdenny commented 9 years ago

We should highly consider the free ci build server AppVeyor

micdenny commented 9 years ago

@mauroservienti we need to use a nuget package for System.Windows.Interactivity or embed as dll in the repo, because otherwise it is not possible to install the blend interactivity for v4.5 because it is not distributed as an sdk anymore, and comes just with visual studio, and probably not on the free visual studio version that does not have blend, and this is a problem for the CI build server that has this software pre-installed: http://www.appveyor.com/docs/installed-software

I've already created the chocolatey package for Blend3 and Blend4 sdk, but can't for 4.5 because doesn't exist.

I think the easiest way is to embed or using a nuget package for that, could you arrange it?

micdenny commented 9 years ago

@mauroservienti please have a look to PR #119 and see if we can go with that solution, to best work with build server as well.

micdenny commented 9 years ago

Build scheduled let's see if it works.

In the meanwhile here's the badge that we'll can add to our repo readme file:

micdenny commented 9 years ago

I also found that AppVeyor is able to understand that a PR was sent, and it starts a build from that PR, before that you actually have merge it.

This is an invaluable feature of AppVeyor, because it can tells you if the build failed (+tests) before you actually merge it.

mauroservienti commented 9 years ago

Lovely, what limitations have? I mean, given that it is free are we limited in some way?

Sent from my Amazing not anymore Yellow Lumia, typos are guaranteed ;-)

From: Michael Dennymailto:notifications@github.com Sent: ý12/ý01/ý2015 19:12 To: RadicalFx/radicalmailto:radical@noreply.github.com Cc: Mauro Servientimailto:mauro@topics.it Subject: Re: [radical] CI and Build server (#93)

I also foundhttps://github.com/EasyNetQ/EasyNetQ/issues/344 that AppVeyor is able to understand that a PR was sent, and it starts a build from that PR, before that you actually have merge it.

This is an invaluable feature of AppVeyor, because it can tells you if the build failed (+tests) before you actually merge it.

— Reply to this email directly or view it on GitHubhttps://github.com/RadicalFx/radical/issues/93#issuecomment-69616177.

micdenny commented 9 years ago

In the free edition you have limitation just on calculation power and concurrent jobs (see the pricing offical page).

What is "concurrent job"?

Every push to the repository starts a new build with a single or multiple jobs. If your current plan includes only 1 concurrent job and there is another build job currently running all consequent jobs will be queued until the first job finishes. With multiple concurrent jobs your team will be getting results faster or you can use build matrix and parallel testing to build and test, for instance, Debug/Release or x64/x86 configurations in parallel.

What hardware is used to run builds?

Every build job runs on a pristine virtual machine provisioned just for this build. "Basic" and "Free" plans run builds on "Azure" environment where each build worker has 1 CPU core and 1.75 GB of RAM ("Small" instance). "Pro" and "Premium" plans run builds on dedicated hardware with faster CPUs, SSD drives, 1 GB network uplink and use Hyper-V for creating isolated build workers.

Are there any build time restrictions?

All plans have maximum build job execution time of 40 minutes.

micdenny commented 9 years ago

and finally it works, check the pushed artifacts :smile: of course the artifacts will be also pushed to the nuget.org gallery, but this is the last step, and we should discuss more on it.

this is just a starting point, I had to add a new chocolatey package for NuBuild, and AppVeyor just installed without any problem with a simple choco install NuBuild ;)

Now I have to manage the versioning and we're quite there.

I was wondering if it's better to avoid all those post-build action to copy assemblies, and just add a .nuspec file for each project we would like to publish, and leave the build server do the rest, actually it will also be clear for whom it may build directly from source where to look at "bin\release" and when you have to create a manual nuget package, just run run nuget pack from the console... I'm just thinking out loud... maybe a branch with a PR could be better to discuss.

micdenny commented 9 years ago

I was wondering if it's better to avoid all those post-build action to copy assemblies

I thought about it, and I think I will leave your structure for the moment, and proceed step by step, first step just use your script+nubuild to build and push packages, then we will see if it worth remove the post-build script, maybe the first time we need to change, we remove :smile:

mauroservienti commented 9 years ago

How do we define when and where packages are pushed? I mean:

can we say that we want to push on NuGet only on master commits/push with a specific tag for example?
can we say that each push to develop shoul be packaged and pushed to myget?

Any other idea?

micdenny commented 9 years ago

can we say that we want to push on NuGet only on master commits/push with a specific tag for example?

I don't see that feature, there's a "tag" promoting scenario, but only for pushing to GitHub releases.

I think we should start easy, something like "when commit to master, build and instantly push to nuget as stable", as opposite to "when commit to develop, build and instantly push to nuget as prerelease".

I would also say, that from my experience, when you have small community, having just one master branch always pushed as stable gives you more feedback on the project, and the project itself evolve/fix more quickly, it sounds risky I agree, but I saw it work remarkably well. If you have a pre-release but no one cares about it, bugs won't get noticed until the release version and then they'll have to be fixed in there anyway.

What do you think about choosing one of the following process?

Leave master / develop branch, build them and instantly create stable and prerelease on nuget. Prerelease of course could be pushed on myget, but at the moment I would push to nuget, and use myget when you would like to differentiate nightly-build from promoted alpha/beta (but again, that's more work!).
Remove develop branch, leave only master, on every commit, build and instantly create stable release on nuget. Every other branch from master, is on developing or waiting to be merged, and could be promoted as a prerelease package but only when it worth, means someone is there to heavily test it.

mauroservienti commented 9 years ago

Leave master / develop branch, build them and instantly create stable and prerelease on nuget. Prerelease of course could be pushed on myget, but at the moment I would push to nuget, and use myget when you would like to differentiate nightly-build from promoted alpha/beta (but again, that's more work!).

Like this one, go ahead. Good stuff.

mauroservienti commented 9 years ago

In light of https://github.com/RadicalFx/housekeeping/issues/15 do you think that it gets simpler? I suspect yes :-)

micdenny commented 9 years ago

for my reference... a way to patch the assembly and nuspec version, setting the version just once in the appveyor config file:

http://help.appveyor.com/discussions/problems/1785-publish-prerelease-nuget-package-with-version-from-yml-file

a working sample:

https://github.com/FeodorFitsner/nuget-test

mauroservienti commented 9 years ago

moving back to the backlog, to ambitious for the next release, I hope to be able to complete https://github.com/RadicalFx/housekeeping/issues/15 and we can concentrate on this

micdenny commented 9 years ago

ok great!

mauroservienti commented 9 years ago

Easier than expected. https://github.com/RadicalFx/housekeeping/issues/15 is now done.

All the develop branches, and most of the master ones are now aligned. Each package has its own repo.

You can start crafting this one, I suggest that if there is something to be done at the repo level issues should be opened there, linking back to this one.

micdenny commented 9 years ago

ok will create issue for every change I need to do, basically the appveyor config file for sure, anyway will work as usual in branch+issue

thanks!

micdenny commented 9 years ago

Just a recap for my reference:

[x] Separate each component (Radical, Radical.Windows, etc...) in its own repo.
[ ] Create a build for each component: each time we push, a build is started and deployed to a feed.
[x] Differentiate publish by branch: if we push to develop then we publish as beta to Myget, if we push to release then we publish to NuGet. (optional)

mauroservienti commented 9 years ago

yes. all correct. What may miss how to generate version numbers

micdenny commented 9 years ago

I've posted something regard that in this comment: https://github.com/RadicalFx/Radical/issues/93#issuecomment-109747001

I've just tested this scenario on a simple project and it worked. Repo: https://github.com/FeodorFitsner/nuget-test nuspec: https://github.com/FeodorFitsner/nuget-test/blob/master/MyNuGetLib/... appveyor.yml: https://github.com/FeodorFitsner/nuget-test/blob/master/appveyor.yml build results: https://ci.appveyor.com/project/FeodorFitsner/nuget-test/build/1.0....

micdenny commented 9 years ago

Basically in that way, you will just need to patch the version variable of the appveyor.yml, so every time you are merging a PR you just ensure that the version is correctly patched (non-breaking or breaking), and that's it, after you commit the merge the build process start with the correct version.

micdenny commented 9 years ago

then to separate the beta from the release, it should be a PR in the middle, with the merge of all the changes, and the version patch removing the pre-build tag (ie.: -rc1), and that's it. This is the mainly idea, let's see to realize something, and then see if we like it.

micdenny commented 9 years ago

This is a good way to differentiate publish by branch

If you use git flow you may want to have a different build configuration (e.g. deploying to a different environment) in a feature branch. Changing appveyor.yml in a feature branch becomes an issue when you merge it into master overriding appveyor.yml and breaking master builds.

To solve this problem AppVeyor allows having multiple per-branch configurations in a single appveyor.yml.

Multiple configurations are defined as a list with branches section in every item that:

# configuration for "master" branch
# build in Release mode and deploy to Azure
-
  branches:
    only:
      - master

  configuration: Release
  deploy:
    provider: AzureCS
    ...

# configuration for all branches starting from "dev-"
# build in Debug mode and deploy locally for testing
-
  branches:
    only:
      - /dev-.*/

  configuration: Debug
  deploy:
    provider: Local
    ...

# "fall back" configuration for all other branches
# no "branches" section defined
# do not deploy at all
-
  configuration: Debug

micdenny commented 9 years ago

first automatic build done successfully :smile:

I'm on a personal repo/branch and a separated appveyor build project to do all my tests

and my first package as been deploy on MyGet (micdenny-radical feed): https://www.myget.org/F/micdenny-radical/api/v2

mauroservienti commented 9 years ago

:tada: :+1:

micdenny commented 9 years ago

Lesson learnt: appveyor does not like the way you add spaces around method call :smile:

It took a while to understand why the assembly version patching was working on AssemblyFileVersion and AssemblyInformationalVersion but not for the most important AssemblyVersion, and it turns out that probably they have a poor regex replace pattern :smile:

[assembly: AssemblyVersion( "1.0.0.0" )]

now replaced with this that work:

[assembly: AssemblyVersion("1.0.0.0")]

I've opened a discussion on appveyor: http://help.appveyor.com/discussions/problems/2407-c-patching-assembly-version-doesnt-work-if-theres-spaces-around-version-parameter

micdenny commented 9 years ago

Habemus Papam!

Automatic release based on the branch!

commit on development and you get a package build with a pre-release version number eg.: 1.0.15-alpha1 that is pushed on MyGet.org

commit on master and you get a package build with a release version number eg.: 1.0.16 that is pushed on the public gallery on NuGet.org

we will just need to remember to patch the version in the appveyor.yml file before commit the changes.

you can preview the changes on my repo on the brach deploy (simulates the master branch) and deploy-development (simulates the development branch), of course I will PR you the right configuration to build against master and development branches.

micdenny commented 9 years ago

@mauroservienti should we pass to semantic versioning? like microsoft is doing also for framework packaging.

In MyGet.org they adding also the build number:

and then when push to nuget they remove build number:

Actual Radical packages will become as follow:

Pre-release on myget: 1.5.2-alpha1-{build} Pre-release on nuget: 1.5.2-alpha1 Release on nuget: 1.5.2

Basically we just remove build version when we push on nuget.

what do you think?

mauroservienti commented 9 years ago

@mauroservienti should we pass to semantic versioning? like microsoft is doing also for framework packaging.

We are already doing our best to follow SemVer so it should not be a problem at all. :+1: to strict SemVer.

Regarding version numbers take a look at these:

Since we are already adopting GitFlow the above should be very easy, it is based on branch naming conventions.

micdenny commented 9 years ago

interesting GitVersion, need to give a try to understand how it works, it uses tag to understand the version to bump assembly info?

Can you describe the flow do you except to have included versioning?

with what I configured until now it looks like this:

when integrating on develop branch

change the version on develop section of appveyor.yml
commit to develop
build start
all the assemblies and the nuget package are bumped with the version specified
nuget are pushed to myget

when integrating on master branch

change the version on master section of appveyor.yml
commit to master
build start
all the assemblies and the nuget package are bumped with the version specified
nuget are pushed to nuget

You want to add some kind of tag commitment, so the build on master start only when there's a tag? and what about development then? Sorry to bother you, but I want to understand what's your idea, because there's so many ways to do this kind of stuff :smile:

mauroservienti commented 9 years ago

Can you describe the flow do you except to have included versioning?

Nothing different for what you described, except that the versioning is deducted by GitVersion based on conventions (TAG + branch + Git Flow).

Testing it now in the public Radical repo, found some issues due the existing TAGs, in touch with the GitVersion crew to see how to move forward.

micdenny commented 9 years ago

Testing it now in the public Radical repo, found some issues due the existing TAGs, in touch with the GitVersion crew to see how to move forward.

so basically you're just trying the console app against the repo and GitVersion reply with the json of what it thinks the next version should be?

mauroservienti commented 9 years ago

No, I'm using the MSBuild TASK. Pull the repo, try to build it locally, take a look at the generated assembly. Also take a look at the AssemblyInfo files, they are missing the Assembly*Version attributes. Injected at build time by GitVersion. It is not working as expected, right now, the generated build number is not expected.

Here the ongoing discussion:

On Wed, Jul 1, 2015 at 2:17 PM, Michael Denny notifications@github.com wrote:

Testing it now in the public Radical repo, found some issues due the existing TAGs, in touch with the GitVersion crew to see how to move forward.

so basically you're just trying the console app against the repo and GitVersion reply with the json of what it thinks the next version should be?

— Reply to this email directly or view it on GitHub https://github.com/RadicalFx/Radical/issues/93#issuecomment-117637859.

Mauro Servienti

mauroservienti commented 9 years ago

All the components are splitted into their own repo. Despite GitVersion not yet usable due to our legacy commit history we can move this forward in my opinion.

Thoughts?

micdenny commented 9 years ago

I was at a good point anyway, with little manual change to do before commit, actually just change the version in the appveyor config file, then we can leverage the power of automatic deployment and CI.

Now I'm facing an issue with building PR, actually the most difficult part is versioning, I need to keep the {build} automatic number somewhere to let the build server build also the PR without getting error that a version was already build, and this is in somehow against semver.

Now I'm going on holidays, but on the first week of august I'm back and I will push the changes to build against appveyor with at least a starting point that covers PR builds, pre-release build, release build.

mauroservienti commented 9 years ago

Wondering if there is any value in setting up our own build server, we can get a TeamCity license as OSS or as MVPs and use a VM on Azure to run it.

Thoughts?

On Thu, Jul 16, 2015 at 9:18 AM, Michael Denny notifications@github.com wrote:

I was at a good point anyway, with little manual change to do before commit, actually just change the version in the appveyor config file, but then we leverage the power of automatic deployment and CI.

Now I'm facing an issue with building PR, actually the most difficult part is versioning, I need to keep the {build} automatic number somewhere to let the build server build also the PR without getting error that a version was already build.

Now I'm going on holidays, but on the first week of august I'm back and I will push the changes to build against appveyor with at least a starting point that covers PR builds, pre-release build, release build.

— Reply to this email directly or view it on GitHub https://github.com/RadicalFx/Radical/issues/93#issuecomment-121855908.

Mauro Servienti

micdenny commented 9 years ago

I think is just a matter of power and control, Microsoft start on appveyor then pass on teamcity and I think just because they installed on bigger machines on azure :) and versioning will be anyway a PITA

mauroservienti commented 9 years ago

+1, go on with AppVeyor

On Thu, Jul 16, 2015 at 10:28 AM, Michael Denny notifications@github.com wrote:

I think is just a matter of power and control, Microsoft start on appveyor then pass on teamcity and I think just because they installed on bigger machines on azure :) and versioning will be anyway a PITA

— Reply to this email directly or view it on GitHub https://github.com/RadicalFx/Radical/issues/93#issuecomment-121876602.

Mauro Servienti

mauroservienti commented 9 years ago

Moved to https://github.com/RadicalFx/housekeeping/issues/23

RadicalFx / Radical

CI and Build server #93