-
-
Notifications
You must be signed in to change notification settings - Fork 61
Update bootstrap scripts for supported operating systems for v3.9 #752
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
if is_rpm; then | ||
# Rocky Linux versions 8.x or 9.x | ||
MAJOR_VERSION=$(cut -d. -f1 <<<"$OS_VERSION_ID") | ||
if [[ ! "$MAJOR_VERSION" =~ ^[89] ]]; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ist2 bootstrap used for all versions, rather than being version specific.
So it has to support all the o/s versions that stackstorm support, as it's the common thread before it call the version specific bootstrap calls.
So as stackstorm 3.8 is still current, and unless dropped the usual premise as we support the last 2 stackstorm versions, it must still support all the o/s of 3.8 and 3.9.
So we can't drop redhat 7 yet from the list, and same for any Ubuntu's that 3.8 supports.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are quite right, this PR is intended for use with the st2 3.9 release. I'll mark it as draft so it won't be merged until the release process is started, which should be this week or the next.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's more than that. You still need to keep the o/s versions in here that 3.8 supports until stackstorm drops support for 3.8. As this file is the installer that is used for all supported stackstorm versions.
You will get the master version when you download the installer for ANY stackstorm versions. So it always has to keep the o/s versions of latest and previous version. It then itself downloads the relevant st2 bootstrap for the specific st2 version at the end of the file.
So you need to update it currently to support o/s versions and for 3.9 but not drop the 3.8/3.7 versions and then merge it.
After 3.9 is released you can then update and merge a change that removes any o/s that only 3.7 supports
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're correct in how things are but master
is the current dev branch and pulling from master to install the current release version of StackStorm is wrong.
We have branches for v3.8
/ v3.7
etc. so people should be using the correct URL to download the bootstrap script that is appropriate for the version of StackStorm they're attempting to install.
According to the docs, the url to install stackstorm is https://stackstorm.com/packages/install.sh which redirects to https://raw.githubusercontent.com/StackStorm/st2-packages/master/scripts/st2_bootstrap.sh (master
).
For convenience, this URL can be maintained, but it should point to the current stable St2 branch v3.8
and not master
. It does mean, it'd need to be bumped with each release.
As far as I can tell www.stackstorm.com is hosted via github-pages, but have yet to see how the redirection is configured.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am just pointing out how it works now. I agree it would be better to do what you say, but you will need to update the documents for old and new, and to update the e2e tests as well that use that link in the e2e runs if you want to do that.
So unless you do those changes first, then this has to be generic and cover all stackstorm versions.
It would also mean that any users who may have their own automations that use our current method would need to be given advance warning thay they can't use the same method as they currently use.
No description provided.