Этот файл содержит невидимые символы Юникода, которые могут быть отображены не так, как показано ниже. Если это намеренно, можете спокойно проигнорировать это предупреждение. Используйте кнопку Экранировать, чтобы показать скрытые символы.
Releases
Use a pipeline that is manually run to trigger a release. The pipeline creates a GitHub release (which implies creation of a tag) on the repo and we can upload assets to that release... While the repo is private the release assets will not be anonymously downloadable so we also upload to a storage account and comment in the release with the link to the file in the storage account. The release asset links should be considered canonical and the storage account links secondary.
PRs and CI
Release assets should be uploaded to just a storage account under version numbers that increment with the build so each link is unique and potentially easy to sort chronologically. Assets are linked in the PR in a comment after every push. Eventually we might want to clean up files for PRs after they merge/close.
CD (merge to main)
In these instances I'm thinking that we should release assets to storage to the same file name (released under the version .latest or something) and these URLs never change but the content is updated with each merge to main. These would be the bleeding edge so if main is broken then so are the contents of the .latest releases.
Удалить страницу
Удаление страницы вики «Release process» не может быть отменено. Продолжить?