MyGet Blog

Package management made easier!

NAVIGATION - SEARCH

Maven packages just arrived on MyGet (Early Access Preview)

Let's go straight to the meat: we just opened our Early Access Preview (EAP) for Maven support! If you're packaging .jar and .war and have a pom.xml to go with them, you can now add these to your MyGet feeds (or should we start calling them repositories).

To enable Maven support on your account, simply click here. This will enable the feature toggle on your account and give you access to the Maven features described in our documentation.

Which features are available in this EAP?

We currently support almost all features we have available for other package managers: uploading your own packages (via the web UI as well as via mvn or Gradle) and adding packages from upstream repositories like Maven Central. Packages can then be consumed in IntelliJ IDEA or Eclipse, using Maven or Gradle. It's possible to proxy upstream repositories into your MyGet feed. You can manage permissions and users, inspect package licenses and vulnerabilities, ...

A Maven repository on MyGet can also be used as a staging area: packages and snapshots can be published on MyGet, and once they are stable, pushed upstream to another repository out there - similar to what is possible for NuGet and NPM.

We're looking into supporting build services as well (theoretically you can already create a build.bat and invoke `mvn deploy` from it), but we'd love your feedback on what the perfect convention-based build for Maven/Gradle would look like.

I want to join the preview!

If you are interested in joining the private preview and eager to provide some early feedback, click here to enable Maven support for your account. Our getting started documentation is available as well.

We're really excited about introducing Maven support on MyGet! You can now use MyGet to securely host and collaborate on NuGet, symbols and sources, Chocolatey, PowerShell, NPM, Bower, Maven and VSIX packages.

Happy packaging!

Configure which feed a token can push packages to - introducing feed-scoped access tokens

Many development teams are making use of a continuous integration server like TeamCity, Jenkins or VSTS to build their projects and push generated NuGet, npm, Bower and VSIX packages to their MyGet feed. When having multiple feeds, it is a good practice to limit the feeds this access token/API key can push packages to, ensuring the surface area of the specific access token is limited to just the feeds the access token requires access to.

In short, scoped access tokens:

  • Are a good security best-practice: use minimum required permissions for a specific operation
  • Avoid services/users accidentally pushing packages by using read-only tokens where possible
  • Allow pushing packages without the ability to get access to other packages on the feed (write-only)

New access tokens and existing access tokens can be scoped in terms of what they can do. We now let you to create read-only or write-only access tokens, optionally limiting write access to just one specific feed.

Create new access token scoped to a given feed

Next to scopes, the access token expiration date and time can also be specified, making it possible to create a time-limited access token that has to be recreated to continue having access to the feed.

Happy packaging!

Learning NuGet Semantic Version Ranges with SemVer Explorer

When authoring NuGet packages, you can declare package dependency versions using Semantic Versioning. NuGet allows specifying dependencies as floating ranges, using interval notation or using fixed version numbers, as explained in the NuGet docs.

MyGet SemVer Explorer allows you to specify a SemVer dependency range, and will check the target package repository for the package versions that match.

NuGet dependency range explorer

Version ranges can be simple (e.g. 6.1.* to match all packages >= 6.1.0) or more complex using interval notation (e.g. (8.0,9.0.1) to match versions that are between 8.0 and 9.0.1. SemVer explorer lets you try these ranges and see which versions of an actual package match. Once satisfied, version ranges can be used in a packages.config or project.json document for use with NuGet or the .NET Core command line.

Can I target MyGet feeds?

Definitely! By default, the tool is configured to query the v3 NuGet.org repository at https://api.nuget.org/v3/index.json. You can simply change the target feed URL to the v3 NuGet feed of a MyGet repository you have access to, and we'll query that one instead.

Can I target private MyGet feeds?

If you have an access token that grants you read-access to the MyGet repository, you can leverage MyGet's support for pre-authenticated feed URLs. Make sure you target the pre-authenticated v3 NuGet endpoint. See our documentation for further guidance.

Have fun exploring the various semantic version constraints NuGet provides! And happy packaging!

Checking potential vulnerabilities in project dependencies

Software projects nowadays are based on many third party and open source libraries. It is important to be aware of any potential security vulnerabilities in these components, to ensure our own software project is secure. Thanks to OSSIndex and Vor Security, we now have a vulnerability report ready for your MyGet feed!

While still in preview, every feed now has a Vulnerabilities tab which reports potential vulnerabilities in packages on that feed, whether NuGet, npm or Bower.

vulnerability-report

The vulnerability report provides us with an overview of potential vulnerabilities in our dependencies. We can also see the percentage of packages with potential vulnerabilities versus the percentage of packages with no known vulnerabilities.

Give it a go, we’re looking forward to your feedback on this new feature! Leave your comments below or reach out on Twitter.

Happy packaging!

Building NuGet and npm using Atlassian Bitbucket Pipelines

Bitbucket Pipelines is a new continuous integration service (still in beta) from Atlassian, built into Bitbucket. Let’s have a look at how we can use Bitbucket pipelines to build, package and publish a .NET Core library to MyGet so we can consume it in our own projects.

How does Bitbucket pipelines work?

To configure a build on Bitbucket, we’ll need a bitbucket_pipelines.yml file which describes the steps to execute as part of the pipeline. Whenever a commit is made to our source repository on Bitbucket, whether git or Mercurial based, a Docker image is started in which our pipeline will be executed.

Here’s a full write-up on how a .NET Core build would work.

How to package and publish a NuGet package to MyGet?

First of all, we’ll need a bitbucket_pipelines.yml file which loads a .NET Core-enabled Docker image. The pipeline itself will have to run package restore, compile the source code, optionally run tests, then package the library and publish it to our MyGet feed.

We have created a sample library at https://bitbucket.org/myget/sample-pipelines-dotnet/, from which the bitbucket_pipelines.yml file can be copied into your own project. A few environment variables need to be configured for the pipeline (see the header of the bitbucket_pipelines.yml file) to make sure it can publish to our MyGet feed.

Once the pipeline completes, we can look at the build output and find the resulting NuGet package on our MyGet feed. The full build output is available as well.

image

How to package and publish an npm package to MyGet?

First of all, we’ll need a bitbucket_pipelines.yml file which loads a Docker image which has node and npm installed. The pipeline itself will have to run npm install, optionally run tests, then package the library and publish it to our MyGet feed.

We have created a sample library at https://bitbucket.org/myget/sample-pipelines-npm/, from which the bitbucket_pipelines.yml file can be copied into your own project. The header of this file lists a few environment variables that have to be configured for the Bitbucket pipeline. When run completes, we can consult the build output:

Publishing npm from BitBucket

Happy packaging!

Keeping feeds clean with retention rules

MyGet Package Retention Rules help clean up your NuGet npm feedMany developer teams use MyGet for storing their continuous integration and/or nightly builds of NuGet, npm, Bower and VSIX packages. As more and more packages get added, it may become harder to manage them all. Some packages may be used in projects, while others are not. Let’s go over the options available for housekeeping.

By default, MyGet keeps all package versions available on our feeds. Every package pushed is there forever, unless manually removed or removed by package retention. By setting retention rules, it is possible to automatically trim the list of packages to X latest packages, keeping into account package usage in projects and package dependency trees.

Configuring retention rules

Retention rules are defined per feed. Some feeds may have more aggressive retention rules defined, other may not have them enabled at all. From the Retention Rules, we can define:

  • the maximum number of stable versions to keep
  • the maximum number of prerelease versions to keep
  • whether to keep depended packages or not – enabling this makes sure package restores always complete successfully by keeping the dependency tree in its entirety
  • whether to allow removal of packages that have downloads – enabling this option ensures that packages that are being used in projects never get deleted

Setting retention rules

Keeping a specific package around

Retention rules are quite brute-force: they will always remove all packages that match the configured rules. Luckily, MyGet lets us “pin” packages which we want to keep around. For example, we may want to only keep the latest 10 pre-release versions while still keeping around the 20th pre-release version we’re still using in our projects.

From the package details page, we can define which package versions should never be considered by retention rules by using the Pin button next to the package.

Pinning packages so they do not get removed

We can pin package per version, or all versions at once using the button at the top of the Package History list. Of course, we can also Unpin packages using the same approach. Once a package is unpinned, retention rules are allowed to remove them.

Custom retention rules using web hooks

Using the built-in retention rules may not be enough. For example, what if we want to run retention rules based on other conditions than the latest version? What if we want to only remove packages when there is a full moon? Using web hooks, we can subscribe to certain feed events (like “package added”) and run our custom logic to optionally remove packages from our feed. We have a complete example available that helps getting started with web hooks.

Learn more about package retention in our documentation.

Happy packaging!

Improved build log viewer with error navigation

We have just deployed a newer version of our build log viewer. When using MyGet’s build services to compile and package NuGet, npm or VSIX packages, the build log viewer now has colored output as well as line numbers that have hyperlinks. Want to share a certain line in the build log with a colleague? Click the line number and send the link so they can open the build log right where you left.

By making less important build output less prominent and by highlighting more important messages, reading and analyzing the build log becomes much easier: less important messages have a gray color tone, normal messages are white. Warnings and errors are highlighted in yellow and red, making them much easier to spot.

Build log with colored output

When warnings or errors are found in a build log, MyGet now shows additional navigation buttons at the top. Next to the number of warnings or errors, the up and down arrows can be clicked to jump to the next important message in your build log.

Warning and error navigation

We’re looking forward to hearing your thoughts on this improvement. Let us know through the comments below or drop us a note via e-mail or Twitter.

Happy packaging!

Setting an expiration time for your MyGet access tokens

From a security perspective, it is always good to have secrets that are only valid for a given amount of time. This ensures that these secrets have to be rolled over more often, resulting in a better overall security policy. Today, MyGet introduces expiring access tokens and API keys to accommodate this workflow.

From your profile page, you can manage your access tokens. The list of access tokens will always contain a primary key, and additional access tokens can be created.

Manage MyGet API keys

When creating (or editing) an access token, we can set a description to identify where the access token is being used. We can now also (optionally) set an expiration time after which the token can no longer be used. This can be done for additional tokens, as well as for the primary access token.

Create MyGet access key for accessing NuGet server

This change is live on all MyGet plans, so go ahead and set the expiration time for your access tokens!

Happy packaging!

Using build services to create Chocolatey packages

Chocolatey is a Machine Package Manager, somewhat like apt-get, built with Windows in mind. It lets us install software onto our machine, supports updates and dependencies, much like NuGet or npm do. MyGet has always supported feeds containing Chocolatey packages, making it easy to distribute software packages across teams or with customers. In this post, we’ll show you a trick on how to build Chocolatey packages using MyGet build services. It’s the least we can do as a Belgian company – our country is known for chocolates after all…

MyGet Build Services has a convention-type build approach that will create NuGet, npm and VSIX packages whenever required files or project types are available. By adding a build.cmd or build.ps1 file, this convention can be overridden – just the thing we want to do to create Chocolatey packages.

Using a little bit of PowerShell, we can call into Chocolatey’s choco.exe which handles packaging and verification. The following can be copy/pasted in a build.ps1 file in the root of a GitHub, BitBucket or VSTS repository:

Write-Host "Building Chocolatey packages..." $nuspecs = Get-ChildItem -Path $PSScriptRoot -Filter *.nuspec -Recurse foreach ($nuspec in $nuspecs) { choco pack $nuspec.FullName } $artifactsFolder = "./artifacts" Remove-Item -Path $artifactsFolder -Force -Recurse -ErrorAction SilentlyContinue New-Item $artifactsFolder -Force -Type Directory | Out-Null Move-Item *.nupkg $artifactsFolder Write-Host "Finished building Chocolatey packages."

Once a build is triggered on MyGet, this script will execute and create (and upload) Chocolatey packages to our MyGet feed, which we can then install on our system.

Happy packaging!

Using service messages to explicitly add a package to MyGet

MyGet build services is a convention-based build system that converts source code into NuGet, Npm and Vsix packages. It will compile code, run tests and collect the packages that were created and add them to your MyGet feed. Sometimes, for example when using custom build scripts or using gulp or grunt to run the build, we can’t always detect which packages were created. To add these packages to your feed, you can use service messages.

By writing a service message (a specially formatted string) to the build output, you can influence part of the build process. For example fail the build, update the version number, setting environment variables and so on. We recently added the publishPackage service message, which lets you specify additional packages to add to your feed when the build succeeds. The following example pushes the mypackage.zip to your feed as a Bower package:

##myget[publishPackage path='mypackage.zip' type='bower']

Check our documentation for additional options and remarks and give it a try. We’d love to hear your thoughts!

Happy packaging!