Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added Docker Support 🐳 #11

Merged
merged 9 commits into from
Oct 15, 2023
Merged

Added Docker Support 🐳 #11

merged 9 commits into from
Oct 15, 2023

Conversation

WillFantom
Copy link
Contributor

Added Docker support in the form a Dockerfile and additions to the release workflow.


Added a pretty basic Dockerfile to the repo and some documentation on how to run the docker version into the README. The resulting image is pretty small and seems to work on an x86 thinkpad and a m1 macbook, so imma just assume it's not too borked.


The CI pipeline will build and push with the rest of the release workflow. Seems fine but is a little ugly since I added the bool input for latest... perhaps the release workflow should run when a tag is pushed/forced and latest set to auto?

README.md Outdated Show resolved Hide resolved
@GeopJr
Copy link
Owner

GeopJr commented Oct 12, 2023

Thanks for this PR!

I appreciate the gesture but honestly I'm unsure if it's needed. The only build dependency is crystal and the releases are already statically linked. I'm not opposed to it but it does feel like an overkill. If it's difficult to run on M1 I believe homebrew has arm builds for crystal

Either way, ideally, it should move into its own action that runs on release (https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#release) since the release workflow only creates a draft (on purpose, so I write the changelog & do last second testing)

Dockerfile Outdated Show resolved Hide resolved
Switched the docker image build/publish pipeline event to a push event
on either a `v*` tag or to the main branch.
@WillFantom
Copy link
Contributor Author

I appreciate the gesture but honestly I'm unsure if it's needed. The only build dependency is crystal and the releases are already statically linked. I'm not opposed to it but it does feel like an overkill. If it's difficult to run on M1 I believe homebrew has arm builds for crystal

Hey, for me at least its more for package mgmt reasons... There's something nice about running a cmd that'll do the install as and when needed (and knowing a docker system prune -a will be a nice cleanup now and then)

+ It's not all that much extra to maintain I guess? (that said, keeping make in the build stage does kinda make it even easier to maintain)

Happy to make more changes though if can move towards a merge

@GeopJr
Copy link
Owner

GeopJr commented Oct 15, 2023

I'll move forward with it, thanks!

@GeopJr GeopJr merged commit c3b1707 into GeopJr:main Oct 15, 2023
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants