Automate core gafferpy maintenance with fishbowl

[t92549]

Fishbowl was integrated as a sub-module to gafferpy in gchq/Gaffer#981. It is now used to generate the core api of gafferpy, but this must be done manually after every Gaffer release and before every gaffer-tools release.

To use fishbowl to generate every supported Gaffer Operation, the spring-rest api must be used. This is because it contains every store on its classpath and has an extra endpoint to get details of those Operations, even if they aren't supported by the current running store.
However, there is no simple way to get Gaffer's spring-rest running within the gaffer-tools repository.

The gaffer-rest docker image could be used, but right now this is built in the gaffer-docker release stage. This happens after a gaffer-tools release, as it relies on the new release of the ui, so there is a dependency order issue.
If we decided to build an image as part of a Gaffer release, then perhaps this could be used. This has been proposed in gchq/gaffer-docker#310.

[GCHQDeveloper314]

Wouldn't it be possible to start the spring-rest in a similar way to how the existing Python and Selenium tests start the road-traffic example at the moment?

gaffer-tools/.github/workflows/continuous-integration.yaml

Lines 63 to 66 in 45f5fd1

	- name: Start road-traffic example
	run: |
	./ui/example/road-traffic/scripts/start.sh &
	sleep 1m

The spring-rest can be started in a similar way by using the -exec jar. As we don't need any data for this, it wouldn't need any config files or scripts and could simply be run as a java command directly from the workflow step.

Do you envisage this happening as part of the update-gaffer-version workflow? So long as the new Gaffer has been released and the jars are on central, it will be possible to pull down the latest spring, run it, then run fishbowl, and take the resulting generated code and add that into the PR which is generated for updating the Gaffer version.

[t92549]

I was indeed thinking it would be best placed in the update-gaffer-version workflow.
The mvn script cannot be used in the same way though.

You're right that it could find the correct jar from maven central and pull that down before running it with java.
Alternatively we could release the spring-rest jar as a release artifact in Gaffer.

[t92549]

Closed by #1033