distributing/github-actions

[giscus[bot]]

distributing/github-actions

This section assumes you have a basic knowledge of GitHub Actions. You can learn more about

https://docs.velopack.io/distributing/github-actions

[BenMendel]

Is it possible to update the application using UpdateManager class when the repo is private?

[caesay]

You can pass an access token to your GithubSource constructor, but keep in mind that strings like API keys stored in your binary are easily retrievable, so the accessToken here is essentially public to everyone who has a copy of your program.

[lloydjatkinson]

Is it possible to work with existing releases created by other GitHub Actions? For example https://github.com/googleapis/release-please-action uses semantic versioning to create the Git tag, bump the version in .csproj/Directory.Build.props, create a GitHub release for that tag, and add an entry to CHANGELOG.md.

I'm imagining an action that is triggered upon a release being created by the above. So then the produced velopack files are added/uploaded to that release?

[Keboo]

Yea certainly would be possible. This is mostly a GitHub scripting thing and less a Velopack issue.

A solution might look something like this.
The key will be the triggers for running the GitHub actions, the most obvious choices would either be release trigger or even a direct workflow call. From there, it would be a simple matter of downloading the artifacts that are in the release (there are some third party actions to do this or you can use the GitHub CLI). After downloading it, you would then leverage vpk to build your new release assets and upload them to the existing release. For vpk you will want to pass the --merge option to vpk upload github to merge the new files with the existing release.