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.

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!

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

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?

• 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

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

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.

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