Create a workflow to test and build the API-dummy image on github elifesciences/issues#9006

[scottaubrey]

elifesciences/issues#9006

[scottaubrey]

This is a very invasive replacement. It would mean needing to update all the downstream dependencies at once - doable, but needs some time an coordination. Blocking #259

[giorgiosironi]

Why does it need to atomically affect all downstream dependencies? For example, journal uses a pinned image tag so it should not see any change if this just published new images at new tags named after a commit sha.
It would still remain possible to update the version used in journal manually, by editing the .env file, if needed in development.

[scottaubrey]

Why does it need to atomically affect all downstream dependencies? For example, journal uses a pinned image tag so it should not see any change if this just published new images at new tags named after a commit sha. It would still remain possible to update the version used in journal manually, by editing the .env file, if needed in development.

Yup true. I was thinking about the automated update pipelines in Jenkins downstream, because the way I went about doing this is so invasive that I didn't keep the jenkins pipelines working. It would mean dismantling those connections, though nothing would break the the immediate, I would want to tidy up after myself so to speak.

Equally, it is just work, but not easy to just "merge" when reviewed and OK.

[giorgiosironi]

Noticing the Jenkinsfile deploys to a api-dummy--demo environment though, that would need to be retired (or redeployed somewhere else is still useful).

Will join the infrastructure team stand-up today to coordinate with the application development going on in journal and api-dummy.

[scottaubrey]

This PR should now:

• continue to build and test on Jenkins and publish the result to docker hub, finally deploying to demo
• build and test on github actions workflow and publish the result to github container repository.

[giorgiosironi]

This is the only task I run into problems with, perhaps a Linux file ownership issue:

[16:23:06][giorgio@Arconia:~/code/api-dummy]$ docker compose run app ./bin/import 92110
WARN[0000] /home/giorgio/code/api-dummy/docker-compose.yml: the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion 
WARN[0000] Found orphan containers ([api-dummy-app-run-6f44d91c5293 api-dummy-composer-run-1984308df2a2 api-dummy-composer-run-73e461503125]) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up. 
[+] Creating 1/0
 ✔ Container api-dummy-composer-1  Created                                                                                                        0.0s 
[+] Running 1/1
 ✔ Container api-dummy-composer-1  Started                                                                                                        0.2s 
PHP Fatal error:  Uncaught Symfony\Component\Filesystem\Exception\IOException: Failed to touch "/srv/api-dummy/bin/../data/articles/92110.json". in /srv/api-dummy/vendor/symfony/filesystem/Filesystem.php:150
Stack trace:
#0 /srv/api-dummy/bin/import(66): Symfony\Component\Filesystem\Filesystem->touch('/srv/api-dummy/...')
#1 {main}
  thrown in /srv/api-dummy/vendor/symfony/filesystem/Filesystem.php on line 150

[giorgiosironi]

./bin/import 09560 remains available as a workaround.

[giorgiosironi]

Tested the rest of the README on Linux.

[scottaubrey]

TYVM