Devops Part 1 #25
Devops Part 1 #25
Conversation
- Eventually these probably will be automatically updated and/or generated?
|
Oh, I was not quite sure what to do with Reviva.pdb - I think it shouldn't get copied into the repo GameData/Reviva because that's usually how I zip things up (or intend to). Also it seemed useful to update the game's copy of Reviva so you can do Build and rerun of KSP. The real CI/CD wouldn't / couldn't do this - so... meh... a problem for another day. |
|
It's critical to have the pdb in GameData for debugging. I usually manually remove them when packaging up a release, but perhaps the "make release" step can just do that. Why do you prefer spaces over tabs? I feel the exact opposite. I'm also not really sure about deploying the GameData folder to the game directory. The way I usually work, I make a junction from the KSP GameData to the mod repo's GameData folder. This way I can have several instances of KSP pointing to the same development repo. I recently started working with KSPCF and it deploys to GameData, and I've found that I can just point other instances of KSP at the mod folder in the KSP reference install. That's good enough. But also I'd be wary of spending extra time copying stuff on each build, and the risk of possibly having stuff get out of sync if things fail to copy or something. |
|
Huh, I prefer tabs over spaces too, but I thought that was unusual, most places I work at or mods are "tabs bad". Do you have tabs as 8 spaces, or 4? I use Emacs so it doesn't make a difference, but I thought having an editorconfig would at least mean anyone contributing would match. Yeah, I wasn't a big fan of the "installing to game", especially if this is used on a build machine, since that wouldn't make sense. I'll add the pdb, and the release automation will make sure it's not there, when I get round to that. |
|
I use a tab width of 4, but I’m also not sure that this needs to be specified because one of the main advantages of tabs is that people can set their own widths. I think I’m fine with the deployment step, because even though it’s not my typical workflow it’s certainly one less step for any new contributor to have to worry about. It’s also easy enough for me to work around. The junction approach is also sometimes annoying when dealing with ckan, if you accidentally update or uninstall the mod while the junction is in place. |
|
This seems to work: https://github.com/KSPModStewards/Singularity/blob/977ad678924d952ab82cf0606e29ae0ef46880c6/Singularity/Singularity/Singularity.csproj#L74 However I thought of one thing that the copy method might not do so well - If there are settings files etc. that live in GameData they will be deleted by the /MIR switch. That's good for mimicking a fresh install, but not great if you actually need to keep those. I'm not sure what a good solution would look like. It would also, of course, be possible to automate creating the junction...maybe that's the right move? I'm also not sure how these would interact with github actions. I think maybe we pass the current build configuration into the postbuild script and have it do different things? Another thing I'm interested in figuring out is how to have one source of truth for the version information. Maybe that's a text file that generates the .version and AssemblyInfo.cs files; maybe the .version file should be the source of truth and other things parse it? |
|
maybe this stuff is maybe even a better path? more cross-platform? https://learn.microsoft.com/en-us/visualstudio/msbuild/how-to-extend-the-visual-studio-build-process?view=vs-2022 |
|
I've been working on some stuff here that we should probably integrate: https://github.com/kspmoddingLibs/kspbuildTools/ |
Just tidying up. I think this makes sense given what you recently changed?