You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently there is no coupling between the repo state and the GitHub Releases. The GitHub releases however are the single source of code used in the quickstart-guide. In order to get a coupling between the repo and the releases we need some automation that creates GitHub Releases from the state of the repo.
<fill in standard arguments for automation here>
The text was updated successfully, but these errors were encountered:
The first iteration that came to my mind is the following: A script located in hack/ which needs to be executed in providers/x/y/z where x is the provider, y is the clusterstack name and z is the kubernetes version.
The next step is to check whether the worktree in that subdirectory is clean and up-to-date with the upstream main branch (at least the files that will be used as assets). The release version is then read from the metadata.yaml file in that directory. With that release number the script should attempt to create a new Github-release. If it is possible it should append the metadata.yaml the node-images.yaml and the zipped version of the cluster-class and the cluster-addons.
Currently there is no coupling between the repo state and the GitHub Releases. The GitHub releases however are the single source of code used in the quickstart-guide. In order to get a coupling between the repo and the releases we need some automation that creates GitHub Releases from the state of the repo.
<fill in standard arguments for automation here>
The text was updated successfully, but these errors were encountered: