I've a Travis CI build matrix intended to test recent g++ and clang. In addition to those two intended entries, I see an entry, AFAIK, not specified in the include matrix. How can I either suppress or remove this third build configuration?
The .travis.yml:
language: generic
os: linux
script: ./bootstrap && ./configure && make all && make check && make distcheck
matrix:
include:
- env: COMPILER_NAME=gcc CXX=g++-5 CC=gcc-5
addons:
apt:
sources:
- ubuntu-toolchain-r-test
packages:
- autotools-dev
- g++-5
- env: COMPILER_NAME=clang CXX=clang++-3.8 CC=clang-3.8
addons:
apt:
sources:
- ubuntu-toolchain-r-test
- llvm-toolchain-precise-3.8
packages:
- autotools-dev
- clang-3.8
Snippet of Travis' output taken from the full details:
From the docs, "the os key also multiplies the matrix":
If your code is used on multiple operating systems it probably should
be tested on multiple operating systems. Travis CI can test on Linux
and OS X.
To enable testing on multiple operating systems add the os key to your
.travis.yml:
os:
linux
osx
The value of the $TRAVIS_OS_NAME variable is set to linux or osx
according to the operating system a particular build is running on, so
you can use it to conditionalize your build scripts.
If you are already using a build matrix to test multiple versions, the
os key also multiplies the matrix.
Source: https://docs.travis-ci.com/user/multi-os/
Builds with multiple os keys:
For example, for each separate "os" key, it creates another build. See here: https://github.com/jaredsburrows/cplusplus-cmake-template/blob/master/.travis.yml#L3 or https://github.com/jaredsburrows/open-virus/blob/master/.travis.yml#L3.
Since the default "os" is linux, it is implied in your own question that you have 3 separate builds, that are all use "os: linux".
Matrix builds with different os keys:
For example, each key is now specified in the matrix on separate lines. See here: https://github.com/jaredsburrows/cs-interview-questions/blob/master/.travis.yml#L3 and https://github.com/jaredsburrows/android-gif-example/blob/master/.travis.yml#L8.
In your question, you are not only specifying a "matrix" build but also a plain build with a different os. When specifying "matrix", you are overriding the default "os" build. But you explicitly wrote both "os" and "matrix", implying that you wanted 3 separate builds.
Moving the language and os portions into the matrix include works. I've still no insight as to why, however.
https://github.com/RhysU/descendu/commit/ab275ea79b4ff315f99604d6d7f26dd2488aa266
Related
I cannot opam init:
$ opam init --verbose
[NOTE] Will configure from built-in defaults.
Checking for available remotes: rsync and local, git, mercurial.
- you won't be able to use darcs repositories unless you install the darcs command on your system.
<><> Fetching repository information ><><><><><><><><><><><><><><><><><><><><><>
[ERROR] Could not update repository "default": OpamDownload.Download_fail(_, "Curl failed: \"/usr/bin/curl --write-out %{http_code}\\\\n --retry 3 --retry-delay 2
--user-agent opam/2.0.7 -L -o /tmp/opam-1697-6d07ae/index.tar.gz.part https://opam.ocaml.org/index.tar.gz\" exited with code 28")
[ERROR] Initial download of repository failed
However, I've manually downloaded index.tar.gz. How to manually specify index.tar.gz to opam init?
System info:
$ uname -a
CYGWIN_NT-10.0-19043 xxx 3.4.5-1.x86_64 2023-01-19 19:09 UTC x86_64 Cygwin
P.S. I'm trying to build one project using OCaml, but it turned out that it is very tricky: either OCaml complains about compatibility (is not a compiled interface for this version of OCaml followed by It seems to be for an older version of OCaml; does it mean that OCaml is not backward compatible?), either opam init fails, either <whatever>.
Your error message indicates that you either have network problems or very poor connection. Also, you opam version is very old, so it might not handle bad networks very well, I would suggest your installing a newer version of opam (at least 2.1.x), or, if it is possible, switching to docker or a virtual machine.
Answering your original question: I don't think there is a way (at least officially supported to specify your own downloaded index). Also, if you have trouble with downloading the index it most likely means that you will have more trouble in the future with your network when opam will start downloading actual packages.
Im sure this this just a lack of knowledge on my end but im having a hard time understand how to install aws-nuke following there documentation. I have downloaded the latest release but install instructions are not so clear for me https://github.com/rebuy-de/aws-nuke#:~:text=Use%20Released%20Binaries,Run%20%24%20aws%2Dnuke%2Dv2.16.0%2Dlinux%2Damd64
Any suggestions would be appreciated.
On a Mac you can run aws-nuke using the following steps:
Open a terminal (Command + Space and write terminal)
Grab the latest version of the aws-nuke. Currently the latest version is 2.17.0 but obviously this will change in the future. In order to download aws-nuke, we can run the following command:
For M1 Mac:
wget https://github.com/rebuy-de/aws-nuke/releases/download/v2.17.0/aws-nuke-v2.17.0-darwin-arm64.tar.gz
For intel Mac:
wget https://github.com/rebuy-de/aws-nuke/releases/download/v2.17.0/aws-nuke-v2.17.0-darwin-amd64.tar.gz
Extract the package using the following command (note: use amd64 instead of arm64 if you are on an intel Mac):
tar -xvf aws-nuke-v2.17.0-darwin-arm64.tar.gz
Create a config.yml file with the following content and place it nearby the extracted executable:
regions:
- global
account-blocklist:
- "999999999999" # leave it as it is, since the current version wont work if you don't provide a blocklist
accounts:
"000000000000": {} # fill in your own AWS account number
Run the following command:
./aws-nuke-v2.17.0-darwin-arm64 -c config.yml
This should list the resources which might be deleted. If you are ok with the list, append --no-dry-run to the previous command.
This question already has answers here:
How to share conda environments across platforms
(6 answers)
Closed 1 year ago.
My project supposed to run on cross platform environment (Mac, Win, Linux).
I've created a conda env that manage our dependencies for an easy setup.
I want to ensure that everyone that want to update the enn could do that, however when I try to export the env from linux to yml file, it couldnt be install properly on Win or Mac and vise versa.
I've already tried to do the regular stuff:
1.
conda env export > env.yml
conda env create --name -f env.yml
2.
conda env export --no-builds > env.yml
3.
https://medium.com/#Amet13/building-a-cross-platform-python-installer-using-conda-constructor-f91b70d393
4.
https://tech.zegami.com/conda-constructor-tutorial-make-your-python-code-easy-to-install-cross-platform-f0c1f3096ae4
5.
https://github.com/ESSS/conda-devenv/blob/master/README.rst
non of the above give me the right answer... some of the tutorials I've attached might help, but I didn't succeed to implement them correctly, and they didn't contain some important information for finishing the tutorial properly.
for instance:
Regarding 3/4 - It didn't explain how to create the yml file that should construct the env.
I understood that conda supposed to work on cross platform env...
It would be great if someone could help me with that.
Conda Envs are Not Inherently Cross-Platform
Sorry, but what you're asking for is simply not a thing. Conda can serialize an environment's package information to a YAML (great for reproducibility), but it can't guarantee that it will be cross-platform. In fact, many packages, especially ones with non-Python code, require different underlying build tools as dependencies, so what you're asking for will never be satisfied.
Explicit Specs Only
The closest you can get these days is to limit your environment.yaml to only include explicit specs that have gone into creating your environment by using the --from-history flag. This feature requires Conda v4.7.12 or later.
conda env export --from-history > environment.yaml
This will generate a YAML that only includes the packages that have been explicitly requested in the history of the env, e.g., if your history goes...
conda create -n foo python=3.7 numpy
conda install -n foo pandas scikit-learn
Then the result of conda env export -n foo --from-history will be something like
name: foo
channels:
- defaults
dependencies:
- python=3.7
- numpy
- pandas
- scikit-learn
prefix: /your/conda/dir/envs/foo
This way, you can leave out all the other dependencies that may turn out to be platform-specific.
I'm Still Seeing a Ton of Packages?!
I've noticed that if one ever uses the --update-deps flag in an env, it adds every dependency to being an explicit spec. This is rather unfortunate. If this is the case, I'd suggest recreating the env using your legitimate specs and avoid that flag in the future. Searching through your command history might be useful in compiling that legitimate spec list.
Travis-CI's official R project build support on Ubuntu uses (at the time of this question) gcc version 4.6.
CRAN uses gcc 4.9 and some packages that build fine on CRAN will not build on Travis with gcc 4.6.
How does one change the default gcc compiler for R project/package builds to more closely mirror CRAN builds?
I really wanted to be able to use Travis to test my ndjson package but the C++ library I'm using won't compile under gcc 4.6.
The ndjson package is on CRAN and the CRAN builds are fine (except for r-oldrel on Windows which doesn't bother me a bit), so I needed a way to change the compiler that R uses on Travis.
I'm using gcc 5 in the example below, but you can use any version available in the toolchain test builds. Ideally, one should mimic CRAN's gcc version and this may be something the Travis folks might consider making default for R builds.
The .travis.yml starts off the same:
language: r
warnings_are_errors: true
sudo: required
env:
global:
- CRAN: http://cran.rstudio.com
I added a matrix build configuration to add the new package source as well as specify the package(s) that needed to be installed. I left it in a matrix configuration since I'm going to try to (eventually) add clang.
matrix:
include:
- os: linux
compiler: gcc
addons:
apt:
sources: ['ubuntu-toolchain-r-test']
packages: ['g++-5']
env:
- COMPILER=g++-5
- CC=gcc=5
- CXX=g++-5
Next, I made sure the auto default compiler is set to this newer gcc and also made doubly sure that R would use it by creating a local Makevars:
before_install:
- sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-5 100
- mkdir -p ~/.R
- echo "VkVSPS01CkNDPWdjYyQoVkVSKSAtc3RkPWMxMSAKQ1hYPWcrKyQoVkVSKQpTSExJQl9DWFhMRD1nKyskKFZFUikKRkM9Z2ZvcnRyYW4KRjc3PWdmb3J0cmFuCg==" | base64 -d > ~/.R/Makevars
- cat ~/.R/Makevars
The base64 string equates to:
VER=-5
CC=gcc$(VER) -std=c11
CXX=g++$(VER)
SHLIB_CXXLD=g++$(VER)
FC=gfortran
F77=gfortran
and is just (IMO) cleaner this way.
In theory, all I would have had to do is create the Makevars (i.e. not have to change the default gcc with update-alternatives) but it turned out that Travis used the Makevars gcc setting when installing the dependencies but not for the actual package build itself. So, the update-alternatives is necessary. I also had to add the -std=c11 to ensure a few of the dependencies compiled (the build errored w/o it).
After these modifications to the .travis.yml configuration, ndjson built fine.
Just to give an alternate approach, I use a custom shell script in one of my packages sourcetools. My goal there was to ensure the package would build using the (now ancient) gcc-4.4 compiler. In .travis.yml, I have:
language: r
cache: packages
sudo: false
warnings_are_errors: true
before_install:
- source travis/before-install.sh
addons:
apt:
packages:
- gcc-4.4
- g++-4.4
- clang
r:
- oldrel
- release
- devel
env:
- COMPILER=gcc-4.4
- COMPILER=gcc
- COMPILER=clang
And in travis/before-install.sh, I have:
#!/usr/bin/env sh
mkdir -p ~/.R
if [ "${COMPILER}" = "gcc-4.4" ]; then
echo "CC=gcc-4.4 -std=gnu99" >> ~/.R/Makevars
echo "CXX=g++-4.4" >> ~/.R/Makevars
echo "CXX1X=g++-4.4 -std=c++0x" >> ~/.R/Makevars
fi
if [ "${COMPILER}" = "gcc" ]; then
echo "CC=gcc -std=gnu99" >> ~/.R/Makevars
echo "CXX=g++" >> ~/.R/Makevars
echo "CXX1X=g++ -std=c++0x" >> ~/.R/Makevars
fi
if [ "${COMPILER}" = "clang" ]; then
echo "CC=clang -std=gnu99" >> ~/.R/Makevars
echo "CXX=clang++" >> ~/.R/Makevars
echo "CXX1X=clang++ -std=c++0x" >> ~/.R/Makevars
fi
The end result is basically the same, but IMHO it's somewhat cleaner to separate the 'setup' logic into its own script that's driven entirely off of environment variables. It also makes it easier to construct the R matrix builds, since Travis automatically combines the permutations of r and env here (no need to do it 'by hand').
I imagine the before-install.sh script I use could be cleaned up / made more general, but I haven't had the need to do that yet.
I've been experimenting this and spend more than 25 commit with only small change in .travis.yml but travis always do either:
./configure: if I put the language: cpp in the first line. travis will ignore everything written in .travis.yml and will go straight ./configure && make && make test
language: cpp
addons:
apt:
sources:
- ubuntu-sdk-team
addons:
apt:
packages:
- ubuntu-sdk
before_script: ls
script: qmake demo/QtGoodiesDemo/QtGoodiesDemo.pro && make
sudo: false
rake: if I reorder the placement of language: cpp or remove it. this point, travis succeeded install the dependency (apt addons executed)
addons:
apt:
sources:
- ubuntu-sdk-team
addons:
apt:
packages:
- ubuntu-sdk
before_script: ls
script: qmake demo/QtGoodiesDemo/QtGoodiesDemo.pro && make
language: cpp
sudo: false
I have read the documentation and using what it told just lead me to the point (1) problem.
I've searched but nobody got this problem, I wonder how people do this.
(This is the link)
Attempt 1
using nested apt source still gets me to problem(1) and ignore the custom script (https://travis-ci.org/imakin/QtGoodies/builds/85143452). Note that in problem 2 when rake is called, it succeeded in installing ubuntu-sdk for the Qt dependencies
language: cpp
sudo: false
addons:
apt:
sources:
- ubuntu-sdk-team
packages:
- ubuntu-sdk
before_script: ls
script: qmake demo/QtGoodiesDemo/QtGoodiesDemo.pro && make
Attempt 2
So then I try to play it and added configure file. Having it all rwxrwxrwx permission too. and pushed it. But travis still execute to problem (1) again. No Qt Installing, even failed to run the configure telling it has no permission to execute it. I can't do anything to chmod it in testing process though as before_script is ignored too. This one occurred in https://travis-ci.org/imakin/QtGoodies/builds/85146543
I think your .travis.yml file is invalid and prevents it to be parsed properly, hence you default to the Ruby language.
Can you try merging both addons.apt sections like so:
addons:
apt:
sources:
- ubuntu-sdk-team
packages:
- ubuntu-sdk
Hope this helps!
Update: it turns out the .travis.yml file started with a hidden character that prevented Travis CI from parsing it properly.