Who on their right mind uses ssh/scp on Windows development other than connecting to UNIX boxes?
Experienced Windows devs I talked to said they used Packer from Hashicorp to entirely recreate their server image whenever they wanted to deploy. This process takes hours, but that was the best I found.
Exactly. That's like complaining that I can't RDP into a linux box to install the toolchain!
iwr -useb get.scoop.sh | iex # install scoop
scoop install coreutils vim nano [...] # yay
But in my case I wanted to leave something small (and busybox.exe is that small) /portable - for others to use (without the requirement to install scoop).
It’s possible in file explorer via \\wsl$, but that is not always supported by applications so it’s not 100%.
Oh, hey, there's the C drive in WSL! ;)
ln -s /mnt/c/Users/Somejerk/Documents ~/documents
Oh, man, a shared documents folder!
Granted, access to those files is slow as dirt because of the Plan9 filesystem, and there are some weird bugs where a process sometimes loses access to $cwd if it's not a native wsl filesystem (also a Plan9 bug reported to MS over a year ago). But it's tolerable when interoperability is necessary.
It also facilitates using the same filesystem under multiple WSL instances.
I feel like there's a ton of innovation in the cloud/container CI/CD space, but next to nothing elsewhere. In fact, some of the innovations in CI/CD make things _more_ difficult for those of us developing in other environments (such as game development).
There's a lot of low hanging fruit for improving things elsewhere.
To me, its like they don't have branches (tons of new code not accessible in the game is released in a patch) and they don't have unit tests that catch bugs (a certain ability has 2 modes, with 2 different activation times. In the most recent patch, the activation times ended up the same) but it's possible that developing a game is far different than developing a SaaS product from a coding perspective. Or it could be that studio just has weird practices.
This is likely by choice, feature flags have a fair few advantages over feature branches and are generally far less of a pain point long term.
It's likely because of inertia. I don't work for EA, but the majority of games studios use Perforce for source control which has... awful support for branches. They've got streams which are a huge improvement, but still nowhere near as flexible or easy to use as branches in git.
Client side encryption is basically impossible; the decryption key has to be in the executable you ship somewhere, or at least sent to the client after a connection with the server. Perhaps some encryption tiering system could work to keep unreleased locked content locked for longer but I don’t think anyone has gone through that trouble yet.
It's made me super grateful to be where I am now, and able to even view tools like this as an option.
It doesn't seem too hard.
https://docs.microsoft.com/en-us/windows-hardware/drivers/do...
Show me how to use this with GitHub actions, if it’s not too hard.
Depending on your requirements/scale the runner(s) can be a VM in your main machine, a cheapo dedicated server (hetzner/ovh) or even autoscaled hotspot instances in your preferred cloud.
It is less pure than using GH's runners and having an end-to-end setup/teardown for your whole toolchain, but it would work just fine. Definitely better than without any CI.
If you deal with proprietary toolchains that are tens of gigabytes (Windows WDK, Xilinx Vivado/Vitis) it’s just untenable, and that’s before even mentioning licensing. Even Azure doesn’t have a great solution for WDK development. It’s hard to feel like we’re not being left behind.
Bind mounting the tools into the container is an option but at that point you’re using the container just because that’s what your CI expects, not because it’s any better or more reproducible than a raw Jenkins shell script.