Add a build workflow that replaces the build.sh in the pipeline

[FieteO]

Currently the build.sh is called in the pipeline as part of the generate-release workflow.
It looks like as if a failure in the script is not recognized in the pipeline (as can be seen in this pipeline run).

To better use the capabilities of github pipelines and to better distinguish the individual steps that may fail, this introduces a build workflow that runs for pull_requests and that is not using the build.sh.

Note: This is currently a draft since I can only test the functionality when creating the pull request.

[FieteO]

Doing an npm install in the pipeline fails because of issues with the Leaflet.Heightgraph package that is used in the graphhopper-maps submodule:

npm ERR! Error while executing:
npm ERR! /usr/bin/git ls-remote -h -t ssh://git@github.com/easbar/Leaflet.Heightgraph.git
npm ERR! 
npm ERR! Warning: Permanently added the RSA host key for IP address '140.82.114.3' to the list of known hosts.
npm ERR! git@github.com: Permission denied (publickey).
npm ERR! fatal: Could not read from remote repository.
npm ERR! 
npm ERR! Please make sure you have the correct access rights
npm ERR! and the repository exists.
npm ERR! 
npm ERR! exited with error code: 128

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/runner/.npm/_logs/2022-02-15T21_42_49_885Z-debug.log

The dependency version is defined as:

    "dependencies": {
        "leaflet.heightgraph": "github:easbar/Leaflet.Heightgraph#82cff7b3013dd73d7221521c5b404ded6439e050",
    },

in the package.json of graphhopper-maps.

I have then tried to replace the defined heightgraph version with the official npm registry version of the package and the pipeline gets further.

I have also noticed that the master branch has a different version defined for that package. Could it be that the navi branch just did not yet receive a necessary update in this regard?

[karussell]

Thanks for your work here.

Regarding the latest problem, see also graphhopper/graphhopper-maps#85 it was related to some npm / node version stuff (I'm not really proficient at this). We had similar issues here: graphhopper/graphhopper-maps#158 + graphhopper/graphhopper-maps#148

Could it be that the navi branch just did not yet receive a necessary update in this regard?

Yes. The navi branch is currently still set to the version before the major change from Mapbox GL JS to Openlayers. As openlayers has suboptimal performance for vector tiles and I have not yet tried how raster tiles look&work for the navigation. Also we would need this plugin.

[FieteO]

I was able to resolve the issues by reverting to the original package-lock.json and using node 16 in the pipeline. To make the pipeline pass, I had to also reintroduce (the previously removed) jcenter() since org.apache.cordova:framework:7.0.0 is not on maven central.

[karussell]

Thanks!

@boldtrn can we remove build.sh or should we keep it for local development?

[boldtrn]

thanks for the improvement @FieteO 👍

can we remove build.sh or should we keep it for local development?

Personally I'd like to keep the build.sh for now, as it makes development easier.

[boldtrn]

LGTM, thanks!

[FieteO]

Thanks!

@boldtrn can we remove build.sh or should we keep it for local development?

I think there is a redundant npm install in the build.sh by the way. Pipeline-wise I left it that out and it's working.

[boldtrn]

I think there is a redundant npm install in the build.sh by the way. Pipeline-wise I left it that out and it's working.

Why is that not needed? We need the node_modules of GHMaps to build GHMaps. We need to do this before we build the graphhopper-maps-capacitor.

The way I understood it is that with using cache-dependency-path, you are adding the package-lock.json to npm install, so it is essentially installing both package jsons?

Did I misunderstand the meaning of this? Because I think we need both installs.