Fixes to the CI document #1556

blackdwarf · 2017-02-14T19:17:42Z

Various fixes to the CI document.

mairaw

Thanks @blackdwarf. Some quick edit notes for you. I'll review this more thoroughly later on.

mairaw · 2017-02-14T22:13:10Z

docs/core/preview3/tools/using-ci-with-cli.md

+After this, you will be given an option to configure the repository that you wish to build as well as what queue to use for this build. After you select the needed options, you will be directed to the actual build definition. Here, you will be able to add a build step, as shown in the screenshot below: 
+
+![Adding a build step](media/vsts-screens/screen_4.png)


rename the folder vsts-screens to the name of the topic

mairaw · 2017-02-14T22:25:53Z

docs/core/preview3/tools/using-ci-with-cli.md

-This document outlines the usage of .NET Core SDK and its tools on the build server. In general, on a CI build server, 
-you want to automate the installation in some way. The automation, ideally, should not require administrative 
-privileges if at all possible. 
+This document outlines the usage of .NET Core SDK and its tools on the build server. When we started building the .NET Core SDK and its command-line tools, we have envisioned the toolset being able to be used both interactivelly, by a human being sitting at a command line, as well as automatically, that is by a CI server. The commands, options, inputs and outputs would be the same and the only thing you would add on top is a way to acquire the tooling as well as choosng how to do your build.


typos:

interactivelly

choosng

mairaw · 2017-02-14T22:26:27Z

docs/core/preview3/tools/using-ci-with-cli.md

-For SaaS CI solutions, there are several options. This document will cover two very popular ones, [TravisCI](https://travis-ci.org/) and 
-[AppVeyor](https://www.appveyor.com/). There are, of course, many other services out there, but the installation and 
-usage mechanisms should be similar.
+The document will focus on various scenarios of acqusition of the tools and show the tools that we built to help with that. We will then delve into some reccomendations on how to design and structure your build scripts themselves. 


typos:

acqusition

reccomendations

mairaw · 2017-02-14T22:26:45Z

docs/core/preview3/tools/using-ci-with-cli.md

-install a system-wide version of the SDK, which may be desired; if it's not, you should look into the 
-[installer script usage](#using-the-installer-script) outlined below. 
+### Using the native installers
+Native installers are available for MacOS, Windows and Ubuntu (in the form of DEB files and a dedicated apt-get feed). They have the following characteristics:


mairaw · 2017-02-14T22:26:59Z

docs/core/preview3/tools/using-ci-with-cli.md

-Ubuntu or `yum` for CentOS, or using the packages themselves (that is, DEB or RPM). The former would require setting up the 
-feed that contains the packages.
+* They require admin (sudo) access to the build server.
+* For Ubuntu, the apt-get feed allows native depencenies to be acquired at the same time the tools are acquired.


typo: depencenies

mairaw · 2017-02-14T22:38:24Z

docs/core/preview3/tools/using-ci-with-cli.md

+
+#### Using a manual script
+Taking the script we have started above and using it in VSTS is very simple. You can create a new build definition and then specify


specify what?

mairaw · 2017-02-14T22:39:08Z

docs/core/preview3/tools/using-ci-with-cli.md

+Taking the script we have started above and using it in VSTS is very simple. You can create a new build definition and then specify
+
+First, start by creating a new build definition. Once you get the screen that gives you an option to define what kind of a build you wish to create, click on the "Empty" option as the 


Remove all these extra words for First, After, etc...
Just list the steps in sequence
UI options are styled as bold

mairaw · 2017-02-14T22:40:30Z

docs/core/preview3/tools/using-ci-with-cli.md

+2. Use the .NET Core command-line commands
+
+Which to use should be decided mostly based on how familar and comfortable you are with each of the mentioned ways. For example, MSBuild can give you access to expressing your build(s) as tasks and targets, but it comes with an added complexity of learning MSBuild project-file syntax. On the other hand, using just the .NET Core command-line tools could be simpler but it would require you to write orchestration logic (for example, change into directory with project 1 and run `dotnet build`, then change to directory with project 2 and again run `dotnet build` etc.) in some scripting language like `bash` or PowerShell. 


Always use the plural form of a noun rather than adding (s).

typo: familar

mairaw · 2017-02-14T22:41:09Z

docs/core/preview3/tools/using-ci-with-cli.md

+Which to use should be decided mostly based on how familar and comfortable you are with each of the mentioned ways. For example, MSBuild can give you access to expressing your build(s) as tasks and targets, but it comes with an added complexity of learning MSBuild project-file syntax. On the other hand, using just the .NET Core command-line tools could be simpler but it would require you to write orchestration logic (for example, change into directory with project 1 and run `dotnet build`, then change to directory with project 2 and again run `dotnet build` etc.) in some scripting language like `bash` or PowerShell. 
+
+The choice here is dependent on familiarity; some people are more comfortable using more familiar languages like shell scripts while others are well-versed in MSBuild projects and have no problems using them. 


This is kind of repeating the last paragraph

mairaw · 2017-02-14T22:41:58Z

docs/core/preview3/tools/using-ci-with-cli.md

+![Specifying the PowerShell script to run](media/vsts-screens/screen_6_ps.png)
+
+Here, you can select the script you've created and committed to source control. After this is done, you can save the build definition and try it out by enquining it. From that moment on, you are good to go. 


typo: enquining

blackdwarf · 2017-02-23T01:09:50Z

@mairaw pls take a look. @enricosada will update the PR to add the new AppVeyor script that uses manual install of the newest bits.

enricosada

I'll add updated travis/appveyor, downloading and invoking install script, because is best option atm

enricosada · 2017-02-24T10:51:36Z

docs/core/preview3/tools/using-ci-with-cli.md

@@ -74,12 +127,14 @@ The [travis-ci](https://travis-ci.org/) can be configured to install the .NET Co
 Just use:

 ```yaml
-dotnet: 1.0.0-preview2-003121
+dotnet: 1.0.0-rc4-0044771
 ```

 Travis can run both `osx` (OS X 10.11) and `linux` ( Ubuntu 14.04 ) job in a build matrix, see [example .travis.yml](https://github.com/dotnet/docs/blob/master/.travis.yml) 


@mairaw @blackdwarf you can specify what osx you want to use (also do a build matrix on that) with normal travis conf, so let's use the default in these docs, and travis users can customize as usual ref travis docs

A really good idea is also update directly the f#, c#, vb official travis docs with .net core support (at least a link to this document)

enricosada · 2017-02-24T10:55:45Z

also afaik (up to two days ago), travis doesnt yet support rc4, ref travis-ci/travis-ci#7301
i'll check with travis.yml embedded in this repo

enricosada · 2017-02-24T12:12:22Z

@blackdwarf added #1599 with cleanup appveyor/travis for rc4

* use install script in build matrix * add travis docs, and template * travis, add custom install using install script

blackdwarf · 2017-02-24T14:32:41Z

@enricosada I've added support for RC* in Travis with travis-ci/travis-build#968 that was merged yesterday or on Wed.

blackdwarf · 2017-02-28T00:27:58Z

@mairaw are you ok for this going in?

mairaw · 2017-03-07T03:22:49Z

.travis.yml

@@ -9,11 +9,21 @@ matrix:
    - os: osx # OSX 10.11
      osx_image: xcode7.2
      dotnet: 1.0.0-preview2-003121


do we need to change these versions @enricosada?

Yes. That should say 1.0.1

mairaw · 2017-03-07T03:23:08Z

.travis.yml


 script:
+  - dotnet --info
  # Run a new console app
  - mkdir -p "test/test-dotnet-new" && pushd "test/test-dotnet-new"
  - dotnet new


should probably be changed to dotnet new console

mairaw · 2017-03-07T03:24:23Z

appveyor.yml

-##   - ps: (New-Object System.Net.WebClient).DownloadFile($url, $tempFile)
-##   - ps: Add-Type -AssemblyName System.IO.Compression.FileSystem; [System.IO.Compression.ZipFile]::ExtractToDirectory($tempFile, $env:DOTNET_INSTALL_DIR)
-##   - ps: $env:Path = "$env:DOTNET_INSTALL_DIR;$env:Path"
+# NOTE .NET Core SDK preview2 is already installed in the build worker image Visual Studio 2015


we would need to update these for vs 2017 correct?

mairaw · 2017-03-07T04:28:50Z

I've made some improvements @blackdwarf but I still don't think this is ready. Here are the my questions now:

we have images that are not being used. Delete them?
The section on Using a manual script seems to skip a few steps but I don't know how to fix that since I've never used VSTS. For example, how do I get to the Create new build definition page/dialog?
The topic still talks about VS 2015

blackdwarf · 2017-03-07T04:53:40Z

@mairaw comments:

Sure, delete all of them.
You click on the "Build & Release" in the top row. Will add that.
Hmmm, @enricosada I thought you added the YAML file for AppVeyor that uses the script and not the VS2015 image?

am11 · 2017-03-07T13:14:17Z

.travis.yml

@@ -9,11 +9,21 @@ matrix:
    - os: osx # OSX 10.11
      osx_image: xcode7.2
      dotnet: 1.0.0-preview2-003121
+    - os: osx # OSX 10.12
+      osx_image: xcode7.3
+      dotnet: 1.0.0-rc4-0044771


Please CMIIW, but I think it's 0044771 -> 004771.

It will work after travis-ci/travis-build#973 :)

enricosada · 2017-03-08T15:53:13Z

Hmmm, @enricosada I thought you added the YAML file for AppVeyor that uses the script and not the VS2015 image?

@blackdwarf i have do it, the appveyor.yml is

 install:
    - ps: $env:DOTNET_INSTALL_DIR = "$pwd\.dotnetsdk"
    - ps: mkdir $env:DOTNET_INSTALL_DIR -Force | Out-Null
    - ps: Invoke-WebRequest -Uri "https://raw.codeproxy.net/dotnet/cli/rel/1.0.0/scripts/obtain/dotnet-install.ps1" -OutFile "$($env:DOTNET_INSTALL_DIR)/dotnet-install.ps1"
    - ps: '& "$($env:DOTNET_INSTALL_DIR)/dotnet-install.ps1" -Version $env:CLI_VERSION -InstallDir $env:DOTNET_INSTALL_DIR'
    - ps: $env:Path = "$env:DOTNET_INSTALL_DIR;$env:Path"

btw all that should be updated for 1.0 rtm i think.

@blackdwarf all that should be updated with .net core tools 1.0.1 , i'll send a PR asap, checking locally because the channel is changed (btw the descript of channel show dev/future/production, but production doesnt work and default is undocumented rel-1.0.0), i'll open an issue in dotnet/cli about that

enricosada · 2017-03-08T16:24:49Z

@blackdwarf added some comment about dotnet-install script and docs in https://github.com/dotnet/cli/issues/5952

guardrex · 2017-05-16T08:05:51Z

Replaced by #2161

Zlatko Knezevic added 5 commits February 12, 2017 18:34

Starting work on CI document

e57a906

Added manual section and images for VSTS

6093875

Adding more content

a91e8f7

Reverting the Preview 2 back to its original form

b3750d1

Adding a simple bash script

40eb14e

blackdwarf requested a review from mairaw February 14, 2017 19:17

dnfclas added the cla-already-signed label Feb 14, 2017

Zlatko Knezevic added 2 commits February 14, 2017 12:50

Adding the entry to RC4 TOC

165f054

Adding the proper path to the TOC

1273801

mairaw requested changes Feb 14, 2017

View reviewed changes

Zlatko Knezevic added 3 commits February 14, 2017 14:45

Spelling mistakes fixed

df02a40

Responding to PR feedback

14a60f9

Responding to PR feedback

2280072

enricosada reviewed Feb 24, 2017

View reviewed changes

rc4 appveyor/travis cleanup (#1599)

d60d44d

* use install script in build matrix * add travis docs, and template * travis, add custom install using install script

mairaw reviewed Mar 7, 2017

View reviewed changes

mairaw added 2 commits March 6, 2017 20:23

making some improvements

f715848

update ms.date

aacbc85

Adding a line for VSTS

339a9c7

am11 reviewed Mar 7, 2017

View reviewed changes

enricosada mentioned this pull request Mar 8, 2017

Use new fsproj, replace project.json fsharp/fsharp-compiler-docs#700

Closed

mairaw mentioned this pull request Apr 27, 2017

Removing outdated VS references (Part 3) #1811

Merged

guardrex mentioned this pull request May 15, 2017

Fixes to the CI document #2161

Merged

guardrex closed this May 16, 2017

guardrex deleted the cifixes branch May 16, 2017 08:06

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fixes to the CI document #1556

Fixes to the CI document #1556

blackdwarf commented Feb 14, 2017 •

edited by mairaw

Loading

mairaw left a comment

mairaw Feb 14, 2017

mairaw Feb 14, 2017

mairaw Feb 14, 2017

mairaw Feb 14, 2017

mairaw Feb 14, 2017

mairaw Feb 14, 2017

mairaw Feb 14, 2017

mairaw Feb 14, 2017

mairaw Feb 14, 2017

mairaw Feb 14, 2017

blackdwarf commented Feb 23, 2017

enricosada left a comment

enricosada Feb 24, 2017

enricosada commented Feb 24, 2017

enricosada commented Feb 24, 2017

blackdwarf commented Feb 24, 2017

blackdwarf commented Feb 28, 2017

mairaw Mar 7, 2017

blackdwarf Mar 7, 2017

mairaw Mar 7, 2017

mairaw Mar 7, 2017

mairaw commented Mar 7, 2017

blackdwarf commented Mar 7, 2017 •

edited

Loading

am11 Mar 7, 2017

enricosada commented Mar 8, 2017

enricosada commented Mar 8, 2017

guardrex commented May 16, 2017

		After this, you will be given an option to configure the repository that you wish to build as well as what queue to use for this build. After you select the needed options, you will be directed to the actual build definition. Here, you will be able to add a build step, as shown in the screenshot below:

		![Adding a build step](media/vsts-screens/screen_4.png)


		#### Using a manual script
		Taking the script we have started above and using it in VSTS is very simple. You can create a new build definition and then specify

		Taking the script we have started above and using it in VSTS is very simple. You can create a new build definition and then specify

		First, start by creating a new build definition. Once you get the screen that gives you an option to define what kind of a build you wish to create, click on the "Empty" option as the

		2. Use the .NET Core command-line commands

		Which to use should be decided mostly based on how familar and comfortable you are with each of the mentioned ways. For example, MSBuild can give you access to expressing your build(s) as tasks and targets, but it comes with an added complexity of learning MSBuild project-file syntax. On the other hand, using just the .NET Core command-line tools could be simpler but it would require you to write orchestration logic (for example, change into directory with project 1 and run `dotnet build`, then change to directory with project 2 and again run `dotnet build` etc.) in some scripting language like `bash` or PowerShell.

		Which to use should be decided mostly based on how familar and comfortable you are with each of the mentioned ways. For example, MSBuild can give you access to expressing your build(s) as tasks and targets, but it comes with an added complexity of learning MSBuild project-file syntax. On the other hand, using just the .NET Core command-line tools could be simpler but it would require you to write orchestration logic (for example, change into directory with project 1 and run `dotnet build`, then change to directory with project 2 and again run `dotnet build` etc.) in some scripting language like `bash` or PowerShell.

		The choice here is dependent on familiarity; some people are more comfortable using more familiar languages like shell scripts while others are well-versed in MSBuild projects and have no problems using them.

		![Specifying the PowerShell script to run](media/vsts-screens/screen_6_ps.png)

		Here, you can select the script you've created and committed to source control. After this is done, you can save the build definition and try it out by enquining it. From that moment on, you are good to go.

Fixes to the CI document #1556

Fixes to the CI document #1556

Conversation

blackdwarf commented Feb 14, 2017 • edited by mairaw Loading

mairaw left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

blackdwarf commented Feb 23, 2017

enricosada left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

enricosada commented Feb 24, 2017

enricosada commented Feb 24, 2017

blackdwarf commented Feb 24, 2017

blackdwarf commented Feb 28, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mairaw commented Mar 7, 2017

blackdwarf commented Mar 7, 2017 • edited Loading

Choose a reason for hiding this comment

enricosada commented Mar 8, 2017

enricosada commented Mar 8, 2017

guardrex commented May 16, 2017

blackdwarf commented Feb 14, 2017 •

edited by mairaw

Loading

blackdwarf commented Mar 7, 2017 •

edited

Loading