Send source files to RoboRIO

[JaciBrunning]

Bundle source files into their own jar / zip, and place them in a known location on the RoboRIO (example: /home/lvuser/sources/{project_name}-sources.jar). This can be useful in recovering code from a robot in the case teams lose their local copy.

Implementation facets:

• [ ] Allow the user to disable these sources from being deployed
• [ ] Expire old sources if the RoboRIO is running low on storage space.
  • There is the possibility for more than one project jar to be present in multi-project builds. We should attach a metadata that dictates when the code was built, e.g. {project_name}.meta.

[solomondg]

this is a good idea.

[vairamsvsjdo]

Why use RoboRIO for storing source when Github is there for someone to store their source. Also, if private repository is needed for free: use http://dev.azure.com/ with upto 5 free user account

[JaciBrunning]

It's for an emergency restore in case a team loses their code during competition. Teams should still use a proper VCS

[Starlight220]

This can theoretically be done completely from the template build.gradle DSL, no need to add any features to GradleRIO/EmbeddedTools. I haven't tested this, but this simple snippet should send the source code as an artifact to a disconnectable USB drive connected to the RIO:

deploy {
// ...
  fileTreeArtifact("SourceCode") {
    files = fileTree(dir: 'src/main/java')
    targets << "roborio"
    directory = '/path/to/drive/'
  }
}

This will likely overwrite anything that's already there (such as previous source code deploys), but it can be further configured to place each new deploy at a new path, possibly with a generated metadata/manifest file.

[JCaporuscio]

Bumping this as I think it's a good idea. Being able to recover source in case of emergency is extremely useful.