search

prplfoundation / prplMesh

This repository moved to https://gitlab.com/prpl-foundation/prplmesh/prplMesh
Other
65 stars 32 forks source link

Deliver boardfarm along with prplMesh #1069

Closed abelog closed 4 years ago

abelog commented 4 years ago

Description

As part of boardfarm integration into prplMesh, we need to have a copy of that repo to work with, because boardfarm isn't deployed in form of stand-alone package.

Possible solutions

2 options available:

Exit criteria

boardfarm can be used just after prplMesh git clone or repo sync without additional hassle (like cloning a separate repo).

taurha commented 4 years ago

I think, the easiest way will be adding boardfarm source into prplMesh manifest. Draft pull request will be created as soon as necessary permissions for prplfoundation/prplMesh-manifest repo will be granted to me.

taurha commented 4 years ago

If we get sources from mattsm/boardfarm repo and make a minor tweak in boardfarm launcher - we can use provided setup.py script to build & install boardfarm lib and use its executable.

As a result, I suggest, we should fork mattsm/boardfarm repo, apply minor tweaks to be able build stand-alone package and include forked boardfarm remote source to prplMesh repo manifest.

arnout commented 4 years ago

From #prplmesh-democracy:

We use external libraries and tools, of course. Some of these are readily packaged by the OS and we can easily use (e.g. zmq, json-c). For some, it is not so clear (e.g. hostapd: wpa_ctrl.c is typically not put in a library). However, this poll is about the libraries and tools for which there is no packaging at all or the packaging is not satisfactory: easylogging++, nng, boardfarm, gtest/gmock, ... Boardfarm is the one for which we urgently need to make a decision. Integrating such "custom" packages can be done in a number of ways.

  1. Not bundled, rely on the packaging system for everything. We have to make sure that the integration layer (openwrt, ubuntu/dockerfile, RDK-B) provides the things we need. For boardfarm this is a bit different because it's not something to run on target, so it would only be necessary to support it on Ubuntu. Concretely for boardfarm this would mean that there's a dockerfile that downloads/clones boardfarm, and a README that explains how to do it. This is the least effort solution, but becomes unmaintainable if we need to make modifications to the external project.
  2. Use Google's repo tool. repo makes managing several repositories with different versions easier. We already have prplMesh-manifest because we used to use repo for dwpal, hostapd, ... . repo is a little bit clunky to use the first time because you have to install the tool and you need different commands to keep the repositories in sync. For this reason, CI becomes a little bit more complicated.
  3. Use git submodules. Pretty similar to repo. However, git submodules have two major things missing compared to repo: it is not possible to automatically stay with "current master" of one of the submodules, and the commands/workflow to keep things up to date is slightly less intuitive. However, the advantage is that it is natively supported by gitlab-ci so much less effort to integrate in CI. Similarly, the workflow for an ordinary user (who doesn't need to modify any of the submodules) is much easier.
  4. Directly bundle in the repo. This is how it was done for easymesh++. It is by far the easiest way to maintain things if we want to make modifications to it. However, it is a bit tricky to keep in sync with the upstream project (although integrating through git subtree can help a lot with that). It also flies in the face of best practices which consider bundling evil.

https://www.strawpoll.me/19707590

taurha commented 4 years ago

I'm suggesting not to update existing boardfarm fork, because we don't have necessity to modify its sources so far. For that case it was picked a commit at mattsm/boardfarm repo by Apr 6, 2020.

Created PR: https://github.com/prplfoundation/prplMesh-manifest/pull/11