Parameterize image names so that other images tags can be easily built

[adepssimius]

Hey, being able to build and push this up from my own fork helps me test. I updated the workflow to set the image name based on the repo that it's from automatically, with an option to pass a custom image name. For instance my fork repo will build and push an adepssimius/jetlog image, while your repo will continue to build and push an pbogre/jetlog image.

[adepssimius]

oh, I realize now that you do actually use docker hub instead of ghcr. I assumed ghcr incorrectly since I had seen the failed pipelines and...I don't know what I was thinking haha. I'm happy to rework this to help you fix pipelines for incoming PRs also. LMK what you would like where. A ghcr AND docker workflow, maybe?

[pbogre]

Thank you so much for the PR which was much needed since the current CI/CD for pr's is very buggy.

I would like it to always use docker hub and ignore ghcr completely, while I see that it uses ghcr in the new version.

Just to clarify, can you confirm that this version will:

1. build and push to pbogre/jetlog:experimental on a push to main
2. only build on a pull request
3. build and push to pbogre/jetlog:latest AND pbogre/jetlog:X.X.X on release version X.X.X

Additionally, I'm confused about the purpose of this feature beside fixing the current CI/CD not working on PR's. What is the need for someone to be able to push the image into their own private version for testing purposes? Isn't it sufficient to just push to a remote image when changes are made to the main branch of Jetlog?

P.S.: sorry for the late replies but I am very busy in this period

[adepssimius]

Hey not a problem, life happens, then there's the projects you started haha.

Would you mind if I added the ability to do either docker hub or ghcr depending on which env vars are set? It's very simple for me to use ghcr for building and publishing development containers, which is why I prefer it. If you are on github, you can push to ghcr.