Install4j update system is working correctly. Marking this issue as closed.

May require around 5 hours effort for full testing and code review - many moving parts here.

Suggestions for how to test:

• Make an all-new fork for testing the bb pipeline build system. (Plz delete when done.)
• Configure it install repository instructions; validate that the instructions still work.
• Use your fork to check that each pipeline can run using your fork; make & push "dummy" branches to trigger each pipeline.
• Confirm that expected installers and files are copied to your Downloads section and can run.
• Read comments and instructions; check that they are understandable

In addition, we need to test that the Install4J update system is still working, since I have changed the installer names. Also, I have removed an environment variable - CODEBASE_URL - that did not seem to be used anywhere.

Suggestion for testing:

• Install 9.0.2 IGB on your system, run it, then shut it down.
• Set up a bioviz.org copy on your local or EC2, using the update XML file created by the release branch pipeline. As an example, see https://bioviz.org/igb/releases/current/ and files it contains.
• Copy the newly built installers on your bioviz copy.
• Modify your "hosts" file to "trick" your system into accessing your bioviz copy instead of the "real" bioviz.org.
• Launch IGB 9.0.2. The Install4J software will launch and try to access https://bioviz.org/igb/releases/current/updates.xml (the new one you built above)
• When it reads the new updates.xml, it will detect there is a new version of IGB available - 9.1.0 - and it will ask you (the user) if you want to update your IGB. (Say yes.)
• Download and run the new IGB.

Something to check: I am not sure why, but previously we had an environment variable:

• CODE_BASE_URL https://bioviz.org/igb/releases/current

that did not appear to be used anywhere. I removed it. However, I am worried that this environment variable was needed to tell installer software Install4J where to get notification that a new version was available.

To test this, increment the IGB version from 9.1.0 to 9.1.1 – on your fork. Deploy the newly created updates.xml and installers on your fake bioviz.

Check that your newly installed IGB version 9.1.0 gets updated to 9.1.1 as it should.

Branch:
https://bitbucket.org/aloraine/alorainefork/branch/IGBF-1193

• using mvn help plugin to get version
• will use mvn to get last commit hash; use in jar file name for default pipeline
• should make sure this works for when not interested in building installer

Note that the IGB version string (with underscores replacing period (.) characters0 through the script build_igb.sh.
This affects the installers.
I don't know why we need to replace underscores with periods. Maybe there is a reason?

Please follow up:

• find out: why do we need to use underscore characters in the names of the installers. For example, can we name the Windows installer IGB-windows-x64_$version.exe?

Things to check:

• updates.xml (http://bioviz.org/igb/releases/igb-9.0.2/updates.xml) is accessed by installed IGB version to determine if a new release is available. Check if "targetMediaFileId" in the XML is used by the installer software to link deployed IGB versions to updates.
• can windows computers handle file names with multiple periods in them? For example, is foo.9.0.1.exe recognized as a program?

Question: Why do I need to login to docker hub to run the docker image?

Need to modify the curl commands so that the version 9.1.0 is not hard-coded in the script.
Suggestion: maybe can use Unix "sed" command to substitute underscore character (_) for fullstop (.) character in file name?

Nice use of mvn in get_version.sh, btw!

To test this issue :
1. Install Docker on your machine; start Docker daemon
2. Open bitbucket-pipelines.yml file and notice the docker image name: ( lorainelab/igb-maven-install4j:jre-1.8.0_191 ). Pull this docker image using command docker pull lorainelab/igb-maven-install4j:jre-1.8.0_191
3. docker login
4. clone the repository
5. Open build_igb
6. Replace the bitbucket pipeline variables with actual values
7. Run each statement one by one on the docker terminal.