Right now, the release process involves manual steps to create the deliverables package offline and then upload it.
This can be integrated directly into GitHub as a new pipeline.
Describe the solution you would like
Ideally, the release of a new OSI version is nothing more than the press of a button.
Since there are more steps involved, the first improvement over the current process will be to automate the step of creating a new deliverables package.
The proposed solution is to convert the release steps from the (ASAM-internal) local build repository and apply them as a GitHub pipeline.
The pipeline is to run both for full and pre-releases.
This way, release candidates can be shared with decision makers, thus utilizing the automated build process.
Describe alternatives you have considered
The manual steps could be kept, of course.
Alternatively, an independent repository (such as the generator or a new one) could be responsible for handling these steps.
However, they do not seem as elegant.
Describe the backwards compatibility
This only impacts the build and release steps and, therefore, does not impact the backwards compatibility of its content whatsoever.
Describe the feature
Right now, the release process involves manual steps to create the deliverables package offline and then upload it. This can be integrated directly into GitHub as a new pipeline.
Describe the solution you would like
Ideally, the release of a new OSI version is nothing more than the press of a button. Since there are more steps involved, the first improvement over the current process will be to automate the step of creating a new deliverables package. The proposed solution is to convert the release steps from the (ASAM-internal) local build repository and apply them as a GitHub pipeline.
The pipeline is to run both for full and pre-releases. This way, release candidates can be shared with decision makers, thus utilizing the automated build process.
Describe alternatives you have considered
The manual steps could be kept, of course. Alternatively, an independent repository (such as the generator or a new one) could be responsible for handling these steps. However, they do not seem as elegant.
Describe the backwards compatibility
This only impacts the build and release steps and, therefore, does not impact the backwards compatibility of its content whatsoever.