Closed JakubKoralewski closed 1 month ago
Hi Jakub. Thank you for proposing this change and for the time you put into it. I think it can make sense to extract this to a separate project (e.g. github-tdg
) and have github-tdg-action
to depend on it. I don't think I can accept this PR as as, as it is not backwards-compatible and will break workflows for some users (as you mentioned as well).
Not accepting this PR makes sense.
Could you go into detail how this upstream github-tdg solution should look like? Are you thinking a different repository?
I guess storing both composite action and Docker action in same repository is impossible, would make it simplest though.
If I use my fork as the root Github-tdg project, and then add PR to your project so that the Dockerfile downloads the built Go executable from my repo, then I worry about things like issues being in wrong repo and stars and such.
Would it be possible to make your repo on which we are discussing become this github-tdg root project, and a new repo become again the Dockerfile based action with the same name without breaking updating process? In this way the issues and stars would stay with the code and actual author (you), while the small Dockerfile wrapper would become the new project?
I'm not sure what's the best way. Feel free to copy my commit for whatever new project, and let me know if you're not interested in this and you'd like to assign this work to someone else, if so what the plan would look like.
I was attempting to cache Docker build of this project but couldn't get it to work. Instead I propose this solution.
I'm not sure if you want to use this, since probably breaking change as it stops compatibility for Linux (ARM), MacOS and Windows runners.
Tested on: https://github.com/JakubKoralewski/testing-tdg-action-no-docker