Dockerfile with GitHub actions #373
Conversation
|
@steveicarus is there any reason this should not be merged. Do we need more information regarding exactly what this is doing/how it will be used? @martinwhitaker do you have any comments? This all seems reasonable, but I must admit I've not looked at Docker much. |
|
And a question for @Thirsty2 what is your intention for having a containerized version of Icarus? I can think of some, but would appreciate understanding your perspective as well. |
|
The primary use case is for build automation.
Doug
…Sent from my iPhone
On Jan 9, 2021, at 09:04, Cary R. ***@***.***> wrote:
And a question for @Thirsty2 what is your intention for having a containerized version of Icarus? I can think of some, but would appreciate understanding your perspective as well.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
I assume this is build automation for you (e.g in an academic/learning setting someone would build a container and then that could be used by all students with no system, version, etc issues). |
|
I don't have any objections to this, but I don't understand the need to include it either. |
|
Yes Martin, that's basically where I am. I can see where this could be useful for the case I mentioned earlier and maybe there are others I've not thought of. I will admit my vision is likely clouded by years of building a huge number of tools from source so all this has mostly become second nature to me. To me the biggest issue preventing me from saying this is a no brainier is you would like to have GTKWave available, but from what I read GUI programs are not really supported. |
|
We could easily add GTKWave to the dockerfile, but I personally prefer to
keep them separate. I have GTKWave running in a Docker container, and it
works very well. I am happy to provide a dockerfile for that if you want
to try it.
As you mentioned, another great use case is students, or anyone that wants
to try iverilog without having to install it or compile it themselves.
Perhaps someone has a tried and true version of iverilog and they are
nervous about updating it. Trying it under a Docker container allows them
to make sure nothing breaks for their use case before they take the plunge
of updating. Likewise, they can try an older version that they knew worked
for them in a container if they are seeing some odd behavior after
updating. Not that this ever happens with iverilog, but in general the
ability to run different versions of software with no worry about conflicts
is a nice thing for troubleshooting.
Another good reason to have a dockerfile is that it acts as an executable
version of documentation that makes the dependencies and the process to
build iverilog very plain.
Merging this change would be very low risk, as it doesn't affect the
iverilog code in any way.
Doug
…On Sat, Jan 9, 2021 at 2:51 PM Cary R. ***@***.***> wrote:
Yes Martin, that's basically where I am. I can see where this could be
useful for the case I mentioned earlier and maybe there are others I've not
thought of. I will admit my vision is likely clouded by years of building a
huge number of tools from source so all this has mostly become second
nature to me.
To me the biggest issue preventing me from saying this is a no brainier is
you would like to have GTKWave available, but from what I read GUI programs
are not really supported.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#373 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKLL7C5LWEBGFYFM2ZWNLDSZDMYRANCNFSM4SDNEQKQ>
.
|
|
I think the Dockerfile files are OK as a source of build documentation, if nothing else. They are harmless. However, I wonder if the deploy action would eat into our free action compute time budget. The CI actions are already time consuming. do we really want to include docker build and deploys with all the other build actions? |
|
I believe the deploy should certainly not be part of the normal CI. For stable it should only be for an actual release, for devel maybe quarterly or monthly or maybe never. Is there a different pool that can be used for the docker build as compared to our existing CI? |
|
Hi Doug, I assume this is just the recipe for building containers and there is no risk of this creating extra load where it builds every time we push a change. Once you confirm I will merge this. |
|
As it is now, it would build and test the container with every push to
master. See line 7 of the docker-publish.yml file. If you merge this and
build it once, then remove line 7 (and you may as well remove 8 as well
since you won't have that branch) then it won't build with every push. It
will still build with each tagged release (lines 11 and 12.)
It is not too difficult to add the ability for you (or someone with admin
access to the repo) to build on demand by pushing a button. I can show you
how to do this if you like.
Doug
…On Sun, Jan 10, 2021 at 7:39 PM Cary R. ***@***.***> wrote:
Hi Doug, I assume this is just the recipe for building containers and
there is no risk of this creating extra load where it builds every time we
push a change. Once you confirm I will merge this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#373 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKLL7DK6KOXC44OXBWTB53SZJXGNANCNFSM4SDNEQKQ>
.
|
steveicarus
force-pushed
the
master
branch
8 times, most recently
from
c698c31 to
fa85cc7
Compare
steveicarus
force-pushed
the
master
branch
7 times, most recently
from
9728397 to
0dc8596
Compare
|
This would be great to get integrated into the project! |
This Dockerfile and associated github actions builds an image based on Alpine Linux 3.12. The docker build executes regression tests automatically, and publishes the container image as a github package if the build and tests succeed.