I have an installation of Jenkins on Azure and wish to build a c++ project using Conan. Many examples show the following pipeline command to initiate Conan:
def conanClient = Artifactory.newConanClient()
however this throws an error:
sh: 1: conan: not found ERROR: Couldn't execute Conan task.
RuntimeException: Conan build failed with exit code 127
I assumed the newConanClient() would install Conan but that is not the case as verified by:
sh 'conan -v' resulting in conan: not found
From the JFrog documentation you would think there shouldn't be any problems as they say:
There is no need for any special setup for it, just install Conan and
your build tools in the Jenkins machine and call the needed Conan
commands.
https://docs.conan.io/en/latest/integrations/ci/jenkins.html?highlight=jenkins
So how does one "just install Conan" in Jenkins?
From the Documentation:
Conan can be installed in many Operating Systems. It has been extensively
used and tested in Windows, Linux (different distros), OSX, and is also
actively used in FreeBSD and Solaris SunOS. There are also several
additional operating systems on which it has been reported to work.
Based on your OS, you can install from here. newConanClient() method is part of the Artifactory plugin for Jenkins but doesn't install Conan
Now you can verify the installation
conan -v
and further can execute commands in Jenkins pipeline
sh 'conan build .'
Related
I am getting this error:
(iit_synthesis) brando9~ $ bash -c "sh <(curl -fsSL https://raw.githubusercontent.com/ocaml/opam/master/shell/install.sh)"
## Using already downloaded "/tmp/user/22003/opam-2.1.4-x86_64-linux"
## Where should it be installed ? [/lfs/ampere4/0/brando9/.local/bin] ~/.local/bin
## '~/.local/bin' resolves to '/lfs/ampere4/0/brando9/.local/bin', do you confirm [Y/n] Y
## opam 2.1.4 installed to /lfs/ampere4/0/brando9/.local/bin
## Converting the opam root format & updating
No configuration file found, using built-in defaults.
Checking for available remotes: rsync and local, git.
- you won't be able to use mercurial repositories unless you install the hg command on your system.
- you won't be able to use darcs repositories unless you install the darcs command on your system.
[WARNING] Missing dependencies -- the following commands are required for opam to operate:
- bwrap: Sandboxing tool bwrap was not found. You should install 'bubblewrap'. See https://opam.ocaml.org/doc/FAQ.html#Why-does-opam-require-bwrap.
[ERROR] Sandboxing is not working on your platform ubuntu:
"~/.opam/opam-init/hooks/sandbox.sh build sh -c echo SUCCESS >$TMPDIR/opam-sandbox-check-out && cat $TMPDIR/opam-sandbox-check-out; rm -f
$TMPDIR/opam-sandbox-check-out" exited with code 10
Do you want to disable it? Note that this will result in less secure package builds, so please ensure that you have some other isolation mechanisms in
place (such as running within a container or virtual machine). [y/N]
but it doesn't link to a way to actually install it, link given https://opam.ocaml.org/doc/FAQ.html#Why-does-opam-require-bwrap and also I thought this would mean I don't need to do that:
opam init --disable-sandboxing
opam update --all
eval $(opam env)
am I wrong? I'm confused.
To install bubblewrap on Ubuntu 18.04 or later just do
sudo apt-get install bubblewrap
If you have an older Ubuntu distribution or a distribution that doesn't package this program, then follow the instructions on the bubblewrap page to install it.
Of course, you can opt out of using bubblewrap, this is actually what the message is telling you. Just say, y for yes and it will continue without bubble-wrapping anything. For example, if you're building in a docker container, you don't need an extra layer of containerization that is provided by bubblewrap so you can drop it off.
also I thought this would mean I don't need to do that:
opam init --disable-sandboxing
...
Yes, once you install opam the binary, and if you opted out of using bubblewrap you need to initialize opam with this option (opam installation roughly consists of two steps, first you download and install the binary, next you need to run opam init so that it configures itself in your system).
I am trying to install the lustre clients on Unbuntu 20.04 nodes I have in GCP. Im using linux kernel version 5.15.0-1021-gcp.
I'm trying to install the client with the following code:
cd /home/apps/
mkdir lustre
git clone git://git.whamcloud.com/fs/lustre-release.git
cd lustre-release
git checkout 2.15.0
sh autogen.sh
./configure --prefix=/home/apps/lustre --disable-server --enable-client ## doesnt run! Fails at ./configures with error message "error: Run make config in /lib/modules/5.15.0-1021-gcp/build"
make debs
The configure step fails with an error about running make config in /lib/modules/5.15.0-1021-gcp/build. I tried running make config in /lib/modules/5.15.0-1021-gcp/build but was asked to input some values that I was unsure of.
I also tried downloading the deb package of the client software at
https://downloads.whamcloud.com/public/lustre/lustre-2.15.0/ubuntu2004/client/lustre-client-modules-5.4.0-96-generic_2.15.0-1_amd64.deb. However this is for the wrong linux kernel and I'm not sure what env variables need to be set for this package.
Anyone know how to install the client modules for lustre on Ubuntu?
You need to have the kernel sources or kernel-devel package that exactly match the kernel that you are installing on. This should also include the .config file that describes all of the options used when building your kernel.
Alternately, you could try a pre-built package, but it isn't clear if this will install on your kernel or not.
https://build.whamcloud.com/job/lustre-b2_15/40/arch=x86_64,build_type=client,distro=ubuntu2204,ib_stack=inkernel/
Background
I have a CI pipeline for a C++ library I've been developing. So far, I can distribute this lib to Linux and Windows systems. Since I use GitLab to build, test and package my lib, I'd like to have my Windows builds running faster and I have no clue on how to do that.
Currently, I use the following script for my Windows builds:
.windows_template:
tags:
- windows
before_script:
- choco install cmake.install -y --installargs '"ADD_CMAKE_TO_PATH=System"'
- choco install python --pre -y
- choco install git -y
- $env:ChocolateyInstall = Convert-Path "$((Get-Command choco).Path)\..\.."; Import-Module "$env:ChocolateyInstall\helpers\chocolateyProfile.psm1"; refreshenv
- python -m pip install --upgrade pip
- pip install conan monotonic
The problem
Any build with the script above can take up to 10 minutes; worse: I have two stages, each one taking the same amount of time. This means that my whole CI pipeline will take 20 minutes to finish because of slowness in Windows builds.
Ideal solution
EVERYTHING in my before_script can be cached or stored as an image. I only need some hints on how to do it properly.
Additional information
I use the following tools for my builds:
CMake: to support my building process;
Python3: to test and build packages;
Conan (requires Python3): to support the creation of packages with several features, as well as distribute them;
Git: to download Googletest in CMake configuration step This is already provided in the cookbooks - I might just remove this extra installation step in my before_script;
Googletest (requires Python3): testing library;
Visual Studio DEV Tools: to compile the library This is already in the cookbooks.
Installing packages like this (whether it's OS packages though apt-get install... or pip, or anything else) is generally against best practices for CI/CD jobs because every job that runs will have to do the same thing, costing a lot of time as you run more pipelines, as you've seen already.
A few alternatives are to search for an existing image that has everything you need (possible but not likely with more dependencies), split up your job into pieces that might be solved by an image with just one or two dependencies, or create a custom docker image to use in your jobs. I answered a similar question with an example a few weeks ago here: "Unable to locate package git" when running GitLab CI/CD pipeline
But here's an example Dockerfile with Windows:
# Dockerfile
FROM mcr.microsoft.com/windows
RUN ./install_chocolatey.sh
RUN choco install cmake.install -y --installargs '"ADD_CMAKE_TO_PATH=System"'
RUN choco install python --pre -y
RUN choco install git -y
...
The FROM line says that our new image extends the mcr.microsoft.com/windows base image. You can extend any image you have access to, even if it already extends another image (in fact, that's how most images work: they start with something small, like a base OS installation, then add things needed for that package. PHP for example starts on an Ubuntu image, then installs the necessary PHP packages).
The first RUN line is just an example. I'm not a Windows user and don't have experience installing Chocolatey, but you'd do here whatever you'd normally do to install it locally. The rest are for installing whatever else you need.
Then run
docker build /path/to/dockerfile-dir -t mygroup/mytag:version
The path you supply needs to be the directory that contains the Dockerfile, not the Dockerfile itself. The -t flag sets the image's tag after it's built (though you can do that with a separate command, docker tag too).
Next, you'll have to log into whichever registry you're using (Docker Hub (https://docs.docker.com/docker-hub/repos/), Gitlab Container Registry (https://docs.gitlab.com/ee/user/packages/container_registry/), a private registry your employer may support, or any other option.
docker login my.docker.hub.com
Now you can push the image to the registry:
docker push my.docker.hub.com/mygroup/mytag:version
You'll have to review the information in the docs about telling your Gitlab runner or pipelines how to authenticate with the registry (unless it's Public on Docker Hub or you use the Gitlab Container Registry) https://docs.gitlab.com/ee/ci/docker/using_docker_images.html#define-an-image-from-a-private-container-registry
Once all that's done, you can use your new image in your CI jobs, and everything we put into the image will be ready to use:
.windows_template:
image: my.docker.hub.com/mygroup/mytag:version
tags:
- windows
...
Following these instructions to install the DataStax C++ Driver on MacOS High Sierra, as a pre-requisite to installing the DataStax PHP Driver for Cassandra.
Everything runs great until I get to the line "make install" in the "Building and installing the C/C++ driver" section. That's where I get the message: "make: *** No rule to make target `install'. Stop."
Can someone help me get past this step?
** SOLVED ** a friend helped me stumble across the solution. Two things to remember when installing on MacOS High Sierra:
1.) You need to run the install of cpp-driver (which isn't a step in the DataStax instructions referenced in the question) and then
2.) You have to fully qualify the cmake .. command to point to the OpenSSL install.
Here are the amended instructions that worked for me:
# Datastax C++ driver dependencies
brew install libuv cmake
brew install openssl
brew link --force openssl
# Install git if you dont have it
brew install git
# Retrieve the cpp
git clone https://github.com/datastax/cpp-driver.git --depth=1
mkdir cpp-driver/build
cd cpp-driver/build
# Build with qualified path to OpenSSL location
cmake -DOPENSSL_ROOT_DIR=/usr/local/opt/openssl/ -DOPENSSL_LIBRARIES=/usr/local/opt/openssl/lib ..
make
make install
# Install pecl driver
pecl install cassandra
Once that's complete you should be good to go.
After following the instructions on the QuickStart, I'm seeing some errors in Yesod when bringing up a webpage. The errors end in:
...
cannot satisfy -package-id wai-extra-1.3.4.6-62543d69d10941dae1d9b206c3eb3067:
wai-extra-1.3.4.6-62543d69d10941dae1d9b206c3eb3067 is unusable due to missing or recursive dependencies:
blaze-builder-conduit-1.0.0-1053545317cd68e3d51439dd9a0e622d zlib-conduit-1.0.0-b51dc7daf506ea4c5ecd031c5101d96a
(use -v for more information)
Build failure, pausing...
Hopefully related, the referenced tutorial has me run
cabal-dev install
on a fresh Yesod project, however that also gives me errors:
...
[1 of 1] Compiling Control.Monad.Logger ( Control/Monad/Logger.hs, dist/build/Control/Monad/Logger.o )
Control/Monad/Logger.hs:63:39:
Module System.Log.FastLogger' does not exportpushLogStr'
Control/Monad/Logger.hs:63:72:
Module System.Log.FastLogger' does not exportLoggerSet'
Control/Monad/Logger.hs:63:83:
Module System.Log.FastLogger' does not exportnewLoggerSet'
Control/Monad/Logger.hs:63:97:
Module System.Log.FastLogger' does not exportdefaultBufSize'
Failed to install monad-logger-0.3.3.0
...
On this later set of errors, I came across a page suggesting the issue has been fixed (SO won't let me post more than 2 links, but Google the error and it comes right up).
Any ideas?
Thanks in advance!
I'd suggest using cabal sandbox for each Yesod project, rather than installing the Yesod platform as part of your system libraries. Think of a cabal sandbox as a localized collection of Haskell packages in a single project, so you could have different versions of a package, say Data.Text, in 2 different cabal sandboxes. Using cabal sandbox takes longer time for compilation but it makes things simpler for dependency resolution (read more here: (read more here: http://coldwa.st/e/blog/2013-08-20-Cabal-sandbox.html). cabal sandbox requires a cabal version of at least 1.18 if I'm not mistaken.
Alright, enough of the talk. Let's get started.
To get the latest cabal, it's easier if you have cabal installed through a package manager, even if the package manager installs a cabal without cabal sandbox. Since you are on Ubuntu, just:
sudo apt-get install cabal
Once you have some version of cabal installed, run:
cabal sandbox
If you see something along the lines of this:
cabal: Please specify a subcommand (see 'help sandbox')
Then congratulations, the version of cabal that you have supports cabal sandbox, just move on Once you have a Cabal with cabal sandbox section of the answer.
If instead you see something like:
cabal: unrecognised command: sandbox (try --help)
Then you will need a more modern version of cabal. Simply clone the cabal repository on github:
git clone https://github.com/haskell/cabal.git
Go to the directory, and checkout the branch Cabal-v1.18.1.2, like so:
git checkout Cabal-v1.18.1.2
Then execute:
cabal install Cabal/ cabal-install/
This should install cabal in the $HOME/.cabal/bin folder. Be sure to prepend $HOME/.cabal/bin to your PATH environment variable, before the folder where the system's cabal is located.
Once you have a Cabal with cabal sandbox
Based on what I read from the Yesod quick start guide, you will want to install the yesod-bin package. It's hackage page is here. Basically, yesod-bin provides you with a yesod binary that allows you to initialize a scaffolded site. The latest version of yesod-bin is 1.2.5.6, and that's what we're going to install.
Create a directory named yesod-bin:
mkdir yesod-bin
Go into that directory, and set up a cabal sandbox in that it, like so:
cabal sandbox init
Fetch the latest package list from hackage using:
cabal update
Now, we are going to install the latest version of yesod-bin, 1.2.5.6, in a cabal sandbox. However, yesod-bin has a dependency on the mmorph package, which defaults to install version 1.01, and trying to install mmorph-1.01 will result in an error message like the following:
src/Control/Monad/Morph.hs:76:8:
Could not find module `Control.Applicative.Backwards'
Use -v to see a list of the files searched for.
Failed to install mmorph-1.0.1
cabal: Error: some packages failed to install:
mmorph-1.0.1 failed during the building phase. The exception was:
ExitFailure 1
and installing yesod-bin without specifiy the mmorph package version defaults to installing mmorph-1.0.1, resulting in the following error:
cabal: Error: some packages failed to install:
base64-conduit-1.0.0 depends on mmorph-1.0.1 which failed to install.
blaze-builder-conduit-1.0.0 depends on mmorph-1.0.1 which failed to install.
conduit-1.0.10 depends on mmorph-1.0.1 which failed to install.
http-client-conduit-0.2.0.1 depends on mmorph-1.0.1 which failed to install.
http-conduit-2.0.0.3 depends on mmorph-1.0.1 which failed to install.
http-reverse-proxy-0.3.0 depends on mmorph-1.0.1 which failed to install.
mmorph-1.0.1 failed during the building phase. The exception was:
ExitFailure 1
network-conduit-1.0.1 depends on mmorph-1.0.1 which failed to install.
project-template-0.1.3.2 depends on mmorph-1.0.1 which failed to install.
resourcet-0.4.10 depends on mmorph-1.0.1 which failed to install.
wai-2.0.0 depends on mmorph-1.0.1 which failed to install.
wai-logger-2.1.1 depends on mmorph-1.0.1 which failed to install.
warp-2.0.2 depends on mmorph-1.0.1 which failed to install.
yaml-0.8.5.3 depends on mmorph-1.0.1 which failed to install.
yesod-bin-1.2.5.6 depends on mmorph-1.0.1 which failed to install.
which seems to be related to these 2 issues in the mmorph github repo:
https://github.com/Gabriel439/Haskell-MMorph-Library/issues/8
https://github.com/Gabriel439/Haskell-MMorph-Library/pull/10
However, mmorph version 1.0.0 works fine. As such, we will have to specify the version of mmorph to be 1.0.0 when we install yesod-bin, like this:
cabal install mmorph-1.0.0 yesod-bin-1.2.5.6
This will take quite some time. cabal sandbox creates a directory named .cabal-sandbox inside the yesod-bin directory, and the yesod binary (along with several other binaries from the yesod-bin package) can be found in the .cabal-sandbox/bin folder. Simply add that folder into your PATH, and you should be able to do the yesod init and yesod devel as seen at the end of the quick start.
As an quick update to #yanhan great answer, since I have tried to follow his guidelines on Ubuntu 14.04 LTS and get stuck a bit.
If you don't have cabal executable preinstalled, you can also do:
git clone https://github.com/haskell/cabal.git
Then of course:
git checkout Cabal-v1.20.0.2
And then you can use the bootstrap.sh script to install cabal executable and Cabal package:
cd cabal-install && ./bootstrap.sh
It will take some time, but soon after you can check the version of newly installed cabal executable:
$HOME/.cabal/bin/cabal --version