Actions on PR and tag

[jburel]

Add support for actions.
Build on windows and ubuntu on pull_request
When a tag is pushed, the artifacts will be uploaded to the GitHub tag (similar to downloads.o.org)
I have not removed the hard-coded version for this round
Token will need to set on the repo in order to push the tag

I have not removed the travis or appeyvor files
I have tested the workflow using on my account see https://github.com/jburel/bioformats/releases/tag/v6.6.0-m3 for example

cc @dgault

[manics]

Did you investigate any existing actions e.g. https://github.com/actions/create-release https://github.com/actions/upload-release-asset ?

[jburel]

@manics I have played with both of them, yes but opted for the solution put in place due to the steps required like creation of checksum etc.

[sbesson]

A few comments:

• 👍 for the Python 3 upgrade and the UpgradeChecker deprecation
• re Actions on PR and tag #3626 (comment), I am definitely in favor of using upstream organizational roles whenever possible. A limitation is that the GitHub actions syntax does not support for loops so I assume it would mean duplicating the action for each asset including checksums. Mid-term I would hope Add the ability to use wildcards for uploading files. actions/upload-release-asset#60 will allow us to use actions/upload-release-asset with a wildcard.
• most of the Travis CI workflow is now converted with the exception of the artifact deployment to Artifactory -

  bioformats/.travis.yml

  Lines 38 to 46 in c14984f

  	deploy:
  	provider: script
  	script: "cp .travis.settings.xml $HOME/.m2/settings.xml && mvn deploy"
  	skip_cleanup: true
  	on:
  	jdk: openjdk11
  	repo: ome/bioformats
  	branch: develop
  	tags: false

  . Is this in scope of this work
• the current workflow combines Ant and Maven as matrix components. An alternate representation could be to split them into two separate workflows: ant.xml and maven.xml. The main benefit of this approach is to be able to re-use the latter as the Maven commands are very generic. This can also be reviewed as a follow-up with other Maven-based Java libraries in mind.

[jburel]

I think:

• I will remove the "release" file since we may not want to push all artifacts to GH for next release
• split into ant and maven as suggested above

since we push over 10 artifacts and not having support for loop in actions, using upstream actions was making the file extremely long, and this chosen approach was not breaking if for example we decide to remove a jar. As indicated I will remove it for now and we can revisit when the deployment is in place.

[jburel]

closing this PR see #3635 for the build part of this work