How do match source code with build number from nu-get - asp.net-core

In my project.json I have a reference to
"Microsoft.AspNet.Mvc": "6.0.0-beta6-14192",
In github https://github.com/aspnet/Mvc I don't know which source is used for this build.
Where do I find this information?

Right now, there's no easy way to get the commit id. But for all the packages that will be released after today noon-ish time (PDT), that will be possible. You will be able to run dnu sources get <package-name> and you'll get the sources for that particular package.
To unblock you, I've looked in our internal CI. MVC build 14192 was produced from commit 37f056ce2bd930635fbfa1370b7ccf5752130c7f

Related

OpenRefine sample extension not building

I'd like to write my own OpenRefine extension
Before starting any implementation, I just want to build the sample extension from OpenRefine just to get me started.
However, I'm getting the Maven error
Could not resolve dependencies for project org.openrefine:sample:jar:3.0-SNAPSHOT: org.openrefine:main:jar:3.0-SNAPSHOT was not found in https://oss.sonatype.org/content/repositories/snapshots/ during a previous attempt. This failure was cached in the local repository and resolution is not reattempted until the update interval of snapshots has elapsed or updates are forced ->
I simply cloned the OpenRefine repo and ran mvn compile from the extensions/sample folder.
any tips?
ok, I think the sample project has a wrong version in the pom.xml. it should be\
<version>3.6-SNAPSHOT</version>
I fixed the issue in this PR https://github.com/OpenRefine/OpenRefine/pull/4395

How to access artifacts folder after build in TFS online?

PreInfo: I have .net core web api (vs2015) mixed with just ordinary projects.
I have spent almost 2 days now to get this to work and search and tried everything I can think of, but I just cant for the live of me get the build and release in TFS online to play together.
The build (publish artifact step) says "Directory 'D:\a\1\a' is empty. Nothing will be added to build artifact 'drop'."
but the "run dot net" step says
"Published to D:\a\1\s\Operator\MobileService\root\MobileService\src\AMP.Operator.MobileService\bin\release\net452\win7-x64\publish"
...so it must be somewhere the release can pick it up but no matter what I try I can´t get it to be picked up.
Here is my build setup
dotnet run
publishing
And the realse with $(System.DefaultWorkingDirectory)/MobileService-Dev please note that I have tried every combo of $(build.artifactstagingdirectory) in the build to publish without luck but I sure this should point to the publishing folder for the build
I so hope somebody can point me to a solution. I just can´t understand how hard it is to make this work..
Within your build definition, I recommend adding a Copy Files step that will copy your the build artifacts from your msbuild results to the Build's Artifact Staging Directory before you run the Publish Artifact step.
Source Folder: $(Build.SourcesDirectory)
Contents: **\bin\$(BuildConfiguration)\**
Target Folder: $(Build.ArtifactStagingDirectory)
I am assuming that the $(BuildConfiguration) variable is custom to your definition and is probably Debug or Release. I am not sure what exactly the Run dotnet step does, but this build definition I setup published my build artifacts correctly. The Publish Build Artifacts step I'm running has the same steps as yours, except the only control option enabled is Enabled.
I am also running on TFS 2015 update 2.
You can download the files if you just want to take a look at them. Go to the build, click on the Artifacts tab, and then download as shown below:
You need to specify output argument (--output/-o) for dotnet publish command.
Arguments:
Publish -c $(BuildConfiguration) -o $(Build.ArtifactStagingDirectory)
BTW: You said “run dot net” step says “Published to D:\a\1\s....”, the files are in D:\a\1\s, no files in D:\a\1\a (one is s and another is a).

Purpose of Test scripts for Appveyor? Intergration with Codecov

We have started using Appveyor for CI with our Github repo and all has went fine. We have our build script working (appveyor.yml) in the repo, and it successfully builds and produces an artifact. Now on to my question
We are trying to pair our builds now with codecov.io which says it will scan it during the CI build. And it does support appveyor, it merely says to add this to the yml
after_test:
- bash <(curl -s https://codecov.io/bash)
Which we did, but nothing happens. Does this mean i need an actual test script to run, before it will send off the code to codecov? It is a C# project, and we have it compile, and generate the .exe which we then package into a zip which can be downloaded.
What are the point of these "test scripts" when we already know it compiles and produces an exe? I am a bit confused on how to use this properly..
I believe here https://github.com/codecov/example-csharp is good example of running codecov tests on C# project with working Appveyor configuration. Please look at readme.md file in that repo for greater detail.
From the Documentation
You need to add the OpenCover nuget package to your Visual Studio solution which is used to generate code coverage analysis:
PM> Install-Package OpenCover
Secondly, you need to either write a PowerShell script (if you intend to generate code coverage and upload the result interactively) or you need to add a few entries in you CI config file (if you intend to let your CI generate the coverage).

Auto increment appx package version after each build

I am looking for a solution to automatically increment a package version (not to be confused with an assembly version) after each build on CI server (particularly Atlassian Bamboo). Every appx package has a version defined in its manifest file (appxmanifest). Thus in order to increase the version a manifest must be edited before commit. I am considering different approaches to implement this. The first one makes changes in manifest and pushes it back to the repo.
Starts building a plan (in order to lock a build number)
Modifies manifest so that a revision is set to the current build number
Pushes changes to SCM (particularly Atlassian Stash). This step shouldn't trigger the next build.
Continues building the package (invoke MSBuild, UT and other tasks)
Cons
Leads to incorrect workflow on Bamboo: checkout -> push -> build
Each build makes a new commit
Another approach is to setup post receive Stash hook which would modify appxmanifest.
Cons Hard to keep a build number in sync with Bamboo.
Is there any other (cleaner and proper) way to achieve this?
ex-Stash developer here (not that it matters),
I would highly recommend not checking in derived/version information or files. It's going to cause you no end of problems (some of which you have pointed out in your question).
My advice - generate what information you need on the build. I don't know anything about appx packaging, but can you use a placeholder/property (like this) which can be resolved on the Bamboo build? For our builds we use the git hash and timestamp as the version, and in the past I've also used the job/build number (timestamp is better though).
As more food for thought - if that appx version is important for developers to see locally, and it becomes hard to match up with the Git version then you can also attach a Git tag/note to the commit in Bamboo as well. The nice thing about that is that anyone fetching from Git can easily see that extra metadata, but it doesn't result in extra commits for every build. If the appx version need to be based off the previous version then this makes it possible for the build scripts to inspect the previous commit and bump the version appropriately.
I hope that helps.

Can i get TeamCity to do what web essentials does? Less files and Bundles?

I am trying to get TeamCity to build less files and generate my bundles.
Is this possible in Team City?
Sure it is. Anything you can run from command line you can create a build step for. So, you need to find a script you can trigger from commandline (MSBuild for example, there's even a build runner for MSBuild). I would probably collect all build files as artifacts that I can later download directly from TeamCity. Something like this (all separate build steps):
Build everything
Generate css files and bundles (maybe part of step 1).
Generate msi file using something like WiX.
Collect artifacts within TeamCity.
This is a very nice setup, in my view. Probably you need to ask for more help on each step separately.
Good luck!