summaryrefslogtreecommitdiffstats
path: root/docker (follow)
Commit message (Collapse)AuthorAgeFilesLines
* unit tests: support code coverage instrumentation and reportsArthur Jones2018-07-041-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, make check runs the unit tests and reports pass/fail, but we have no way to guage how much of the code is covered by these tests. gcov provides those statistics on a per source file basis, but requires special CFLAGS and LDFLAGS. Here, we add the --enable-gcov configure option to setup those options correctly. We also add a make target called check-coverage, which runs the unit tests, runs gcov and uploads the data to the codecov.io cloud service for display. Finally, we include a Dockerfile-coverage which creates a container image in alpine linux to run the tests. To create the image: $ docker build \ --build-arg commit=`git rev-parse HEAD` \ --build-arg token=<upload token from codecov.io> \ -t frr-gcov:latest \ -f docker/alpine/Dockerfile-coverage . and to create and upload the report: $ docker run -it --rm frr-gcov:latest Testing done: Created and uploaded a report from my fork using alpine linux 3.7. Non-coverage alpine 3.7 build still works. Issue: https://github.com/FRRouting/frr/issues/2442 Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
* alpine packaging: use a more standard packaging formatArthur Jones2018-04-101-1/+3
| | | | | | | | | | | | | | | | | | | | Currently, we just package the frr daemons, but we don't run them. This is fine for basic tests, but it is inconvenient to orchestrate the daemons from downstream test environments. Here, we follow the redhat and debianpkg formats more closely, putting the daemons in /usr/lib/frr and including the frr user and groups in the package. We also include a docker specific startup script and a sysvinit link in /etc/init.d/frr for openrc based alpine installs. Testing done: Built packages, built base images, everything seems to work fine. Uninstalled the package, all the daemons stopped. Issue: https://github.com/FRRouting/frr/issues/2030 Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
* alpine packaging: build packages and base image directly from gitArthur Jones2018-04-043-11/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently, we tar up the git repo before building alpine packages. This ensures that the packages we're building are exactly what is checked in. But, in practice, this restriction causes us to not be able to build off of git contexts, which is a convenient feature especially when using docker-compose. So, here, we build the alpine packages directly from the contents of the current directory and we install the packages into a base image to ease downstream consumption. There is still work to be done in that area, as we need to package up the daemons, frr user and all the rest, but that's for later... Testing-done: Built directly from the git repo, built from a reference to the git repo and built using docker-compose, all seemed to work. Also, tested by @leleobhz and seems to build fine. Thanks to Leonardo Amaral (@leleobhz) for reporting the issue and for the original idea for a fix. Issue: https://github.com/FRRouting/frr/issues/2024 Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>
* docker build: build Alpine Linux dev packages in dockerArthur Jones2018-03-195-0/+65
Building alpine packages in a "standard" distro can be complicated due to the limited scope of the distro (embedded and small docker images). Building in a VM is one possibility, but docker support for alpine is very good (default docker images come in alpine due to the very small size). Here, we want to package up the current git repo into apk packages that can be easily installed in alpine linux using the apk tool. This support is not intended to package released versions of apk packages, that, if it comes to be, should be done here: git://git.alpinelinux.org/aports We're content here to build packages that can be used by developers to try out frr in docker and other alpine environments. This is a very minimal environment, we don't support importing keys (so, installing the packages with apk requires the --allow-untrusted option). In addition, we can't use the git commit id in hex as version tag, as alpine doesn't support hex digits in the version string. So, we need to convert the git hash to decimal before tagging the package with the extra version. This is yucky, but I can't think of another way to get a unique version per package. The alpine way (using a numeric date), only works for released packages, not for dev packages. Issue: https://github.com/FRRouting/frr/issues/1859 Signed-off-by: Arthur Jones <arthur.jones@riverbed.com>