I'm trying to build Kubernetes from source using the release.sh script. However I can see that it build client and server binaries for many platforms which are not useful to me. How can I say release.sh to build binaries only for my platform? I can see that KUBE_SERVER_PLATFORMS and KUBE_CLIENT_PLATFORMS checks are done in hack/lib/golang.sh script. But how can I pass those values?
Unless you're looking to cross-compile, or specifically build a release, I'd recommend using hack/build-go.sh, it will pick the host platform for you and just build on that.
I'm looking for ideas on how to easily build binaries for common platforms for a Golang project, for release on Github.
I already know how to manually do releases, using Github's instructions at Creating Releases. And I'm currently doing releases using aktau/github-release, but this requires manually logging into different machines (OSX, Linux, Windows) and doing the release.
Benedikt Lang has blogged about using Travis-CI (which I'm yet to experiment with). But I presume the public Travis will only build binaries for Linux.
Any suggestions?
You are most likely right about the Travis CI only building in Linux as go cross-compilation requires you to build from source and build other go executables. Like RoninDev suggested, I would suggest that you setup your own cross-compilation build environment by following the blog post:
http://dave.cheney.net/2012/09/08/an-introduction-to-cross-compilation-with-go
It is quite easy, and only takes about 10 minutes. After you have that, a build tool such as Jenkins will give you the controls to kick off a build for the desired platforms (Mac, Windows, Linux, etc) and then push out git releases for each one.
Thanks for all the suggestions and answers that were given. Cross-compilation was what I was looking for, and Dave Cheney's blog post was a good start.
However I found a better solution - laher/goxc - "a build tool for Go, with a focus on cross-compiling, packaging and deployment". It was inspired by Dave Cheney's work, and also includes deploy tools for Github - just what I was looking for. (For example, I used it to release soniah/awsenv)
I created goreleaser to do just that.
You can try it out if you want :)
I am currently working on a project in Microsoft Robotics Development Studio, and I am having a little trouble deploying the solution for general use.
My problem is this. I am making a simulation, so I need to deploy the simulation engine along with my project. This is dependent on the Ageia PhysX engine, DirectX, and the Microsoft XNA framework. I understand this, and I understand that the deployment tool for MRDS (dssdeploy) isn't set up to deploy simulations by default. So, if anyone has worked with MRDS before, and has deployed a simulation, I could use some help with this.
Unfortunately, dssdeploy does not work with simulation projects. It won't package up all the required simulation libraries. I believe the reason for this is due to license and/or install issues for PhysX, DirectX, and XNA. I think you can still zip up your own service with dssdeploy, but you will have to have your target user install RDS first, then un-deploy your service.
FYI, because of this and many other headaches using dssdeploy, I have stopped using it to distribute my code. I simply zip up my service, then tell the end user to run dssprojectmigration on the code after they un-zip it.
I have prior experience in build a automatic build process for .NET & Delphi projects but now want to automate the building of a iPhone project... not only simply builds but also to the final deployment..
I want a generic step list, with the command line actions that need to be performed, so anyone could adapt it to their particular build software.
Also, how build with support for 3.0 and 2.0 targets (or more general: How build to different deployments targets???)
So:
Preparation:
Set support for application versioning with agvtool.
Build steps:
Checkout the sourcecode
Clean the project
Increase the version: agvtool bump -all
If is for deployment also run: agvtool new-marketing-version <new version here>
Build the project (how?)
Build the test suite
Run the test suite
What more?
Building the target is the easiest of the pieces. Use xcodebuild. It can easily target separate SDKs. It's also the tool that will build your test suites for you (by using a separate target generally). I recommend relying on xcodebuild as much as possible. I've only seen heartache come from trying to wrap xcodebuild calls with make, jam or ant. You have to build with xcodebuild eventually, so it's worth studying the Xcode Build System Guide and learning to make the most use of it. It's quite powerful. I have a few introductions to configuring it here.
Running the test suite is more difficult to automate for iPhone (especially if you need to test on device). There have been other discussions of this. For many apps, you may not be able to fully automate this step.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What tools do you use for Automated Builds / Automated Deployments? Why?
What tools do you recommend?
Hudson for automated builds. I chose it because it was the easiest to setup and demo. A system that's too complex and isn't slick-looking won't impress management enough to get them on-board for automated builds. Especially in a project that has a lot of inertia.
NAnt for builds (but MSBuild, Rake, almost anything would be fine) and CruiseControl.NET for deployments. I'm currently working with the new Cruise from ThoughtWorks studios as it provides a better way to stage the various pipelines and let's me deploy any version I want to a target environment.
We use TeamCity, from JetBrains. They also make Resharper And IntelliJ.
We use it for building our .Net applications, and it has been quite easy to set up, connect to TFS, and run additional tools from. It is very polished, and actually kinda reminds me of this site. Found it much nicer than CruiseControl, and for our team size it is free. If you need lots of different builds, more per-user builds, and so on then it costs a bit (but still quite reasonable).
Funnily enough I just spent two weeks overhauling (read implementing from scratch) our nightly build process. Great fun (no, really). I toyed with the idea of installing Team Foundation Server, but we use Perforce for source control and I didn't think it was worth the hassle.
Our process is now a set of Powershell scripts that run on a dedicated build/test server that do the following on a scheduled task:
Wipe out the entire source tree (check that you didn't have anything checked out first!)
Bring down the entire source tree from Perforce (from the last labelled build)
Generate a change report (by syncing to HEAD and watching what comes down)
Build the App
Index the PDB files to the Perforce sources
Store the binaries and symbols in a dedicated symbol server
Run the test projects
Build the installer
Label
Send out emails to the group with status reports on all of the above
Works well.
make and bash on linux
make and cmd on windows
Visual Build Pro
We use a combination of build tools and continuous integration server:
Build tools:
Maven
SBT
Gradle
Rake
Continuous Integration Servers:
Jenkins
Hudson
Travis CI
Automated Build Studio.
Instead of letting you mes with scripts or xml files, it comes with predefined graphical macro operations that allows you to create tasks easily.
For our Windows-compilable stuff, we use FinalBuilder.
CruiseControl for automated builds. Works great.
For automated builds, I think the best tool going right now is JetBrain's Team City. The free version has all the features you'll need for most 5-10 person teams. Set up is easy, configuring new projects is painless (relatively), and most importantly, it's reliable.
For automated migrations, nothing beats PowerShell.
UppercuT uses NAnt to build and it is the insanely easy to use Build Framework.
Automated Builds as easy as (1) solution name, (2) source control path, (3) company name for most projects!
http://code.google.com/p/uppercut/
Some good explanations here: UppercuT
More information
UppercuT is a conventional automated build, which means you set up a config file and then you get a bunch of features for free. Arguably the most powerful feature is the ability to specify environment settings in ONE place and have them applied everywhere, including documentation when it builds the source.
Documentation available: https://github.com/chucknorris/uppercut/wiki
Features :
Simple setup
Simple upgrades
Custom extension points (pre, post, and replace) for each step of the build process http://uppercut.pbworks.com/CustomizeUsingExtensionPoints
Has documentation for integration w/Team City, CruiseControl.NET, and Jenkins (formerly Hudson) https://github.com/chucknorris/uppercut/tree/master/docs
Works on Linux w/Mono
Versioning DLLs based on build number and source control revisions (SVN, TFS, Git, HG)
Compile activities - F5 or Ctrl + Shift + B
Strong naming made as easy as true/false
Code Testing and Analysis
Testing
NUnit
MbUnit v2
Gallio
xUnit
NCover
NDepend
Nitriq
Mono Migration Analyzer
Obfuscation
ILMerge
Environment Templating and Building (ConfigBuilder, DocBuilder, SQLBuilder, DeploymentBuilder) https://github.com/chucknorris/uppercut/blob/master/docs/ConfigBuilder.doc?raw=true
Packaging output to prepare for deployment
Zips up output
At work we use good ol' Ant to build our Java servlets.
We used to use Visual Build from Kinook software, but recently with our new application we switched to MSBuild since it had better integration with TFS and the ability to create custom tasks.
The GNU Autotools definitely. The autoconf and automake are de-facto standard for unix systems.
I've had success using buildbot, triggered by a post-commit script on a subversion repository. This has been used for both automated builds and automated testing.
ANT for both build and deployment/installs.
Makes a great cross-platform installer.
We use Hericus Zed Builds And Bugs Management for our automated builds.
We have 4 branches of code, each with java, c++, C#, cross platform compiles and installers for 5 OS's.
Make for the builds.
Debian packages for deployments (since our production servers runs it).
TeamCity running NAnt scripts for building/packaging and PowerShell for deployment.
I've found that using NAnt, powered by TeamCity, instead of the native TeamCity runners allows us to have a much richer build process (eg. css minimiser, etc). It also means the full build/package process can be run on any developers PC instead of just the TeamCity servers making it much easier to customise and debug problems in the build process.