| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
| |
* Update build instructions
* Remove manually installed daemons file
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
|
| |
|
|
|
|
| |
Utilizes debian buster and the support libyang from the vendor.
Signed-off-by: Rob Gil <rob@rem5.com>
|
| |
|
|
|
|
|
| |
Don't delete the Alpine docker image after the build.
Also, extract the packages from the build stage, so that we can
remove them from the final image.
|
| |
|
|
|
| |
The packages resulting from the Alpine build should be installed
to docker/alpine and not to the general docker directory.
|
| |
|
|
|
|
|
| |
As we need libyang, which is only part of Alpine Linux edge/testing,
update the Dockerfile to use this repository.
Also, update the Dockerfile to adhere more to best common practices.
|
| |
|
|
|
|
| |
The standard Alpine package should not install docker glue,
so remove it from the APKBUILD and install it in the Dockerfile
instead.
|
| |
|
|
| |
Signed-off-by: Rob Gil <rob@rem5.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
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>
|
