How can is specify: language: none in .travis.yml?
I don't specify a language, and get Ruby by default.
i have no Ruby. I'm using C, C++, Ocaml, Python, and Felix.
The build script is just "make".
You can set language: minimal or language: generic which are not language specific.
From the documentation:
minimal has some essential CI tools and Python:
version control tools
essential build tools such as gcc and make
network tools such as curl and essential
Docker
python
generic extends minimal and additionally includes:
databases and services
go
jvm
node_js
php
ruby
Start with setting language: c
https://docs.travis-ci.com/user/customizing-the-build/
https://docs.travis-ci.com/user/languages/c
You might run into problems as per https://github.com/travis-ci/travis-ci/issues/4090
Related
The Bazel install instructions say that Python is required. However, I used the Linux installer without Python and it seems to work.
Does Bazel actually require Python for non-Python builds, such as C++ and Go?
I believe it doesn't, and your success to build without Python proves that.
I'm building a python package which is mostly c++ code (think numpy)
My travis file is currently
language: cpp
compiler:
- gcc
- clang
os:
- linux
- osx
dist: trusty
script: "make pcst_fast_test && ./pcst_fast_test"
notifications:
...
But I've also written some python tests in a file called test_pcst_fast.py. Is there some way to call those from travis as well?
It seems ambiguous as to whether travis supports multiple languages in one file, but it seems like most people pull this off despite only listing one language under the language tag.
Travis doesn't support multiple languages per job yet.
Look at categories after_success and after_script in the Travis build lifecycle docs
Also, you can add more build scripts, they will run independently, just list them like this:
script:
- "make pcst_fast_test && ./pcst_fast_test"
- "./test_pcst_fast.py"
If there is no python installed (not sure about c builds), you can install it, check out this .travis.yml, it installs custom python interpreter as a dependency.
You can't add multiple languages, which explains the behavior you are seeing, and the node_js setting will only be recognized in a node language project.
What you can do is utilize the incorporated nvm in TravisCI.
For example, you can include
nvm install 0.10
nvm use 0.10
in your before_install section to download the latest v0.10.x release of node.
However,
On a Travis Java build environment, you can use nvm to manage Node.js runtimes:
.travis.yml
language: java
jdk:
- oraclejdk8
env:
- NODE_VERSION="0.12"
before_install:
- nvm install $NODE_VERSION
If your Node version is very recent, you might have to update nvm too.
To update nvm, write this in your .travis.yml:
before_install:
- wget https://raw.githubusercontent.com/creationix/nvm/v0.31.0/nvm.sh -O ~/.nvm/nvm.sh
- source ~/.nvm/nvm.sh
- nvm install 5 # for Node v5
- node --version
The above example shows how to first update to nvm v0.31, to then obtain Node v5.
See title. Currently, I do either run the scripts on Windows with a CMD or by using a shell on Linux. This seems a bit unflexible to me since it limits the jobs to be run either on Windows or on Linux.
How would I define a job which simply does run my test scripts written in Perl/Python/Ruby/WhateverOtherScriptingLanguage regardless on which OS the Jenkins instance is running.
The correct script interpreter can be assumed as installed, of course.
The cross-platform shell plugin solves exactly this problem -- however, the last release was done in 2014, and there's a couple of open issues that might prevent you from using it in a production environment.
As an alternative, there is plugins for wrapping the actual call to the interpreter into plugin code. With a plugin, you become independent from OS-specific shells. However, the plugin will be language-specific, e.g.,
For Python, the ShiningPanda plugin is popular
For Ruby, the Ruby plugin will do that (albeit only for embedded scripts)
For Perl, there is no such thing
In any case, you'd depend on availability and maintenance of an additional plugin. Plus, adding fat plugins to Jenkins just to wrap a system call is somewhat awkward.
I reckon that the most versatile and compact solution is to introduce a Groovy build step, and to start the interpreter with a one-liner from there, e.g.:
"perl myscript.pl".execute();
This will work on any platform, as long as you ensure that Groovy is available, e.g. by using the Groovy plugin.
If you prefer Python, you can probably do the same with short wrapper that you start via the ShiningPanda plugin.
Shell scripts in Jenkins provide crossplatform she-bang.
#!perl
print "hi"
will work both on linux and windows, perl should be in PATH.
UPD. Actually we had shell installed on windows hosts so it might be not working without it.
I am just starting to get to grips with Nix, so apologies if I missed the answer to my question in the docs.
I want to use Nix to setup a secure production machine with the minimal set of libraries and executables. I don't want any compilers or other build tools present because these can be security risks.
When I install some packages, it seems that they depend on only the minimum set of runtime dependencies. For example if I install apache-tomcat-8.0.23 then I get a Java runtime (JRE) and the pre-built JAR files comprising Tomcat.
On the other hand, some packages seem to include a full build toolchain as dependencies. Taking another Java-based example, when I install spark-1.4.0 Nix pulls down the Java development kit (JDK) which includes a compiler, and it also pulls the Maven build tool etc.
So, my questions are as follows:
Do Nix packages make any distinction between build and runtime dependencies?
Why do some packages appear to depend on build tools whereas others only need runtime? Is this all down to how the package author wrapped up the application?
If a package contains build dependencies that I don't want, is there anything that I, as the operator, can do about it except design my own alternative packaging for the same application?
Many thanks.
The runtime dependencies are a subset of the build-time dependencies that Nix determines automatically by scanning the generated output for the hash part of each build-time dependencies' store path. For example, if you build a package using the compiler /nix/store/abcdef...-foo-1.20, then Nix will scan all files in the generated output for the hash bit abcdef.... If that hash is found, then the output is assumed to reference the compiler in some way, so it's kepts as a runtime dependency. If that hash does not occur, however, then the generated output has no reference to the compiler and therefore cannot access it at runtime, so foo-1.20 is treated as a build-time-only dependency.
Some packages record large parts of their build environment for informational/debugging purposes. Perl, for example, stores every little detail about the tools used to compile it, so all those store paths end up being treated as runtime dependencies despite the fact that Perl doesn't actually need them at runtime, but Nix can't know: it just knows that the Perl store path references those tools. Now, Nixpkgs maintainers usually make an effort to clean that up, i.e. by pruning the logfile that contains all those store paths from the installation, etc., but for sure there are plenty of packages in the database still that haven't been optimized to that end yet.
Let's assume that you'd like to compile a version of openssh that does not depend on PAM. Then you can remove the build input from the expression by means of an override, i.e. you replace the pam argument that's normally passed to the openssh build function with null. To do that, store the following file in ~/.nixpkgs/config.nix
{
packageOverrides = super: let self = super.pkgs; in {
openssh-without-pam = super.openssh.override {
pam = null;
};
};
}
and now install that package by running:
$ nix-env -f "<nixpkgs>" -iA openssh-without-pam
Has anyone worked out an ultra efficient workflow and toolset for Erlang? Debugging, prototyping, browsing, version control, etc.
I'm extremely impressed with Smalltalk's integrated image system, but was wondering if something could be even approaching it with Erlang.
Erlang has a very robust development chain, especially if you are an EMACS maven. There is an Erlang specific build system, there is robust support for packaging your application and its dependencies for deployment and don't forget OTP.
As for tools, there is Dialyzer, real time tracing on running systems, hot code loading ( you can enable and disable or add logging to a running system without restarting it, for example ), remote code execution, there is so much to learn it is dizzying when you start out.
Editor: you can use whatever you want. I used emacs for my first year of erlang, but I'm currently using gedit.
Version Control: I like git. It seems that most of the erlang community agrees (most projects are hosted on github).
Workflow: I'd recommend getting familiar with rebar.
Here is an example of a rebar-flavored Makefile:
REBAR := ./rebar
.PHONY: all deps doc test clean release
all: deps
$(REBAR) compile
deps:
$(REBAR) get-deps
doc:
$(REBAR) doc skip_deps=true
test:
$(REBAR) eunit skip_deps=true
clean:
$(REBAR) clean
release: all test
dialyzer --src src/*.erl deps/*/src/*.erl
Here are some basic pointers:
Put your unit tests in the same modules as the code they are testing. See the rebar wiki for details.
Add {cover_enabled, true} to your rebar.config file. Every time you run make test you get a coverage report in HTML!
Add your project's dependencies to your rebar.config and you can fetch and build them when you run make deps.
Make sure to comment your code with edoc. If you do, rebar can build all of your docs when your run make doc.
I wonder about the difference between Sinan/Faxien and Rebar, too. From my notes, I remember that Sinan/Faxien was more about creating a project template, and dependency management, while Rebar was more useful for creating a module template... My notes are here, are several years old, and are aimed at bootstrapping erlang newbies (like me).
-Todd