MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

Build services - an overview

Our 1.6 release shipped a number of interesting new features and enhancements to existing features, including those for MyGet Build Services. In this post, we’ll describe existing and new features and enhancements in a bit more detail.

One important thing to know is that Build Services is intended to make packaging projects easier. We are not aiming to become a full CI server like TeamCity of Team Foundation Server. That said, we do believe Build Services is appropriate for many scenarios and can take a lot of work out of your hands. We found some blog posts you may like: Nico Vermeir is using Build Services to package Windows Phone libraries. We also use it ourselves to push components from GitHub to NuGet.org.

Specify build configuration and platform

When creating or modifying a build source, you can now specify the configuration and platform that should be built. Easily switch between Release (the default configuration) or Debug or any other configuration that exists in your solution. The same goes for platform: if you wish to specifically build for x86, this can now be specified as the target platform.

Build configuration and platform

Note that we also set a %Configuration% and %Platform% environment variable during the build process. This way you can make use of these in your customized builds that are run using a build.bat file.

Package versioning

In earlier versions of MyGet Build Services, we’ve been generating a random incremental version number for packages created during build. From now on, we have support for true incremental build numbers through the build source settings

Specify package version number

The build counter starts with zero and increments with 1 on every build. You can also specify a version format ( Iuse '{0}' as a placeholder for the build counter) which will be generated during build. Note that if you enable the forbid packages which are non-compliant with Semantic Version option ,you should make sure the version format specified follows the Semantic Version rules.

We also set a %BuildCounter% and %PackageVersion% environment variable during the build process. This way you can make use of these in your customized builds that are run using a build.bat file.

Supported project types

We’ve added support for psake builds (use a built.bat file and invoke psake). Building Windows Phone 8 packages is now also supported out of the box. This brings us to the following list of supported frameworks and SDK’s:

  • .NET 2.0, .NET 3.0, .NET 3.5, .NET 4.0 and ,NET 4.5
  • PCL support (2012)
  • Windows Azure SDK
  • Windows Identity Foundation SDK
  • Silverlight 4, Silverlight 5
  • TypeScript SDK
  • psake

Regarding test runners, we now support

  • MsTest
  • MbUnit 2, MbUnit 3
  • NBehave
  • NUnit (up to 2.6.2)
  • xUnit.net
  • csUnit
  • RSpec

We believe adding these SDK’s out-of-the-box provides a lot of value to our users and we want to continue investing in expanding the number of supported SDK’s.

Environment variables

As part of the build process, we now set the following environment variables. Note that these are all read-only.

%BuildRunner%

Always "MyGet", can be used to determine if running on MyGet Build Services

%NuGet%

Path to a maintained-by-MyGet NuGet.exe

%SourcesPath%

Path to source code being built

%Configuration%

Build configuration (defaults to Debug)

%Platform%

Platform to build (defaults to blank)

%VersionFormat%

Version format specified in build configuration

%BuildCounter%

Build counter value

%PackageVersion%

%VersionFormat% with %BuildCounter% filled in, used as the auto-generated package version number

%EnableNuGetPackageRestore%

NuGet package restore enabled? Always true.

Other features

Some smaller features have been implemented for version 1.6 as well.

  • When building from GitHub/BitBucket, a link to the changeset that has been built is available from the build services tab.

image

  • Hanging build detection: whenever a build hangs for > 15 minutes, we kill the build process and set the build status to failed.
  • The build log can be copied to clipboard.
  • Build status is refreshed automatically.

Happy packaging!

Support for Package Source Discovery draft

We’re proud to announce support for the NuGet Package Source Discovery (PSD) draft on MyGet. Package Source Discovery (PSD) allows for NuGet-based clients tools to discover the feeds that are hosted by a user or organization by using the blog or website URL. Every feed hosted on MyGet has a discovery endpoint hosted at http://www.myget.org/Discovery/Feed/<yourfeed>.

In its simplest form, you can place a simple HTML tag on your website or blog and use that for discovering all feeds you own, whether on MyGet or another NuGet package repository such as TeamCity or the NuGet gallery.

Package Source Discovery

NuGet Package Source Discovery is an attempt to remove friction from the following scenarios:

  • An individual user may have several NuGet feeds spread across the Internet. Some may be on NuGet.org (including curated feeds), some on MyGet and maybe some on my corporate network. How do I easily point my Visual Studio to all my feeds accross different machines? And how do I maintain this configuration?
  • An organization may have several feeds internally as well as one on MyGet and some CI packages on TeamCity. How can this organization tell his developers what feeds they can/should use?
  • An organization may have a NuGet server containing multiple feeds. How will developers in this organization get a list of available feeds and services?

For all scenarios, a simple feed discovery mechanism could facilitate this. Such feed discovery mechanism could be any URL out there (even multiple per host).

As an example, open Visual Studio and open any solution. Then issue the following in the Package Manager Console:

Install-Package DiscoverPackageSources
Discover-PackageSources -Url "http://www.myget.org/gallery"

Close and re-open Visual Studio and check your package sources. The URL has been verified for a PSD manifest URL and the manifest has been parsed. Matching feeds have been installed into the NuGet.config file, in this case all feeds listed in the MyGet gallery.

Discovery for your feed(s)

By default, we’ve enabled discovery on your profile page. For example, http://www.myget.org/users/maartenba provides discovery for all my (public) feeds. Of course, you can also create your own discovery URL on your blog or website: simply add a <link /> element to the HTML code. From then on, you or your users can use the following command to discover feeds from your website or blog:

Install-Package DiscoverPackageSources
Discover-PackageSources -Url http://<your website>

On your feed’s discovery page, we’ve added the HTML you have to add to your website to enable this scenario.

image

Discovery for gallery feeds

We’ve added a discovery on the MyGet gallery. When using http://www.myget.org/gallery as the discovery URL, all gallery feeds will be registered in your NuGet.config file. Every feed on the gallery in itself also provides discovery, for example ScriptCS has a discovery endpoint at http://www.myget.org/gallery/scriptcsnightly.

Please provide feedback on the Package Source Discovery specification. Comments on the MyGet implementation are also welcome!

Happy packaging!

Release notes for MyGet 1.6

Many users have asked for us to provide release notes for everything we put online. Since that’s a great idea we’ll start doing this with the current 1.6 release which has been deployed earlier this week. But before we dive into that, let’s give you some hints about our development process and versioning system.

Our development process and versioning system

If you look at the footer of our website, you’ll have seen the following for the past few weeks already:

image

That’s right: we’ve been on (parts of) version 1.6.x for the past few weeks already. The reason for that is we version after our sprints and do continuous deployment of most things we work on. This means that when we start deploying features for our v1.7.x sprint, we’ll already update the version number in the footer to that number yet we’ll provide release notes only at the end of our sprint. So while today, you may already see v1.7.x mentioned in our footer because we've already deployed some features from that sprint, the following release notes are valid at time of writing this post.

Release notes for MyGet 1.6

MyGet 1.6 was released on February 25, 2013.

Features

MyGet

  • Minimum length for usernames has been decreased to 3 characters (previously 6). Shorter usernames are now possible.
  • A new menu item under feed: "Feed Settings" will contain settings specific to how MyGet handles packages for a given feed.
  • Feed settings contains an option to enable/disable overwriting of packages on the feed
  • Feed settings contains an option to enable/disable validation on the package version number with regards to Semantic Versioning
  • Dashes and underscores in feed names are supported. Feeds can be named foo-prod for example.
  • Download feed as ZIP.
  • Package Sources are out of beta.
  • API key in package source configuration is now masked

MyGet Enterprise

  • Block e-mail addresses not belonging to the organization.
  • Users can be made administrator.
  • User removal (with the option of transfering their resources to another user).

MyGet Build Services

  • Copy build log to clipboard.
  • Specify build configuration and platform (Release/Debug and Any CPU/Mixed Platforms/...)
  • Support incremental build numbers.
  • Support configuring the build number using a template. Register version number as an environment variable.
  • Support building Windows Phone 8 projects.
  • Hotlink commit on GitHub/BitBucket from the build list.
  • Refresh build status automatically.
  • Support creating tools packages.
  • Hanging build detection.
  • Install psake on the build servers.

Bug Fixes

  • Copy to clipboard on feed details page did not work in Chrome version 24.0.1312.57 and up.
  • Feed statistics are not updated in some situations.
  • NuGet Package Explorer always shows prerelease packages in the feed list.
  • Build Services: building from protected SVN repositories isn't always working.
  • Build Services: GitHub API only returns 30 repositories.

Happy packaging!

Introducing activity streams

In a previous post we highlighted the new user profile page and briefly mentioned we are working on activity streams. If you look at the Activity tab of your profile, you'll still see that it is coming soon.

We are still working on the UI for this part, but before we introduce it to the masses we need to take care of a few more things. No worries, a clear communication about these changes will be done upfront, and we obviously will keep private feed activity secured. A lot of stuff is happening under the hood, really, in order for this feature to be rolled out smoothly. Our incremental and short release cycles are starting to pay off (or you'd end up with blank activity streams upon release).

However, you might notice that we already built an initial UI for the feed activity. Simply take a look at your feed details page and check the Feed Activity tab on the left menu.

We are working hard on providing you with historic information on packages and feeds throughout the site so expect more to come soon. We believe this will greatly improve the experience of both package publishers as consumers, as well as those interested to keep up with what's happening on the feed or with a specific package. There's some great stuff on some of the feeds in our Gallery and we'd like to give you the opportunity to get notified of the package repository events you want to track.

The below screenshot also gives you an idea of the kind of activity you might be interested in: adding or deleting packages, unlisting packages, pushing packages to an upstream package source (e.g. to NuGet.org), etc. The particular feed activity you can see below is the result of how we push the GoogleAnalyticsTracker package to NuGet.org.

Happy New Year & Happy Packaging!

Cloning feeds is now supported

It happens that for some reason you require a full copy of an existing feed. You may want to do some upgrades. Maybe you just require your development feed to be copied as a production feed or vice-versa. Our latest deployment provides you with a fresh feature: cloning feeds.

From the feed list (www.myget.org/feed/list), simply click the “Clone” button next to a feed. Note that this will only be shown for feeds that are owned by you.

image

After a couple of minutes, your feed clone will be up and running.

image

Happy packaging!

Introducing a new profile page

Our latest service deployment features a fresh user profile page. You’ll be able to see everything you need by just clicking the Profile link. You’ll be able to see your feeds, linked identity providers, payment history and more.

image

You can also look at other user profiles. Simply browse to the MyGet gallery and you’ll be able to find out who’s behind a given public feed.

image

Yes, you’re seeing what we’re up to: in one of our next releases, we’ll be providing you with activity streams that give you an overview of what’s happening on a given feed or by a specific user.

Happy packaging!

Package retention policies

So you’re pushing your packages from your build server onto MyGet. That must result into a large number of packages! Or you want to keep only the latest 2 versions of a given package? Have no fear, package retention policies are here!

Under your feed, navigate to the Package Retention tab.

image

By default, we keep all package versions available on your feed. If you would like to do some automated housekeeping, you can now specify the number of stable and prerelease packages to keep on your feed. Whenever a package is added to your feed, we'll make sure these retention rules are respected.

Happy packaging!

Add packages from GitHub, BitBucket and CodePlex using MyGet build services

We’re pleased to announce some new features to MyGet build services. This feature allows you to add packages to your MyGet feed from any Git, Mercurial (hg) or Subversion repository out there. We’ll grab the sources, compile, package and make sure the result is listed on your feed. While still in beta, the feature is starting to take shape. In our latest release, we’ve shipped some interesting new features related to build services.

From your feed details page, you can navigate to build services. The “Add build source…” button has been around since the start and allows you to enter details of the source code repository manually. Because that can be a bit clumsy and since most public source code repositories out there have API’s available, we now support linking GitHub, BitBucket and CodePlex repositories with the click of a button!

image

After clicking one of these, you’ll be redirected to the code hosting provider for login.

image

After that, you can just check the projects you wish to add and link them automatically.

image

Apart from being able to easily link projects from GitHub, BitBucket and CodePlex, we also improved the build server itself a bit:

  • Support for portable libraries
  • TypeScript SDK 0.8.1.1 has been deployed
  • Private repositories on BitBucket now can be referenced
  • Git repositories with submodules can now be built (do note the submodule must be available over HTTP/HTTPS)

Happy packaging!

NuGet package restore from a secured feed

One of the most frequently asked questions at MyGet is the following one (we have pending updates to our FAQ section):

How do I set up NuGet package restore against a private MyGet feed requiring authentication?

This is also one of the things you might end up doing when debugging NuGet package restore issues.

For public feeds, you only need to change the repository URL in the nuget.targets file to let your build server know from where it needs to fetch the packages. For private feeds however, there are a few things you need to know.

Which credentials should I use?

At MyGet, we recommend you to create a separate account for your build agents and give it specific permission on your feed (e.g. readonly or read/write, but no additional permissions).

It is not a technical requirement though: you could simply use your personal account, but please be aware that in this case you share your credentials!

As you'll see in this post, you can store the credentials for the build service account on the build agent(s) without having to share them with anyone. Using a user's account for the build agent can break anyone's build if access for this user is revoked...

Visual Studio will prompt for credentials

As soon as you try to communicate with a secured package source in Visual Studio, it will prompt you for credentials. So why do you get the following build error when using package restore?

There's no non-interactive way to provide credential parameters

NuGet package restore relies on the NuGet.exe commandline tool by using the install command. The commandline will either prompt you for credentials (which isn't suitable for automated build scenarios), or will look for credentials in nuget.config file in %AppData%\NuGet\nuget.config (if you use the Non-Interactive option).

The latter looks like what you need in automated build scenarios, but requires you to store feed credentials on the machine, for the user account that will perform the build. This can become cumbersome if you have a multitude of solutions using this feature.

Hierarchical NuGet.config doesn't take credentials into account (yet!)

The latest version of NuGet has support for hierarchical nuget.config files, which is an attempt to overcome the need to store everything on the machine. It allows you to have a solution-level NuGet configuration which should be taken into account during package restore.

This means that feed URL and credentials could be stored next to your solution instead of being pre-configured in the user profile. However, credentials aren't picked up (yet), and there's no easy way to store them (encrypted) into any nuget.config file other than the one in your roaming user profile (explained in the next section of this post).

This is a known issue which seems to be fixed in vNext of NuGet. Check this Codeplex issue for more details. Not sure though whether this will be facilitated without having to copy-paste those encrypted credentials from one config to another.

You can store feed credentials in your user-profile NuGet.config

That's likely to be the easiest approach: as you register the package source URL, you might want to save the required credentials as well. This is however not exposed in the Visual Studio NuGet Package Manager extension, so you'll have to use the NuGet.exe commandline tool. The following gist illustrates a few of these options that should help you configure your secured feed, including credentials.

MyGet logo stickers

We're fairly sure the mailman didn't know he was carrying more than one package this morning when handing over the enveloppe. To celebrate our new logo, we've been handing out free subscriptions to our Starter plan during the past few days. Follow us on Twitter for future announcements (our Features page is growing!) and perhaps a chance to win.

Today we're happy to announce we'll be handing out some of these cool stickers during our upcoming trips! Thank you StickerMule for a job well done!

Want to get some? Then don't miss the opportunity to meet our team members and learn how we built MyGet at these upcoming events:

See you there & Happy Packaging!