How to cache packages which have been installed via `apt-get` in Travis CI? - caching

So, with my .travis.yml, I'm installing some packages via apt-get which doesn't take too long to download, but a very long time to install.
Is there a way to make Travis CI remember the installed packages, so I won't have to install them from scratch for every build?

There seems to be no easy or convenient way to cache all of the packages you need to install via apt-get. According to the Caching Dependencies and Directories documentation, Travis CI currently only provides "convenience" caching for Bundler, CocoaPods, Yarn (and a few others).
However! If you can determine where apt-get installs each of the packages you need (as install locations vary from one package to the next), you can cache each of those install directories individually by following the steps in the Arbitrary directories documentation.
I hope this helps. Please let me know if you have any other questions and I'd be happy to help in any way I can. Cheers!

If the packages you need are in Travis' whitelist, you can install them more simply by adding to your .travis.yml:
addons:
apt:
packages:
- cmake
- package-xy
And cache them with:
cache:
apt: true

Related

What's the difference between installing Yarn from npm, Homebrew, and from source?

I read that on OS X you can install Yarn either by
curl -o- -L https://yarnpkg.com/install.sh | bash
brew install yarn
npm i -g yarn
What functional difference is there between these three methods? Why would someone choose one over the others?
when using brew to install packages, you install them system wide. that is, you cannot have more than one version for the same package, which is usually problematic. for this reason, many other technologies have spawn, such as docker, snap.
moreover, each package manager has its own lifecycle and packs original package in a different manner for ease of use, distribution and maintenance. for instance, npm container is based on the release of npm package itself.
usually, you should stick to the package manager of the same ecosystem that you are using. specifically to your case, it will be recommended to use npm to install and update your package (using package.json). which will give each of your project to pin and lock the desired yarn version that you like, without any affecting your system wide.
speaking of npm, you might wish to look at this answer
curl downloads the installation script from yarnpkg.com, and installs yarn using that script
brew is a package manager for MacOS. It's meant to make things easier for people when installing commands for the terminal. When you install with brew, the package get's put into /usr/local/bin instead of /usr/bin so I believe that this is kind of like a virtual environment, and yarn wouldn't be installed into the core of your machine. You'll have to install homebrew before you can use it, and you install it using curl. I believe that there is less risk when using homebrew because of the reasons that it is kind of like a virtual environment
npm is a package manager for javascript, it's the same as yarn. It's meant for easy installation of javascript packages.
I use brew for all installs to the terminal, and npm for all installs of javascript packages.

Is it safe to use ansible's package module to upgrade all packages?

I have a numer of ansible playbooks I use to perform certain actions on Debian and CentOS VMs. Until now, when I needed to handle packages I would use ansible modules apt and yum. Consequently, I had to check which OS was installed and then use the correct ansible module.
However, I've recently learned there's a module called package which somehow unifies package managers, reducing playbook's complexity, so I'm now trying to use this module only.
One of the operations I want to perform is to update all packages. The problem is that ansible's documentation doesn't say how to do this using package. It does say, however, how to do it with apt and yum: the first one uses and upgrade operation and the latter suggests writing something like:
yum: name=* state=latest
For this reason I thought I could use package to do the following:
package: name=* state=latest
When I ran this playbook I didn't come across any error but this isn't documented anywhere and apt and yum don't work exactly the same way. So my question is: is the command above a safe one as in does it actually do what I want it to do?
Thanks in advance!
EDIT:
I have found out that using package: name=* state=latest will try to install or update all available packages instead of just updating installed ones. Therefore this isn't a valid solution for me. Alternatively, I can keep using yum and apt for this particular action, but I do wonder why is it not possible to do this using package, or if I'm missing something.
Well after further testing I can now answer the question by myself, and the answer is no. Using package: name=* state=latest on a Debian machine will try to install or update every package available in the repositories, so it can't be used as a replacement for an apt-get upgrade.
From the docs below i think its clear that the use you are describing can be considered safe.
From package documentation:
This module actually calls the pertinent package modules for each system (apt, yum, etc).
So whatever you pass to it should be supported by the underlined packagers yum or apt.
From apt documentation:
Name wildcards (fnmatch) like apt* and version wildcards like foo=1.0* are also supported.
From yum->name documentation:
When using state=latest, this can be '*' which means run: yum -y update.
EDIT: After #Xavier Alvarez testing the apt: name=* state=latest will install all packages in repo.

Is there a durable store for deb files (like a maven repo?)

I have a maven built docker image that was dependent on libssl1.0.2_1.0.2d-3_amd64.deb, but this has now a 404 and has been replaced by libssl1.0.2_1.0.2e-1_amd64.deb.
This is a problem because maven builds are meant to be durable - ie you can rebuild them at any point in the future. The main maven repo is durable, so artefacts taken from that will be there in the future. I could move the debs I need into the maven repo, but that is a bit of abuse of other peoples storage...
So is there a durable store of debian files that is guaranteed to exist... well at least until the revolution/meteor strike/Jurassic resurrection etc.
You can do this yourself with free, open-source tools. You can create your own APT repository for storing Debian packages. If you are interested in using GPG signature to sign repository metadata read this.
Once you've created the repository, you can create a configuration file in /etc/apt/sources.list.d/ pointing to your repository. You can run apt-get update to refresh your systems apt cache, and then run apt-get install to install the package of your choice.
BTW, you can install a particular version of a package by running: apt-get install packagename=version.
For example, to install version 1.0 of "test", run: apt-get install test=1.0.
Alternatively, if you don't want to deal with any of this yourself you can just use packagecloud.io for hosting Debian, RPM, RubyGem, and Python PyPI repositories. A lot of people who use our service have your exact use case, where Debian packages they depend on disappear from public repositories so they upload them to us.

Better way to manage libraries required for gems?

I consistently run into issues with gems not having the required libraries on a server. RMagick is one, and usually mysql2, which usually require installing the dev versions such as:
imagemagick libmagickcore-dev libmagickwand-dev
My question is, is there a better way to manage this? I'm using bundler and capistrano, so it would be great if somebody could point me in the right direction.
The big problem I can see is that distros will change from server to server, but if I had a task I could run which could check the existence of these required packages based on the Gemfile, that would be tremendously helpful. Is this possible?
You can extend section 'cap deploy:setup'. =And in this section run 'apt-get instal imagemagick libmagickcore-dev libmagickwand-dev'. But you user must have sudo access.
Also you can read this manual

SmartGit Installation and Usage on Ubuntu

I have downloaded latest SmartGit installation and each time I want to use it I need to run script smartgit.sh from SmartGit bin directory, this process requires the same repository setup every time.
What it correct way of installing SmartGit on Ubuntu? Thus I can have normal icon and run the program from state of previous usage, without configuring repositories every time.
Thanks.
You can add a PPA that provides a relatively current version of SmartGit(as well as SmartGitHg, the predecessor of SmartGit).
To add the PPA run:
sudo add-apt-repository ppa:eugenesan/ppa
sudo apt-get update
To install smartgit (after adding the PPA) run:
sudo apt-get install smartgit
To install smartgithg (after adding the PPA) run:
sudo apt-get install smartgithg
This should add a menu option for you
For more information, see Eugene San PPA.
This repository contains collection of customized, updated, ported and backported packages for two last LTS releases and latest pre-LTS release
What it correct way of installing SmartGit on Ubuntu? Thus I can have
normal icon
In smartgit/bin folder, there's a shell script waiting for you: add-menuitem.sh. It does just that.
Now on the Smartgit webpage (I don't know since when) there is the possibility to download directly the .deb package. Once installed, it will upgrade automagically itself when a new version is released.
Seems a bit too late, but there is a PPA repository with SmartGit, enjoy! =)

Resources