Until now Buddy only supported Linux workers. Bulding .NET applications was only possible through Mono, an open-source implementation of Microsoft's .NET framework. However, this solution, although the only one possible on this type of architecture (excluding .NET Core), was far from perfect, as the build environment was still emulated and not native.

And so it happened: last week we added support for Windows workers (Windows Data Center)! We are super excited about it as it opens Buddy for a completely new ecosystem of developers. It also adds new challenges for our team – as always we are looking forward to you helping us fine-tune the feature so that it meets the high standards of Microsoft developers.

New Features

• New action: Doctl

Improvements

• [Hugo] Adjusted the default commands to match the newest Hugo release
• [Google Cloud Functions] Added Node.js 12 runtime support

Bugfixes

• [Windows build] Fixed a bug with execution retry after a failed Windows build causing the action to crash
• [Windows build] Fixed a bug with sync paths getting removed upon updating the action
• [Sandboxes 2.0] Added validation to prevent adding sandbox actions if there's no sandbox in the project
• [Standalone] Fixed a bug with only the first 100 projects getting listed when adding a project from GitHub Enterprise

New Features

• New action: Windows build
• New option: Execute all pipelines in the current folder

Improvements

• Current folder information is now displayed when adding/editing the project's folder
• [On-premises] You can now manually enter the RAM value for builds in megabytes in the settings

Sandboxes

• Trying to delete a project with a Sandbox in pending status will now display proper warning

Bugfixes

• Changelog variables are no longer passed in the SSH action since their potential size caused actions to fail
• [REST API] Fixed a bug with ref_type and ref_name values not changing when updating pipeline settings
• [On-premises] Fixed a bug with the display of available seats in the license settings

New Features

• Priority levels in pipelines – set pipelines to high priority to run them faster when queued

Sandboxes

• Start & Stop Sandbox actions now support trigger conditions

Bugfixes

• If deleting a project was taking long, retrying deletion was causing an error. Fixed
• Private SSH keys defined in the Variables tab will no longer be forwarded to the SSH action
• Added name length validation when creating a new permission set

There is no such thing as one correct approach to Continuous Integration and Delivery. It's possible to distinguish some patterns, yes, but each use case is different and depends on many variables: project guidelines, type of Git workflow, experience and skill of developers, etc. etc.

A crucial element to most delivery pipelines is the testing phase, an essential step to delivering high quality, reliable software. More advanced testing, for example, such as integration, browser, or E2E tests, often require deploying the application to a staging environment first. This may cause issues if you are running tests concurrently for different branches or pull requests. As one of our clients put it: