[WIP] Try to reduce image size

[koppor]

Use rsync to speed up uploads.

Enable the "old" upload-script. The advantage of the script is to create symlinks to the latest files.

Current issue:

Connected to build-upload.jabref.org.
sftp> cd www/
sftp> mkdir change-upload-back-to-script
Couldn't create directory: Failure
sftp> cd change-upload-back-to-script
Couldn't canonicalize: No such file or directory

Google does not say something specific about "Failure". I was in the server, access rights are OK. Since the last working execution of the script, I security-updated the server software. Maybe, there was a change.

Alternative to fix the upload issues. Https://github.com/appleboy/scp-action (does not create symlinks, too; but tries the uploads more harder)

• Refs Download-Area: master-latest is missing #5398
• Refs Use Github Actions for deployment #5312 (providing reasons to switch to GitHub actions)
• Fixes Decrease size of distribution #5771

[Siedlerchr]

That sh script works also under windows?
if yes that's good

[tobiasdiez]

If the script does not want to work, then maybe it would be also an option to manually create the symlinks (since the file names only change after a release which is not that often).

[koppor]

I am not sure whether -p works on sftp

Furthermore, the parent directory exists.

We have three (!) parallel builds: windows, linux, mac. Each of that uploads to the SAME directory. Thus, the second and the third one cannot create the directory. cd works fine (see output)

The \n is a newline character. It separates the command on SFTP (=secure FTP). So, with your change, SPACEcd is executed instead of plain cd. Think, this is unintended?

[koppor]

Even though the sources are the same for the build, the binary files differ.

Total bytes sent: 1,562,723,021
Total bytes received: 1,018,290

sent 1,562,723,021 bytes  received 1,018,290 bytes  13,657,129.35 bytes/sec
total size is 2,647,503,235  speedup is 1.69

Some difference example:

  1064536  2019-12-19 23:32   JabRef/runtime/lib/jvm.lib      |   1064536  2019-12-20 01:14   JabRef/runtime/lib/jvm.lib
186273910  2019-12-19 23:32   JabRef/runtime/lib/modules      | 186273746  2019-12-20 01:14   JabRef/runtime/lib/modules

The timestamp differs (this is OK; first fie). However the modules also differ (second line). I wonder why the build is non-deterministic.

[tobiasdiez]

@koppor is this PR still required in view of #6711 ?

[koppor]

No, it is not. Thank you for linking