Vpk download should allow non-existent releases.channel.json

[andersforsgren]

Scenario: a CI build script would often have these steps in some shell snippet to build and deploy a release.

vpk download -c channelname ...
vpk pack  ...
vpk upload -c channelname ...

This works well, except for the initial release where there is no json file present. In the case of a http download, the 404 will be an exception, which leads too a nonzero exit code of vpk.

possible workarounds

1. ignoring errors in vpk download.

This is often not desirable because other errors such as a 500 http response should be a failure.

2. hand-crafting an initial releases.channel.json with no assets

This works and sorts the problem, but the json needs to be valid e.g. { "Assets": [] }, not merely an empty file.

I suggest that all IUpdateSource implementations should return an empty VelopackAssetFeed in case there is no feed found for the channel. In the case of http that would be in case of a 404, for a local source that's a FileNotFound and so on.

This was a Q on discord
https://discord.com/channels/767856501477343282/767856501477343286/1231899380353597524

Edit: The suggested fix is a bit complicated in an upgrade scenario: in case of the default channel, having a "RELEASES" file, but no "releases.win.json" is currently a 404 for vpk download, but in that case assuming an empty VelopackAssetFeed is incorrect. There are assets they're just in another file...

[Trinitek]

I would like to reserve the option to have a HTTP 404 response result in a non-successful exit code. If I expect the channel to exist and it doesn't, that should be an error.

Here's a third workaround: I've modified my Azure DevOps build pipeline to accept a parameter so I can disable the download step:

I'm currently working on migrating away from Squirrel.Windows and onto Velopack, so I only have RELEASES and no releases.win.json feed. During testing, this is working well for me.

[andersforsgren]

Yes this might be an edge case but it’s horrible to work with CI scripts if you have lots of channels or create new channels regularly. E.g if you do a channel per major version. Even with just the common stable/beta channels it’s two sets of options.

But it becomes harder to design this if 404 should error. The only way would be an option for vpk download to “allow missing” but it doesn’t feel very elegant.

[Trinitek]

Okay, that makes sense. I purposely trigger all my releases manually so I wasn't following.

In the absence of a --allowMissingChannel (or similar) flag, how would I re-add the assertion that the channel exists? If I have to make a separate HTTP request, that's not going to be elegant either, and even worse if someone is using a private S3 or AzBlob instance with public HTTP access disabled, as the pipeline will have to pull additional CLI tools to talk to them.

Or should the flag be inverted? --ensureChannelExists

[andersforsgren]

The compatible way would be the --allowMissingChannel one, because any existing user would then keep failing on 404 so it's not a breaking change for anyone.

The question as always for a switch is whether it carries its own weight at all or if it's better to not add it at all and let users handle it by e.g. yaml options, local shell deploys or similar.