Repository navigation
Let users set up continuous integration on their robot projects #27
Description
This enhancement would enable teams to set up continuous integration in the same way we did for Strongback with #22. Most likely this would involve adding more Ant tasks to dynamically the download WPILib (if not found in the home directory?). We'd also have to fully document what teams would do differently, and how to set up their repository with Travis-CI.org.
Activity
xortive commentedon Oct 27, 2015
The ant task for downloading WPILib that Strongback itself uses would probably work for robot projects as well, but my experience with build systems is limited.
Adding a check for an installed version that matches the version Strongback requires would be prudent, but what should happen when an incompatible version of WPILib is already in
~/wpilib/is something that needs careful consideration.rhauch commentedon Oct 27, 2015
This is what I was thinking, but I haven't fully fleshed it out:
ant depsthat would check and install any missing dependencies (primarily WPILib).ant clean test) would not depend onant deps.First, since WPILib should normally be installed on developers machines, most developers would only have to worry about the normal Ant targets (e.g.,
ant clean test deploy) and would not have to runant deps.Second, Travis-CI.org by default will run
ant depsseparately as a "prepare" step before running the ant task (by default that'sant test). So this setup works for both developers and CI (at least Travis, and other CIs like Jenkins can easily be configured to runant depsas a first step).Third, Ant properties are immutable, so properties can't be changed when running. Keeping these as separate steps means the second step would load the properties as normal and directories are expected to be there.
Here's the messy part: Yes, we could have
ant depscheck for the~/wpilib/directory, and if it is missing it could install WPILib there. What happens a developer does this before they run the New Robot Java Development wizard, and their Eclipse plugin version is slightly different than the versionant depsinstalled? In other words, if we take this route the scripts are easy (we literally just need to add to~/strongback/java/ant/build.xmlanant depsthat checks, downloads, and installs the WPILib -- nothing else is needed), but the developer might get into trouble if they do something unexpected.Thoughts?
xortive commentedon Oct 28, 2015
We can check version of WPILib in
ant deployandant testand if it is not supported, we can throw an error and cancel the build. We can show an error message that basically says "Run ant deps to fix this error" or something of that sort.Other ways I can thing of:
Thoughts?
rhauch commentedon Oct 28, 2015
@granjef3: You bring up a really good point I hadn't realized: so far, the Ant tasks that WPILib provides and that we supplement work only in a robot project -- there's nothing defined for a repository that might contain multiple robot projects.
So really we need to provide a script that teams can place at the top-level of their repository, and this script should be self-contained (since neither Strongback nor WPILib might yet be installed), handle checking for and handling dependencies, and then dynamically discover robot projects and for each delegate the
clean,compile, andtesttasks. It should expressly not handledeploy, since that makes no sense at the repository level nor on a CI server.I don't think that we need to or should handle multiple WPILib versions because, at least right now, WPILib only has a "current" version in its installation. Until WPILib changes this and better supports installing multiple versions, there's not much we can do.
The top-level script should probably use Ant for portability, and if we do this we can define a
build.propertiesfile that specifies the URL of the WPILib and Strongback libraries. This way, teams can control which version of each their CI builds use.And as you suggest, the top-level script could potentially check the installed versions and report any problems. This may mean the top-level
build.propertiesfile also has to contain the expected versions to check against the installations; I'm not sure we can derive it from the URLs. And while Strongback's installation does contain a file with the version and build date, this may be tougher since I'm not sure if that same info is in WPILib's installation. Regardless, this could be a useful tool for teams, since each developer could run this to check whether their own machines have the specified version of WPILib and Strongback.The more I think about it, the more I think that the top-level
ant depsshould just install WPILib and Strongback in the~/directory, where the robot project builds will naturally find them. And, the robot project build tasks (e.g.,ant compile) cannot really depend ondeps, since (a) that task is defined at the repository level, and (b) the robot level builds themselves require Strongback and WPILib to already be installed before they can even be run.In summary, I think this issue can be addressed by a top-level
build.xmlandbuild.propertiesfiles that are completely standalone -- they can't use any Ant tasks in Strongback or WPILib since those might not be installed. If teams want to use Travis-CI.org, then there would also be a.travis.ymlfile at this top level.Now, we could use the
strongback.shscript to generate these top-level files (perhaps a simple switch on thenew-projectcommand or a new command altogether). However, perhaps a simpler and better way is to create a new GitHub repository at https://github.com/strongback/robot-ci/, manage these files here, and have a README.md file that describes how to use these files and how to set up Travis-CI.org. Users could fork them, and changes could be tracked with issues and PRs. We could even provide tags for each season (with the URLs updated to the latest versions for that season).WDYT?
rhauch commentedon Oct 29, 2015
I've created a new repository on GitHub for examples, called strongback/strongback-java-examples. And in that repository is a self-contained
build.xmlfile (with abuild.propertiesfile) that defines adepstask to install WPILib and Strongback if they are missing. This works really well, and as you can see I've set up Travis to do CI on this new repository.I'm not sure whether we want to place these files in a different repository, or whether we should just have people copy the files from this examples repository. If it's the latter, then the only thing left for this task is to document it in our book.
If you want to try it, just fork the examples repository, clone it locally, and then run
ant clean testto clean, compile, and build the multiple robot projects. You can even runant deps, although this shouldn't do anything on your local machine if you already have WPILib and Strongback installed.Have a look and see if it's good enough. The
build.xmlfile is not small and it's kinda ugly, but it works and I think the process to set up a team repository using these is straightforward.xortive commentedon Oct 29, 2015
I'm not sure how I feel about the 1 season = 1 repository thing. IMO, a
repository should contain things for one goal/project. I think that e.g. a
team's preseason robot is distinct enough from their actual robot to
warrant a separate repository. This keeps our build.xml simple, and
everything self contained. If I change my code in the preseason robot for a
demo, then it fails tests, that shouldn't make the actual season robot's
code fail tests. 1 repository should equal 1 robot.
On Thu, Oct 29, 2015 at 12:21 AM, Randall Hauch notifications@github.com
wrote:
rhauch commentedon Oct 29, 2015
@granjef3 wrote:
True, although by "season" I really meant "competition season". That generally means one robot project, although in the past we've created additional robot projects for prototype robots created during competition, and those robots were distinct enough from our competition robot that they didn't have a shared codebase.
Of course, you don't have to set it up this way. If you prefer to have only one robot per repository, then that's fine and will certainly work. You still could reuse the
build.xmlfile to make sure that your CI system can download and install WPILib and Strongback.rhauch commentedon Nov 15, 2015
I'm going to close this since there's nothing that strongback-java needs to do or provide.
Merge pull request strongback#27 from Team3132/PhoenixUpdate