This is a collection of “third-party package” definitions.
See the support_3pp recipe module docs for the format of package definitions.
TODO(crbug.com/1171499): run_locally might not work. See [./run_locally.sh]. You can pass help as the first argument for the lowdown. run_locally.sh requires docker to be installed. For googlers, please refer to go/docker.
If possible, prefer to use git, url, or script methods. If none of these are workable for a package, cipd source may be used.
Some third-party packages distribute their releases via source tarballs or zips. Sometimes this is done via http or ftp.
To ingest a new tarball/zip:
Download the official tarball release from the software site.
recipe_engine/archive module.Put the tarball in an empty directory by itself (don‘t unpack it). The name of the archive doesn’t matter. Your directory should now look like:
some/dir/ pkgname-1.2.3.tar.gz
Now run:
$ PKG_NAME=pkgname $ VERSION=1.2.3 $ cipd create
-in some/dir
-name infra/third_party/source/$PKG_NAME
-tag version:$VERSION
You can now use the source in a 3pp package definition like:
source { cipd { pkg: “infra/third_party/source/pkgname” default_version: “1.2.3” original_download_url: “https://original.source.url.example.com” } # Lets 3pp recipe know to expect a single tarball/zip unpack_archive: true }
By default the 3pp recipe also expects unpacked archives to unpack their actual contents (files) to a subdirectory (in the Unix world this is typical for tarballs to have all files under a folder named the same thing as the tarball itself). The 3pp recipe will remove these ‘single directories’ and move all contents to the top level directory. To avoid this behavior, see the no_archive_prune option.