CI and Build server - Githubissues

mauroservienti commented 9 years ago

From @mauroservienti on October 30, 2014 5:56

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

Copied from original issue: RadicalFx/Radical#93

mauroservienti commented 9 years ago

From @micdenny on November 18, 2014 21:48

We should highly consider the free ci build server AppVeyor

mauroservienti commented 9 years ago

From @micdenny on January 11, 2015 13:47

@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?

mauroservienti commented 9 years ago

From @micdenny on January 12, 2015 12:44

@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.

mauroservienti commented 9 years ago

From @micdenny on January 12, 2015 18:8

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:

mauroservienti commented 9 years ago

From @micdenny on January 12, 2015 18:12

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.

mauroservienti commented 9 years ago

From @micdenny on January 12, 2015 18:29

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.

mauroservienti commented 9 years ago

From @micdenny on January 12, 2015 22:12

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.

mauroservienti commented 9 years ago

From @micdenny on January 13, 2015 9:46

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?

mauroservienti commented 9 years ago

From @micdenny on January 14, 2015 10:22

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

mauroservienti commented 9 years ago

From @micdenny on June 7, 2015 12:21

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

mauroservienti commented 9 years ago

From @micdenny on June 27, 2015 13:18

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.

mauroservienti commented 9 years ago

From @micdenny on June 29, 2015 8:5

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!

mauroservienti commented 9 years ago

From @micdenny on June 29, 2015 8:11

Just a recap for my reference:

[x] Separate each component (Radical, Radical.Windows, etc...) in its own repo.
[x] 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

mauroservienti commented 9 years ago

From @micdenny on June 29, 2015 8:20

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....

mauroservienti commented 9 years ago

From @micdenny on June 29, 2015 8:27

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.

mauroservienti commented 9 years ago

From @micdenny on June 29, 2015 8:30

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.

mauroservienti commented 9 years ago

From @micdenny on June 29, 2015 16:45

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

mauroservienti commented 9 years ago

From @micdenny on June 29, 2015 18:49

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:

mauroservienti commented 9 years ago

From @micdenny on June 30, 2015 18:16

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

mauroservienti commented 9 years ago

From @micdenny on June 30, 2015 18:34

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.

mauroservienti commented 9 years ago

From @micdenny on June 30, 2015 18:50

@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.

mauroservienti commented 9 years ago

From @micdenny on July 1, 2015 9:39

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.

mauroservienti commented 9 years ago

From @micdenny on July 1, 2015 12:17

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?

mauroservienti commented 9 years ago

From @micdenny

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

mauroservienti commented 9 years ago

Any progress on this? Do we have an ETA?

No pressure at all, just to understand. Thanks :smile:

micdenny commented 9 years ago

I'm back from my holidays, so I think I'm going to look at this next week (or maybe this weekend), I will push a first working attempt, then we can evolve if it doesn't fit our requirements.

mauroservienti commented 9 years ago

cool :)

micdenny commented 9 years ago

in progress...

micdenny commented 9 years ago

there's some problem with the nuget v3.1 that is used by default from appveyor, but I figure it out temporary adding nuget.exe 2.8.x directly in the repo.

at the moment I'm still working on my fork I will PR when I have a complete working solution.

micdenny commented 9 years ago

there's some problem with the nuget v3.1

now works! it was a nuget.org problem with the new v3 gallery:

micdenny commented 9 years ago

this is what I've done so far to automatically build... versioning is a PITA!

the sad part:

{build} number always increment (appveyor manages), also when building pull request
to follow the semver the version is set to be 1.1.{build} for releases and 1.1.{build}-alpha1 for pre-releases
need to change the version in two section of the appveyor.yml file (release and pre-release configuration)
when changing major or minor version the {build} number has to be manually reset from appveyor settings UI page, for example to pass from 1.2.45 to 1.3.0 correctly.

the happy part:

need just to bump the version on appveyor.yml when a major or minor version changes, so only on breaking changes
pull requests builds, does not trigger package deploy, only artefacts
we can publish release package to nuget.org when building from master
we can publish pre-release package to myget.org when building from develop

@mauroservienti what do you think about that?

In the meanwhile I will experiment another way, that maintains version in AssemblyInfo.cs then with a PS script extracts the version and use it to set the version of appveyor build and of the nuget package.

micdenny commented 9 years ago

I'm developing a nicer experience, just change the version in a semver way, and the script does the rest ;)

stand by....

mauroservienti commented 9 years ago

What if we schedule a short Skype/Zoom call to get this going? I can show you what I'm doing with GitVersion and see if we can seamlessy integrate it solving the SemVer issue as well.

On Wed, Aug 19, 2015 at 7:31 PM, Michael Denny notifications@github.com wrote:

I'm developing a nicer experience, just change the version in a semver way, and the script does the rest ;)

stand by....

— Reply to this email directly or view it on GitHub https://github.com/RadicalFx/housekeeping/issues/23#issuecomment-132707664 .

Mauro Servienti

micdenny commented 9 years ago

yes we can arrange it

mauroservienti commented 9 years ago

[x] Create AppVeyor account for the radical-bot user
[x] Add radical-bot user to the Radical Build team on GitHub
[x] Grant access to the Radical Build to the relevant projects
[x] Add Radical Build team as AppVeyor admin joining the radical-bot account
[x] Create NuGet environment on AppVeyor adding API Key as radical NuGet user
[x] Create MyGet account as radical user
[x] Create MyGet feed as radical-unstable
[x] Create MyGet environment on AppVeyor adding API Key as radical MyGet user

mauroservienti commented 9 years ago

All done. Ping me if I missed/screwed something :smile:

micdenny commented 9 years ago

Great, if that is all what I need, you should see my PR soon ;)

RadicalFx / housekeeping

CI and Build server #23