Closed JoelProminic closed 1 year ago
@MarkProminic noted that if we can confirm that the user selected the expected version of Nomad, we could exclude the variable overrides. In that case, we could handle the variables like this, where ::NOMAD_VARS::
could be replaced by any empty string or the above properties:
vars:
...
debug_all: true
::NOMAD_VARS::
In my opinion, this solution seems unnecessarily complicated. I think it is better to just always write the installer and version properties, like I showed above.
@MarkProminic @JoelProminic I have figure out on SHI what to change to apply installers picked up by the user. In order to test it I have changed locally my demo tasks 0.1.17 - everything worked nicely. Please check my properties based on screenshot. The question right now is where changes in demo-tasks should take place - should it be as part of next version 0.1.18 or still 0.1.17 ? I'm assuming all of these changes should be done by you Mark in your repository ?
List of files which has been changed locally:
Additionally I didn't bother about versions of each installer - what was hardcoded stays as it was. I'm not sure how to resolve problems with passing the right version, because user pickup file and there is no other option. I can of course read name of the files and try to extract version, but it won't be too perfect.
The next step would for me take care of Hotfix and Fixpack for Domino - I think I need to have more discussion with Mark what properties need to be updated, but this can be for the laters work.
@JoelProminic Correct me if I mis-remember our conversation from the other day, but like I mentioned in issue 77, I was going to take the current hosts.template.yml that is in SHI, and copy it over to my repo, and begin to fill out the "vars:" section, with the variables in the format below. I believe this is the preferred format you wanted this in:
vars:
...
debug_all: true
# change nomad version
nomadweb_archive: ::NOMAD_INSTALLER::
nomadweb_version: ::NOMAD_VERSION::
One question I have, is if I expose a new variable, ie a new Domino Project comes along, and I try something like this:
vars:
...
debug_all: true
# change nomad version
nomadweb_archive: ::NOMAD_INSTALLER::
nomadweb_version: ::NOMAD_VERSION::
# change domino project x
domprojx_archive: ::DOMPROJX_INSTALLER::
domprojx_version: ::DOMPROJX_VERSION::
Whether or not Haxe will have an issue with the interpolation of a undefined variable. If we can set that behavior to always write space or nothing, the default variables I define in the roles would takeover. So if someone can confirm that behavior and if its modifiable that will mean that there will be no need to manually transcribe new features and changes into Hosts.template.yml
For example, If we can make this into a variable/checksum map, we can know what version the user is using.
@piotrzarzycki21
You didn't need to modify the main.yml for all the defaults folder, you simply just needed to redefine/override them via the Hosts.yml.
So I would expect the section on the right of your screenshot, in the Hosts.yml, to work without having to modify any of the other defaults/main.yml files.
@piotrzarzycki21
You didn't need to modify the main.yml for all the defaults folder, you simply just needed to redefine/override them via the Hosts.yml.
So I would expect the section on the right of your screenshot, in the Hosts.yml, to work without having to modify any of the other defaults/main.yml files.
Understand. I don't have time test this, but I have run dev build - once it's ready it will contains my changes - if someone just modify Hosts.yml file manually at some point will be able to test whether it's working. I check that myself on Monday. Link to build if someone wanted to test.
@JoelProminic Correct me if I mis-remember our conversation from the other day, but like I mentioned in issue 77, I was going to take the current hosts.template.yml that is in SHI, and copy it over to my repo, and begin to fill out the "vars:" section, with the variables in the format below. I believe this is the preferred format you wanted this in:
vars: ... debug_all: true # change nomad version nomadweb_archive: ::NOMAD_INSTALLER:: nomadweb_version: ::NOMAD_VERSION::
One question I have, is if I expose a new variable, ie a new Domino Project comes along, and I try something like this:
vars: ... debug_all: true # change nomad version nomadweb_archive: ::NOMAD_INSTALLER:: nomadweb_version: ::NOMAD_VERSION:: # change domino project x domprojx_archive: ::DOMPROJX_INSTALLER:: domprojx_version: ::DOMPROJX_VERSION::
Whether or not Haxe will have an issue with the interpolation of a undefined variable. If we can set that behavior to always write space or nothing, the default variables I define in the roles would takeover. So if someone can confirm that behavior and if its modifiable that will mean that there will be no need to manually transcribe new features and changes into Hosts.template.yml
@MarkProminic If in Hosts.template.yml exists property which I didn't map here - In the end you will have this kind of entry in final Hosts.yml:
domprojx_version: ::DOMPROJX_VERSION::
I have just updated Hosts.template.yml with properties and it's working great with new development release build. I will continue to figure out how to fix fixpack for Domino.
@piotrzarzycki21
You didn't need to modify the main.yml for all the defaults folder, you simply just needed to redefine/override them via the Hosts.yml.
So I would expect the section on the right of your screenshot, in the Hosts.yml, to work without having to modify any of the other defaults/main.yml files.
I have just pushed changes to Hosts.template.yml file for demo tasks 0.1.17 - I will try to figure out changes on my sight to have working fixpack as well. Once I do that I suggest release version and start work on proper improvement of 0.1.18 and upgrade on my sight.
I did a test on Monday after renaming all of the installers:
mismatch_Domino_12.0.1_Linux_English.tar
mismatch_Domino_12.0.2_Linux_English.tar
mismatch_Domino_1202FP1_Linux.tar
mismatch_Domino_REST_API_V1_Installer.tar.gz
mismatch_HCL_Verse_3.0.0.zip
mismatch_Leap-1.0.5.zip
mismatch_Traveler_12.0.2_Linux_ML.tar.gz
mismatch_domino-appdev-pack-1.0.15.tgz
mismatch_nomad-server-1.0.8-for-domino-1202-linux.tgz
Everything installed without an error, which is a good sign. We could do a quick release for this, but we would like to add the Nomad Web 1.0.8 SHA to the recognized installer list (this is separate from the SHA-version mapping that we'll discuss separately).
This task is going to be continued as part of upgrade to newest demo-tasks -> https://github.com/Moonshine-IDE/Super.Human.Installer/issues/77
When we tried to test with a newer version of NomadWeb (1.0.8), we got a crash (#75) with error using the old version number (1.0.6):
This is because the installer name is hard-coded. This is then used when checking the installer locations (example).
We discussed this with @MarkProminic, and his intention was to allow this to be overridden in Hosts.yml. In order to do this, we need to set values for the above properties in the
vars
section. For example:The Haxe code would need to be updated to replace the new insertion parameters
::NOMAD_INSTALLER::
::NOMAD_VERSION::
. The installer name would be determined by the file selected by the user. The version would need to be parsed from the filename, defaulting to value like "UNKNOWN" if it can't be parsed. For the Nomad example, the version is only used in labels, so it doesn't matter. In theory we could need custom logic for different installer versions, though.Note that this same issue will likely trigger for the other user-provided installers, so we would need to update the template with the appropriate properties for each installer.