Replace Legacy .zip packaging with the new DualityTemplates .zip packaging

[ilexp]

Summary

Right now, the NightlyBuilder will pack a binary .zip that will no longer be usable with the v4.0 pre-release. It will show up as a CI artifact and could otherwise confuse any future maintainers or users. This can be fixed by replacing it with the new DualityTemplates .zip that is generated on build.

Analysis

• Remove all legacy .zip code from NightlyBuilder, e.g. this block, this block and all related config variables.
• Remove the legacy AdditionalFiles folder and related config entries, and some more. This will leave the nightly builder with only build, test, .chm docs and package steps remaining as-is.
• Update the CI artifact path for the template download .zip to point to the new template .zip - or adjust the output path of the templates project to match it.

Simplifying NightlyBuilder as outlined above will also make it a little easier to talk about retiring NightlyBuilder altogether because there's less moving parts left to identify for replacement.

[ilexp]

Pinging @Barsonax for awareness.

[Barsonax]

Will look into this the coming week

[Barsonax]

@ilexp I see this comment in the appveyor.yml:

# The following lines trigger a complete NuGet Package and Binary Release build.
# They do not attempt to deploy them - it's just a build, made available through artifacts.
# The reason why it's inactive is that releases are in fact a relatively rare thing,
# while AppVeyor runs on each commit. It's probably for the best to not accumulate 6 - 11 MB
# of disk space in the AppVeyor VM on each commit, never to go away because of build history.

My understanding is that every build uses a fresh instance of the VM so this should be a non issue for the VM. Artifacts are not stored in the VM but somewhere else.

After a while (~6 months?) appveyor will cleanup old artifacts as well: https://www.appveyor.com/docs/packaging-artifacts/#artifacts-retention-policy. In fact if you don't want this then you are responsible for uploading them to a external storage.

So I think you can just leave that part active. It also makes it easier to see whats in the artifacts of a certain build if we want to.

[ilexp]

My understanding is that every build uses a fresh instance of the VM so this should be a non issue for the VM. Artifacts are not stored in the VM but somewhere else.

After a while (~6 months?) appveyor will cleanup old artifacts as well:

Ah, that's great info 👍

---

It also says this though:

Artifacts storage within AppVeyor is more properly regarded as an intermediary step in the deployment process, rather than an archival storage solution.

Which sounds like we might not be supposed to produce artifacts if there is no intent for deployment? Then again, maybe I'm reading this too strict here, and not accumulating indefinitely is a good start.

If we have six months worth of commits with maybe around one per day, and around 10 MB of artifacts per build, they would end up with ~2GB of data storage for artifacts only. I have honestly no idea if that's nothing or a lot these days - but they host that stuff without charging us, so there's that 😁

I'd probably just try to keep avoiding unused artifacts as long as we're not impaired by doing that, or missing out on some reasonably good opportunity. Unless I'm totally off here and a few GB of storage is nothing to worry about at all.

[Barsonax]

Its not meant for archival purposes because they clean it after 6 months :).

I believe the max artifact storage capacity is around 50GB (in case its not enough they are even willing to increase) so we would need alot of builds happening in 6 months to fill this up. Probably still best to just put a branch condition on it (only master/release) but commenting it out shouldn't be necessary.

I never ran into problems with this as most CI's auto clean after a while. Just don't assume the files are there forever.

Some advantages:

• Always/more often running the packaging/artifacts steps means they are being tested more often thus less prone to silently breaking.
• Easier to see what artifacts a build is gonna produce before releasing it.

EDIT: Its about 13MB per build (the duality zip is now alot smaller since it no longer has binaries) with 50GB that means we need to have almost 4000 builds happening within 6 months. Considering that duality doesnt even have that much commits during its entire history I don't think we will ever reach that much so might as well just publish artifacts on every build. https://ci.appveyor.com/project/AdamsLairBot/duality/builds/33459842/artifacts