Support for native Windows/.NET builds on Pipelines

Issue #13452 open
Vladimir Golubev
created an issue

As a .NET developer and big fan of Atlassian i want to migrate my CI processes (TeamCity on Windows instance in AWS cloud) to Bitbucket Pipelines.

Features that many .NET devs (who use Bitbucket) would like to have:

  1. Build windows apps (asp.net mvc5, .NET 4.6 apps).
  2. Use Bitbucket Pipelines as a CI server and don't host any TeamCity instances...
  3. Add a private nuget feed that will contain latest versions of our internal packages (like nuget feed plugin for TeamCity) as a .NET developers we use our own nuget repository for company packages.

Official response

  • Raul Gomis staff

    Hi everyone,

    I'd like to share a status update on the Windows/.NET builds support in Bitbucket Pipelines:

    We developed an internal-only pilot for Windows builds and we found two outstanding blockers:

    • No network policy support: We cannot go live without some form of network policy enforcement available in a shared infrastructure.
    • Pods using Hyper-V isolation only support 1 container per pod: this is supposed to be fixed in the next release of Kubernetes. More details can be found on the Windows K8's Roadmap.

    We are currently in conversation with the different teams at Microsoft and Tigera to get a more accurate timeframe for when the external teams will have the necessary changes in place. The current estimate for when all of these changes will be available is end-2018.

    Based on this, it is unlikely that we'll have anything production ready for Bitbucket users until mid-2019, always subject to change based on the progress on the blocking issues.

    We'll continue to keep you updated on the progress of this feature request. In the meantime, I'd love to better understand everyone's use cases and requirements for Windows builds. If you'd like to share your use cases for this feature, please send us an email at pipelines-feedback@atlassian.com and we can schedule a convenient time to chat.

    Regards,
    Raul

Comments (47)

  1. Matt Ryall staff

    Thanks for the suggestion. We don't have plans to offer this in the short term, but we'll keep this feature request open to get customer feedback and votes.

    I'll rename this ticket to "native Windows builds", so we can keep the discussion of the implementation approach (e.g. Docker vs VM) outside the request for building projects on Windows in Pipelines.

  2. Matt Ryall staff

    The technical barriers around Docker support are gradually removed by Microsoft, but there's still a substantial effort required for Pipelines to support running customer builds on Windows. So we are prioritising other more highly voted feature work currently, like multiple steps and scheduled builds.

    The background is that Pipelines currently runs on a Kubernetes cluster of Linux Docker hosts, so we're limited to running .NET Core applications on these hosts. Supporting the dotnet-framework container would require us to spin up a cluster of Windows Server Docker hosts and use a different orchestration technology.

    Interestingly, Microsoft's advice seems to be that new microservices projects should be built using .NET Core rather than the full .NET Framework. So if you want to try Pipelines on a new .NET Core project, that might be a good way to get started with us.

  3. Josh Santangelo

    I'd suggest a revision to this feature request, there are many Windows projects that I'd like to use Pipelines for which are not .NET. (Unity, node, C++/Cinder/OpenFrameworks)

  4. Matt Ryall staff

    Good call. I've updated the issue title to make this clear. If we were to build this feature it would be for native Windows builds that would support anything you can build on a Windows host.

    Unfortunately, for now this feature is on hold while we address other more important issues like multiple steps and deployment features over the next six months. In the meantime, this is still the best place to vote, watch for updates and describe any new use cases not covered by the comments above.

  5. Joshua Gribbon

    Has anyone found a workaround for this?

    I'm currently trying to use mono/xbuild on ubuntu but getting some assembly reference errors that don't happen with msbuild locally.

  6. Alexander Logvinenko

    As a workaround can be using appveyor or migrating your project to .Net Core. That's it. Also I've recently started another project on .Net Core and found it awesome. Only too old libraries could cause problems while migrating. All modern ones are compatible with .Net Core. So I understand bitbucket team why they do not hurry with this feature.

  7. Matt Ryall staff

    Thanks for the reminder - time for an update on this one. No actual development work has been done yet, but our plans for this are firming up.

    An internal-only pilot for Windows builds is planned for next quarter (Apr-Jun). This will help us understand what's required to build this for real, and where the showstoppers are with running Kubernetes nodes on Windows Server hosts.

    Unfortunately the pilot must be internal-only because of some outstanding issues with network isolation between Docker containers on Windows. These need to be fixed by Microsoft, Docker and Kubernetes before we can roll anything out to Bitbucket customers. But we're still going ahead with a pilot so we can scope out the rest of the work and deliver it once the networking issues are resolved.

    Based on this, the absolute earliest we could offer any native Windows support would be late 2018, but this will depend a lot on how the pilot goes and how Microsoft's Docker support advances in the coming months. We'll keep you posted on any progress.

  8. Joshua Gribbon

    An update from someone who's trying to get around this:

    We looked into migrating to .NET Core because that would be needed to use pipelines. For us, the migration wouldn't have been worth it just to use pipelines, but it offered a great opportunity to clear out a bunch of tech debt and take advantage of the performance improvements and other nice features that come with core, and then we ultimately get to use the tight integration with Bitbucket/Pipelines. We're finishing the migration in the next week or two, it's been relatively painless, and overall it seems like it was a great move. Our project had a lot of things that were worth fixing and wasn't too complex, but this could be a really hard sell depending on the state of your project and organization.

  9. Patrice Boulet

    +1 We want to migrate from Bamboo server to cloud and there is no way for us to do so with our .NET 4.5 projects without a significant amount of work to port to .NET Core.

  10. Craig Bekker

    It would make me really happy to swap out team city for this. code, build and deploy in one place. I don't really think ill win convincing my boss to convert to VSTS. also I'm used to TFS so it will be nice to try something new for a change.

  11. Cristi Hotescu

    .NET Core has been mentioned a couple of times as the way to make it work with pipelines, but all I can see so far is 1 (one) .NET Core project per repository, per pipeline.

    How can we get pipelines working with a .NET Core solution that contains multiple projects, for example, a UI project (e.g. an mvc app) and an API project? The whole solution is checked in, in one single repository and the goal would be to have one pipeline for the UI project and a separate pipeline for the API project, each would trigger a deployment to a separate target environment. Again, both projects in one single solution that goes into one single repository.

    Is the above scenario supported?

  12. Cristi Hotescu

    Hmm.. I was directed to this feed by Bitbucket support saying that is not supported (and I didn't find any documentation about it).

    When you mention the steps, doesn't that mean that both projects will be deployed, regardless of which one was changed? (any checkin will fire the pipeline). I would like to deploy only the project for which I've made a change and don't bring down everything else. Is there a way to associate a step with a "sub-section" of the repository? (everything related to project XYZ).

  13. David Mccheyne

    Cristi, Have you considered breaking up a repository that has "sub-sections"? Have you considered using git submodules? That's how we accomplish this sort of case, and is what git recommends as well. If you need more help, consider opening a new support request so we don't clutter up this unrelated issue. :)

  14. Raul Gomis staff

    Hi everyone,

    I'd like to share a status update on the Windows/.NET builds support in Bitbucket Pipelines:

    We developed an internal-only pilot for Windows builds and we found two outstanding blockers:

    • No network policy support: We cannot go live without some form of network policy enforcement available in a shared infrastructure.
    • Pods using Hyper-V isolation only support 1 container per pod: this is supposed to be fixed in the next release of Kubernetes. More details can be found on the Windows K8's Roadmap.

    We are currently in conversation with the different teams at Microsoft and Tigera to get a more accurate timeframe for when the external teams will have the necessary changes in place. The current estimate for when all of these changes will be available is end-2018.

    Based on this, it is unlikely that we'll have anything production ready for Bitbucket users until mid-2019, always subject to change based on the progress on the blocking issues.

    We'll continue to keep you updated on the progress of this feature request. In the meantime, I'd love to better understand everyone's use cases and requirements for Windows builds. If you'd like to share your use cases for this feature, please send us an email at pipelines-feedback@atlassian.com and we can schedule a convenient time to chat.

    Regards,
    Raul

  15. Jules & Amy Clements

    As an alternative, has Atlassian considered support user managed Agents/Runners as are available in Azure DevOps/TFS and GitLab? Note: IBM Cloud GitLab CE has this feature disabled.

    p.s. I'm only looking at this as we are having a horrific time with scaling Bamboo.

  16. Log in to comment