-
Notifications
You must be signed in to change notification settings - Fork 36
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
Proposal: Aligning the build/run protocol among platforms #36
Comments
Good idea. One suggestion: At build time you use two paths off of the root (/build and /app). I did the same in my C++ Dockerfile (/source and /build) but now I am regretting it. It makes it inconvenient to test the build script without docker. Instead we could use two subdirectories, e.g. /app/build and /app/run. If the build script does things like "cp some_file ../run" it will work outside of docker as well. Also, files that only need to exist in the run directory, like run.sh or a pre-built binary, can be placed there in the repository and not need to be copied by the build script at all. For example:
And with a single image:
|
Brilliant idea! Can I ask any one of you to rewrite a single platform of your choice to @jeremysawicki's second option (single image)? We'll verify that everything works fine: that it's comfortable for you as the developers and doesn't break our submission system. Then I'll try to align all the other platforms. |
So is there no longer a concern about keeping run images small, as you previously expressed (#8 (comment))? Or you've decided to sacrifice size for simplicity? Sure, I can work on updating C++. |
Simplicity is a strong argument, yes. I think we can handle a limited amount of large base images in our submission system. |
I really like @jeremysawicki's proposal. I agree that it's great to do everything under the checkout directory to simplify local verification process. And given that @beevee is fine with the second approach to reuse build images as run images, resulting I have very minor revision proposal: what do you think about placing So
And finally, it's great if @jeremysawicki could work on applying this idea to the |
On second thought, I feel like moving In the end,
|
Yes, I was about to agree with you about Here is an example of how
If someone wants to put output files in a separate directory, they can. If someone wants to put their source code at the top level and avoid the need to We do have to choose how to structure the starter kits, though. Should we put the code at the top level or in a subdirectory? If a subdirectory, should it be called |
I strongly prefer leaving this application in a subdirectory (/app). A team can store lots of auxiliary stuff in this repo, and I’d like to keep it separate from the application. I’m also not sure about make. Less people are familiar with make than with simple bash scripts. Make can complicate things for beginners. |
Regarding the
It is starting to sound like a good idea to isolate everything in the
Also it makes Regarding |
I imagine that team's repository may contain multiple applications. One of them being the submission, other some helpful auxilliary apps for development. These applications may have some common libraries. Resulting directory structure can look like this:
That's why I think we should copy everything and let teams do whatever they want. But keep |
But copying everything will probably make submissions quite large, since teams can and will store various massive binary files in their repos... Now I'm confused. |
OK, let's go with a single image and copy everything. |
I made some changes to dockerfiles and starterkit-cpp
Please @nya3jp and @jeremysawicki review this changes, I'm not a cpp developer at all ) |
@jeremysawicki: Thanks for updating the cpp platform! @spaceorc: Renaming the root directory to I will make PRs for some platforms I'm familiar with. |
@spaceorc: I don't have a strong opinion about either of these changes.
Yes, I thought /app/app was bit strange as well, so this is good.
Personally I would not have made this change as it adds a small incremental complexity, but I don't think it matters much either way. I think most teams will use their own build system that they are comfortable with. |
Done all the remaining platforms. |
As initially proposed in #11, some platforms now support customizing the build/run process with participant-supplied shell scripts (e.g. #21). But other platforms don't.
To avoid confusing participants, I propose to align the build/run protocol among all platforms. In other words, all
Dockerfile
in this repository should be identical except for the base image reference (e.g.icfpcontest2020/python
).I imagine that such
Dockerfile
would be like this:Also, if we're fine with reusing build-time images as run-time images,
Dockerfile
can be simplied to something like the following. Actually this looks better to me, unless it has big implication to the evaluation infrastructure, because the difference of build-time dependencies and run-time dependencies is often tricky and hard to debug.The text was updated successfully, but these errors were encountered: