I've been building my C# project from the MS Visual Studio IDE, and by invoking msbuild from Jenkins on Windows. Now I want to build the C# project on Atlassian OnDemand.
However, msbuild is not listed as a builder option in OnDemand and I can't find any documentation on how to build a C# project on OnDemand.
Update
Atlassian OnDemand Bamboo features a Windows stock image as of mid July 2012, see Azwandi Mohd Aris' comment:
Just an update that Bamboo OnDemand now ships with a Windows-based AMI - see release notes at https://confluence.atlassian.com/display/AOD/July+2012#July2012-Bambooupgrade
This image meanwhile also supports MSBuild as per James Dumay's answer from early November 2012.
Initial Answer
The configuration of builders is one of the Restricted Functions in Atlassian OnDemand for Bamboo:
Bamboo OnDemand only runs builds using elastic agents. Hence,
capabilities can only be configured by using a custom image.
So in principle you would need to either use one of the default Stock images provided by Atlassian or Create a custom elastic image of our own. While Atlassian provides a Windows stock image as of Bamboo 3.4, the version of Bamboo for OnDemand is most annoyingly still stuck at 3.0 (see Atlassian OnDemand Application Versions), with the long overdue update including DVCS support recently postponed again (see Lingbo Lu's comment: We are hoping that we can deliver it in July/August timeframe)
So for the time being I'm afraid you'll need to apply the Bamboo 3.0 version of Creating a Custom Elastic Image and create an appropriate custom image for the task at hand yourself.
Update
There are a couple of related threads on Atlassian Answers as well:
James Dumay's answer to How do I run .NET builds on JIRA Studio summarizes the state of affairs and recommends Grace Mollison's instructions for Setting up a windows AMI for use with Elastic Bamboo in turn. However, RodH's comment regarding How can I run Bamboo OnDemand with MSBuild? indicates unspecified issues with this approach/solution.
So be prepared for a rough ride eventually.
Related
I am trying to integrate the Security Code Scan with Gitlab CI. I read the documentation but still, I can't understand how exactly must write commands for SCS in yml file (source file: warning SCS[rule id]: [warning description] [project_file]). My Gitlab is hosted on Windows 10 machine without a container. The project is .NET Framework 4.6.2 and I use Visual Studio 2019. I already get an SCS package from NuGet.Also, I have read about Fortify but I am stuck on the same problem.
Per the GitLab docs, you really just add this include to your main .gitlab-ci.yml file.
include:
- template: Security/SAST.gitlab-ci.yml
The template defines a job that uses a custom Docker image and Go wrapper around the Security Code Scan package. It actually dynamically adds the SCS package to discovered projects, runs a build, and captures and parses the output in order to produce the security report.
It does things this way because the Security Code Scan project runs as an analyzer at build time... it's not a normal CLI application, although there are mostly ignored issues asking for this option.
Update: You could just add the Security Code Scan package to your project(s)
$ dotnet add package SecurityCodeScan --version 3.5.3
And run a normal build in your GitLab pipeline, reading the warnings that are produced in the pipeline logs.
build:
stage: build
image: mcr.microsoft.com/dotnet/core/sdk:3.1
script:
- dotnet build
You could enable TreatWarningsAsErrors to break the build, too.
dotnet build /p:TreatWarningsAsErrors=true
<PropertyGroup>
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
<PropertyGroup>
You won't get a nice MR attached report this way, just pipeline logs. The interactive pipeline report doesn't appear unless you have a Gold plan, anyway.
With GitLab 13.9 (February 2021), this will work for multiple projects too:
Multi-project support for .NET SAST scanning
GitLab security scans automatically detect code language and run appropriate analyzers.
With monorepos, microservices, and multi-project repositories, more than one project can exist within a single GitLab repository.
Previously our .NET SAST tool could only detect single projects in repositories.
With this release, our .NET SAST analyzer can now intelligently detect multiple solution files (.sln) in .NET projects and report vulnerabilities across them.
This will make it easier and more streamlined for users with multi-project .NET repos to leverage our SAST scanning.
See Documentation and Issue.
And it is more visible (still with GitLab 13.9, February 2021)
Security Configuration page for all users
With SAST and Secret Detection available to all GitLab customers, we wanted to improve the experience for developers enabling available security scans. We have had a guided configuration experience for Ultimate users and have now made a simplified version of this experience available to all users. This new configuration experience makes it easier for developers to understand which security scans are available to them, find relevant documentation, and provide simple enablement tools. With this initial release, we support a button to create a merge request for SAST. In a future release, we will add additional buttons to easily enable other scan types.
-- Security Configuration page for all users
See Documentation and Epic.
It does evolve with GitLab 13.11 (April 2021)
GitLab + Semgrep: upgrading SAST for the future
GitLab SAST historically has been powered by over a dozen open-source static analysis security analyzers. These analyzers have proactively identified millions of vulnerabilities for developers using GitLab every month.
Each of these analyzers is language-specific and has different technology approaches to scanning. These differences produce overhead for updating, managing, and maintaining additional features we build on top of these tools, and they create confusion for anyone attempting to debug.
The GitLab Static Analysis team is continuously evaluating new security analyzers. We have been impressed by a relatively new tool from the development team at r2c called Semgrep.
It’s a fast, open-source, static analysis tool for finding bugs and enforcing code standards.
Semgrep’s rules look like the code you are searching for; this means you can write your own rules without having to understand abstract syntax trees (ASTs) or wrestle with regexes.
Semgrep’s flexible rule syntax is ideal for streamlining GitLab’s Custom Rulesets feature for extending and modifying detection rules, a popular request from GitLab SAST customers. Semgrep also has a growing open-source registry of 1,000+ community rules.
We are in the process of transitioning many of our lint-based SAST analyzers to Semgrep.
This transition will help increase stability, performance, rule coverage, and allow GitLab customers access to Semgrep’s community rules and additional custom ruleset capabilities that we will be adding in the future. We have enjoyed working with the r2c team and we cannot wait to transition more of our analyzers to Semgrep. You can read more in our transition epic, or try out our first experimental Semgrep analyzers for JavaScript, TypeScript, and Python.
(So not yet for .Net, but soon)
We are excited about what this transition means for the future of GitLab SAST and the larger Semgrep community.
GitLab will be contributing to the Semgrep open-source project including additional rules to ensure coverage matches or exceeds our existing analyzers.
See Documentation and Epic.
The same GitLab 13.11 announces:
OpenShift Support for SAST and Secret Detection
Experimental Semgrep Analyzer for Python, JavaScript, and TypeScript
Support for Generic Kotlin SAST Scanning
See GitLab 13.12 (May 2021)
Semgrep SAST Analyzer for JavaScript, TypeScript, and Python
In GitLab 13.11 we announced an experimental release of Semgrep, a new SAST analyzer for JavaScript, TypeScript, and Python. This transition has been developed in partnership with r2c, the team behind Semgrep who share our mission to help developers write more secure code. After an extensive beta with hundreds of customers trying out our experimental analyzer, we’re ready to start the transition to Semgrep.
With 13.12, we’re updating our managed SAST.gitlab-ci.yml CI template to automatically run this new analyzer alongside our existing JavaScript and TypeScript analyzer, ESlint. In a future release we will fully disable ESLint, but for now it will work in unison with Semgrep. We’ve done work to deduplicate findings, so you should not notice any difference in findings. If you include our SAST.gitlab-ci.yml, you don’t need to do anything to start benefiting from the Semgrep analyzer, however if you override or manage your own SAST CI configuration, you should update your CI configuration.
Both GitLab and r2c are excited about the future of this transition to bring you fast and wide coverage Static Application Security Testing (SAST). We’ll continue to expand the Semgrep analyzer through new security detection rules as well as expanding coverage to other languages. We’ve created a feedback issue where you can share your experience with this transition or ask questions.
See Documentation and Epic.
See GitLab 15.0 (May 2022)
Semgrep-based SAST scanning available for early adoption
You can now switch to Semgrep-based scanning for many languages in GitLab SAST.
Semgrep-based scanning brings significantly faster analysis, reduced usage of CI minutes, and more customizable scanning rules compared to existing language-specific analyzers.
As of GitLab 15.0, it supports C, Go, Java, JavaScript, Python, and TypeScript.
In a future release, we’ll change GitLab SAST to use only Semgrep-based scanning by default for supported languages, and we’ll remove the language-specific analyzers that also scan them. (This change was previously scheduled for GitLab 15.0; work to complete it is tracked in this deprecation issue.)
You can now choose to disable deprecated language-specific analyzers early and use Semgrep-based scanning instead before we change the default behavior. We’ve updated documentation to explain the transition, including guidance on when to make the change in your pipelines.
See Documentation and Issue.
We have MuleSoft applications and they are deployed in Mule Runtime. We need recommendations on patching MuleSoft applications. The patch can be either in MuleSoft Runtime itself or can be in application.
MuleSoft's recommendation on patching a MuleRuntime is available at https://support.mulesoft.com/s/article/How-to-apply-patches-to-Mule-4-x.
Here, the recommendation to patch MuleRunTime is to replace the jars/plug-in. But with this, how can we maintain/know the version of patch that is applied.
What is the recommended way to patch a application which is deployed in MuleRunTime.
Any help/recommendation on this is appreciated. Thanks.
You can look at infrastructure automation tools that auto install your runtime with the correct patches etc like puppet, chef and so many other tools. So that your runtime is always using the correct doenedencies and is repeatable. Which tool depends on your organisation.
Or just as with your code you can version control your runtime or install scripts in git etc.
The Mule runtime will log its own version and the versions of each plugin and applied patch, whenever it starts your app. So check the log from the last time you started and you'll see the current version and patch level.
So trust the recommendations in the help document you cited in the OP. As Ryan says, you can use any dev-ops tools favored in your organization. (If you don't have a favorite, Maven is integrated very nicely with Anypoint Studio and can help with this.)
We are using Bamboo to compile our C# projects and recently enhanced our build AMIs to have the MsBuild 15 Build Tools so devs are able to use C#7. With the advent of C# 7.1, Microsoft state they are "increasing the cadence" of language releases and I've been trying to find out what the upgrade path for MS Build Tools and how to keep it updated with the latest version.
At the moment it appears that the Bamboo admins would have to always be one step ahead of the devs (who update their IDE to use the new language release) to enable clean compilations.
I can't find a decent way of automating this (other than though something like Chocolatey) - I'd be interested to see how other people get round this or ensure their Build Tools will always up to date.
I'm setting up a RoboCopy job using the MSBuild Community tasks. It seems however that the task has not been released, despite it being in the list of tasks on the project front page. The latest release v1.2.0.306 does not include it, but if it is present in the SVN trunk. Am I looking in the wrong place?
I know there is an MSBuild Extension project that also have a RoboCopy task, but I'm already using some of the other Community tasks, and I'd rather not make my build depend on two almost identical extension packs.
The Tigris site seems abandoned in terms of documentation, so I'm attempting to see if anyone in here knows.
In case you didn't notice it: the latest official release on the download page (v1.2.0.306, exactly what you downloaded) is nearly five years old (February 2007).
Since then, obviously a lot of stuff happened in the trunk.
You can download and compile the trunk yourself, or you can use the nightly build which you can download at the bottom of the main project page:
Download The Latest Nightly Build
The latest test binaries and source from the automated build server.
Version: 1.3.0.516 Date: 9/8/2011
MSBuild.Community.Tasks.Nightly.zip
MSBuild.Community.Tasks.Nightly.msi
I'm using this version.
So...yes, you are looking in the wrong place :-)
MSBuild (latest) is also available through NuGet: http://nuget.org/packages/MSBuildTasks
You can install it via GUI or in Package Manager Console run
Install-Package MSBuildTasks
We have our source code stored in Kiln/Mercurial repositories; we use MSBuild to build our product and we have Unit Tests that utilize MSTest (Visual Studio Unit Tests).
What solutions exist to implement a continuous integration machine (i.e. Build machine).
The requirements for this are:
A build should be kicked of when necessary (i.e. code has changed in the Repositories we care about)
Before the actual build, the latest version of the source code must be acquired from the repository we are building from
The build must build the entire product
The build must build all Unit Tests
The build must execute all unit tests
A summary of success/failure must be sent out after the build has finished; this must include information about the build itself but also about which Unit Tests failed and which ones succeeded.
The summary must contain which changesets were in this build that were not yet in the previous successful (!) build
The system must be configurable so that it can build from multiple branches(/Repositories).
Ideally, this system would run on a single box (our product isn't that big) without any server components.
What solutions are currently available? What are their pros/cons? From the list above, what can be done and what cannot be done?
Thanks
TeamCity, from JetBrains, the makers of ReSharp, will do all of that. You will have to configure it for what specifically it means to "build your product", but you can configure up everything you specified with it.
The software can alert you to failed builds, even down to alerting only the person responsible for checking in code that broke the build. It even comes with handy web pages you can view to see only your own changes, which builds they've been through successfully, which ones are pending, and which ones are currently being executed.
Since it is a distributed product, you can make it grow with your organization and product. If at some point you discover that you're waiting for the build to complete too much, because a lot of builds are being queued up, you can add more build agents. The build agents are basically separate client programs you install on additional machines, that execute the actual build configurations.
It comes in two flavors, the professional version and the enterprise version. The professional version is free, can contain up to 20 build configurations, 20 users, and 3 build agents. The enterprise version has unlimited users and build configurations, and you can also use LDAP based security (think domain verified users.) There's also some other bonuses from the enterprise version. You can also buy licenses for more build agents if you need more than the initial 3.
Now, if "no server components" means you don't want it to act like a web server, you're going to be hard pressed to find something that will react to your commits.
However, if you mean that you don't want to have to install a server OS, then TeamCity can work on workstation versions of Windows as well. That isn't to say that you shouldn't consider setting up a proper server for it, but it will run on a workstation if that is what you require.
Our product BuildMaster does all of the things you listed by design and there is a free, somewhat limited edition (e.g. you can only have a limited number of issue tracking providers integrate with it, the database change script packaging tool isn't included in the free version, etc.) for 5 users or fewer.
What you've described is the basics of a CI Tool, so every CI Tool should be OK.
I use Cruise Control.NET but it is bugged with Mercurial and is not very straightforward at first glance. I am nevertheless happy with it. Other tools that come in my mind are Hudson, Team Build (from TFS) and TeamCity.
I have not tried other tools but you can see pros/cons here :
TeamCity vs CC.net
Hudson vs CC.net, Link 1 and Link 2
CC.net vs TFS
EDIT : I forgot to mention that Hudson and Cruise Control.net are Open Source project, you can easily write plugins and patches to your install.
EDIT² : Mercurial bugs seem to be fixed in the upcoming 1.6 version of ccnet (changes commited to the trunk this week).
There's always BuildBot which I like (and have contributed some code to ). It's fairly easy to set-up and run on any OS, and to do simple tasks like that you say, and remarkably flexible if you need it.
What you might find missing is batteries-included log-scrapers and/or report generators that other more commercial CI-servers comes with, especially for Enterprise-y frameworks.
It scales pretty well too, Mozilla and Chromium use it, amongst others.