UI-based or Scripting-based for Install/Deploy

[jkoritzinsky]

Are we planning on using a UI-based tool or a Scripting style (either an executable or a Powershell/bash script) for install and deploy?

[ThadHouse]

Currently the Deploy I'm working on uses Windows Forms. 1 reason I think to use this method is that it will work on linux and mac with mono. If we used bash or powershell we would have to write a seperate script for linux and mac, and it we used something like python it would involve 1 more dependancy to install. We could easily make the executable be a console application instead of a WinForm application, but I added some command like arguments so its possible to automate it if somebody wants to turn it into a script.

[jkoritzinsky]

For Deploy how would you feel about factoring out the Deploy script to be usable in an MSBuild (or Mono's XBuild) task so it could show up directly in Visual Studio as a possible target?

[ThadHouse]

Is it possible to do that? I didnt know. My plan was to just in the templates change the executable to run the deploy executable, but If you can make it usable in MSBuild that would be cool. As long as you can run SSH and SFTP from the MSBuild script.

[jkoritzinsky]

It is possible, I just need to find the right assemblies to reference. I'll be able to SSH and SFTP (I was acutally thinking about SCPing instead) through the SSH.NET library.

[ThadHouse]

OK.

So my thought for the deploy was to treat the HAL as completely seperate, to allow updated to it to be more controlled the the rest. Right now when you grab the MyGet package, it only includes WPILib.dll, HAL-Base.dll and NetworkTablesDotNet.dll. My thought was to host specific versions of the HAL, which includes HAL-RoboRIO.dll and libHALAthena_shared.so, and have those get installed to a seperate directory, such as /home/lvuser/hal. Then on deploy, the tool would against the newest version of the HAL we have hosted elsewhere, and give the option to upgrade the HAL if needed. I know that the py guys do this in order to control the HAL versions better. We should never need to updated the autogenerated files unless the headers for the HAL change, and I dont think it would be a good Idea to accidentally include a mistake in the HAL when WPILib updates happen.

[jkoritzinsky]

I agree. We just need a setup for version management.

[ThadHouse]

The MyGet has 2 feeds. 1 is a dev feed, which is what builds every build. Then to the stable branch I can push builds individually from the Dev Feed. So for WPILib versioning control the MyGet feed will work. For the HAL we could probably just create ZIPs when we want to do a release and then find somewhere to host them.

[jkoritzinsky]

For releasing the HAL zips we could use the GitHub Releases feature.

[jkoritzinsky]

Can you add me to this repository as a collaborator so I can push out my preliminary version?

[ThadHouse]

Added you to all 3 other repositories too.

[jkoritzinsky]

Pushed my preliminary implementation.

[ThadHouse]

How do I test these out? Do I have to install the template somehow?

[jkoritzinsky]

Just make another assembly that calls the methods on the InstallDeployManager class and verify that it works the expected way.

[ThadHouse]

OK