We have several build machines, each running a single TeamCity build agent. Each machine is very strong, and we'd like to run several build agents on the same machine.
Is this possible, without using virtualization? Are there quality alternatives to TeamCity that support this?
Yes, it's possible:
Several agents can be installed on a single machine. They function as separate agents and TeamCity works with them as different agents, not utilizing the fact that they share the same machine.
After installing one agent you can install additional one, providing the following conditions are met:
the agents are installed in the separate directories
they have distinctive work and temp directories
buildAgent.properties is configured to have different values for name and ownPort properties
Make sure, there are no build configurations that have absolute checkout directory specified (alternatively, make sure such build configurations have "clean checkout" option enabled and they cannot be run in parallel).
Under Windows, to install additional agents as services, modify [agent dir]\launcher\conf\wrapper.conf
to change the properties to have distinct name within the computer:
wrapper.console.title
wrapper.ntservice.name
wrapper.ntservice.displayname
wrapper.ntservice.description
You could also take a look at this blog post for Step-by-step guide
http://handcraftsman.wordpress.com/2010/07/20/multiple-teamcity-build-agents-on-one-server/
The top answer is the correct method, but if you want to complete this more easily you can use the TeamCityAgent Chocolatey package and supply the agent name, the agent folder and the port as --params and it will handle setting up the config files as well as pulling in the required version of Java via the server-jre package.
The one caveat to this is you need to use --force on any installs after the first agent as Chocolatey doesn't currently understand installing the same application with a different configuration as a "new" installation.
You will also need to use --version 2.0.1-beta-05 since this is still in a testing phase, but should make it out of beta soon.
Full install example for a second agent:
choco install teamcityagent --force -y --params 'serverUrl=http://teamcity.local:8111 agentName=AgentUno agentDir=C:\buildAgentUno ownPort=9091' --version 2.0.1-beta-05
Related
I managed to create playbooks to backup an existing running Wordpress server by installing a VM backup server on Debian, so using APT package manager in Ansible.
Now I would like to be able to use the same playbooks but for installing at the same time the backup on an Alpine linux server.
Is there a more generic way than using APT or APK modules ?
If not what would you recommend me ?
Regards,
FB
Yes, and it's called package module, check https://docs.ansible.com/ansible/2.9/modules/package_module.html
Package names, however, might be different from distro to distro, and you still will have to provide distro-specific instructions. Quoting doc:
Package names also vary with package manager; this module will not "translate" them per distro. For example libyaml-dev, libyaml-devel.
The usual way to avoid it is to create distro-specific subtasks for different os families, or distro-specific variables, which are included with some condition.
I am looking to play with apache-superset on a cloud-based ide. I have it on my local. I tried unsuccessfully to set it up on gitpod. I wanted suggestions on where can I set it up, opensource preferably not necessarily. I believe cloud9 is 1 such place, but I am looking for other options before I settle. If you've ever set it up on any such platform, even if it is on gitpod and can help me, kindly do so.
[Disclaimer: Gitpod staff]
You can indeed use Gitpod to work on apache-superset, and for that you'll just need a working configuration.
From what I can see in apache-superset's requirements, you'll need to get:
PostgreSQL (e.g. by using Gitpod's official gitpod/workspace-full-postgres Docker base image)
Redis (e.g. by installing it in a Dockerfile via sudo apt-get install)
Various Python dependencies (e.g. by running pip install . after cloning)
Various Node.js dependencies for the front-end (e.g. by running npm install)
Here is a basic configuration I wrote to achieve this:
https://github.com/jankeromnes/incubator-superset/commit/0d345a76ec8126fd1f8b9bc7b6ce4961bf3b593d
What it does is:
Create a Docker image with PostgreSQL and Redis
Once the repository is cloned, open 4 separate Terminals ("tasks"):
Redis server
Superset backend
Superset worker
Superset front-end
All dependencies will be installed automatically, and once the front-end is ready, it will automatically open in a web preview IDE side panel.
You can try it out by opening my personal fork of the apache-superset repository in Gitpod, e.g. by following this link:
https://gitpod.io/#https://github.com/jankeromnes/incubator-superset
I am searching for instruction how I can manage to install hortonworks (hdp) cluster, using ambari as a silent installation.
I saw in the manual of ambari-server that there are option to do it but it used the default values.
amabri-server setup -s
(Setup runs silently. Accepts all default prompt values.)
How I can do it? And how can I change the default values?
The reason I need it is for our nightly build.
It wasn't a very elegant solution but I used expect to automate the installation by spawning ambari-server setup and automatically putting in preconfigured values into the prompts.
A little bit of necro: you can use flags to kinda automate installation process. View a list of flags via
ambari-server setup –help
One used to be able to download Vagrant boxes to debug Travis builds (for GitHub projects for instance). Apparently, this is no longer possible, so how do people currently debug complex Travis build chains locally?
One way to inspect the build (not to debug, sorry) is to send the build logs to another server on failure.
Here is an example:
after_failure
- sudo tar -czf /tmp/build-${TRAVIS_BUILD_NUMBER}-logs.tgz your-application-logs/
- scp /tmp/build-${TRAVIS_BUILD_NUMBER}-logs.tgz travis#your-server.com:~/logs
You could send them via email, store them on a storage server or whatever.
These logs would be useful to you if you run your tests in a debug mode and include our own logs as well in the tarball.
Unfortunately, there is no good solution for testing travis-ci builds locally at the moment. The closest thing I can recommend is a Ubuntu 12.04 vagrant vm and to provision it with the Travis chef cookbooks from here. This will solve most use cases as most of the time the test failures are not from the travis software (Though when it is you're in tough luck, as most Travis software depends on the other pieces of Travis software, making it fairly difficult to set up) but from the underling OS (Ubuntu) and software such as ruby and ruby gems.
I had a crack at making a docker file for JVM builds here which works well for me. It is based of the travis published containers and utilises the Travis CLI and Travis Build projects to be able to run your .travis.yml file within a docker container.
A built JVM image is on docker hub.
I want to use Jenkins for creating RPM packages to deploy code and scripts onto a Linux redhat machine(s)
So the applications are a mix of technologies (no compiling needed) i just need to package up the applications deploy them to the correct location restart apache
Would anybody have some instructions on how to do these steps for a total Newbie:
Some questions:
Do i need to install jenkins on a local linux machine if im going to be creating RPM's that will be deployed on to linux redhat machine (i was hoping to install jenkins on windows)
Does anybody have a example of creating a package out of a local folder (no source control for the moment)
I want to just specify the directory of where to take the code from and specify where to deploy the code to on a machine the rpm is installed on
On the destination machine i want to run something like
yum -install mypackage-version12.rpm
and it will install the code/scripts to the specified directory and restart apache
i need an example of this also.
Thanks
You can install Jenkins on a different machine, but you generally must have a Jenkins "node", "slave", "agent" installed on a machine that can generate RPM packages.
Running each step of the RPM package setup is putting all the steps to build within Jenkins. It works much better if you extend your build system to build the RPM, and have Jenkins do what it does best, manage the build (schedule, etc), not micro-manage the build (do the steps).
Depending on what you currently have as your build system, this might include ant directives to setup the rpm build tree, copy in the .spec file, and a executable call to rpmbuild.
Jenkins can easily call a post-build task to do this, or you might want to configure a mini "fake" project that does the update, depending on tastes.
As an aside, for a yum command to work without using the --localinstall option, you will need to have a web server set up, the new RPM copied to the right folder on the web server, and the indexing files rebuilt (repobuild is the script to do so, if I recall correctly).
On the client machine (where the package will be installed), you will need to have a yum configuration that directs the client machine to include the web server as one of the known yum repositories.
Why not use an Docker images to build the RPM inside it though a dedicated stage ?
Your code needs to provide /rpm/SPEC files and inside the Docker (Jenkins) you can have a Jenkinsfile like :
mkdir -p ./rpm/BUILD && cd ./rpm/ && for f in ./SPECS/*; do rpmbuild --define \"_topdir \$(pwd)/\" --define \"_builddir \$(pwd)/BUILD\" -bb \$f;
And you are done.