update git workflows and dockerfile
changes in this commit
-
include the .git folder in the docker build stage, so we can get the git version inside the build stage.
-
add an argument to the dockerfile to control the built release name
-
update the nuget workflow so it will only run on release, and not on push to master. this is to prevent updating the nuget when doing breaking changes to the plugin abstractions. the nuget package should only be updated when shoko server gets a version bump. if we want hotfixes then we can create a new manual workflow for the nuget package or allow it to be ran manually.
-
update the cli* and tray* workflows to also run on release, attaching the files in a zip with the release. this is to make it easier to download release zips from github for all users.
-
the release channel is used for web ui to determine if it should show the update modal, if the release channel is anything other than 'latest' or 'daily' then it can skip checking for a version update. the default channel when built from source is 'none' to prevent the check while developing.
Do feel free to suggest changes and/or fixes. I haven't tested the actions yet since i don't know how to test them beforehand.
I've tested the docker build locally though.
Are you able to provide image sizes of the different builds locally?
Alternatively, we could just keep the .dockerignore the same and use the env GITHUB_SHA
see: https://docs.github.com/en/actions/learn-github-actions/environment-variables#default-environment-variables
The workflows are still untested. Will see if i can manage to test them tomorrow... I don't have enough time right now to do it.
Further investigation /p:Version={VersionNumber} might work better, if we can get rid of the shared assembly info
Personally I find the SharedAssemblyInfo.cs useful for programmatically modifying the assembly info. But if anyone have a better way to do it (it -> add a release channel and git sha digest to automated builds), then by all means, do tell.
Also do note that this PR have nothing to do with automated build numbers/version-changes. That will happen in another PR (if I'm the one doing it) since I don't want to delay this PR any longer.
I'm not sure if sed will work on the windows builds. We'll find out, I guess
So I need to fix the sed usage on windows and maybe the Compress-Archive usage on linux.
Removed sed.
Also, the Compress-Archive cmdlet is available in linux.
I need to find a better way to get the previous tag... the current action module (or whatever it's called) it uses only grabs the last tag... which is not ideal when we have tags for both the server and the plugin abstractions in the same repo, also they won't conform to the required version format if they have a prefix (e.g. "v", etc.)..
I think it's ready.
It was not ready. Also, managed to actually test some aspects of the workflows locally. Will unmark it as a draft when I fix it... again.
I've tested all I could manage locally.