31209d905a7c96d7a35b2719f92a84fcfa038012
6eeb1f3b963a7a02cea144384b59e6133d02ade8
166eccd785a07a17a011d7bd0c3042f561e01614
99ca2654e65788c43c2cc309df3907720d5adef1
70d55307b4842dd165c5d413ef133dff16f01e45
42ec4e78dec41416bc4fd33246ee0cdb4d1c9940
61b08aabfe613d61509be584923344528292b855
I think these comments are leftover from developing, right?
I like this way of building in a container. How about run the container on the host? That way we can keep the base image cached there and don't have to re-download inside the Atomic Host for every test.
Yes, they will be remove when submitted to dist-git
This is also left over from debugging that will be remove as well
How about run the container on the host?
I'm not quite sure how we would do that.
With the standard role we have nothing to do to get in the image, so I'm not sure how I would get out of it. Any idea?
I don't think the test should download from upstreamfirst. This is part of the test itself and should be in the repo.
Agreed, that was the easiest solution for now, I was thinking to update this either to use dist-git or find another way to place the file in the container
Why not copy it into the mounted directory on the host? That way it'll be in /code for the container.
Might be as simple as that indeed :)
1 new commit added
FWIW wholeheartedly agree here. test-gc.c should be in tests/files/ and copied with the Dockerfile to the place where the container is built.
Ok, the tst-gc.c file is now made accessible in the docker container and the Dockerfile is really getting simplified :)
Imho, this is ready to be proposed upstream
Can we make a standard-test-dockerbuild role? This role would accept a directory with a Dockerfile, build it ... and optionally run the container with a given command.
Or how about a standard-test-gcc role ... that builds a C file ... andif on Atomic Host, does it via a docker container ... if on the main host does it directyl?
I prefer https://pagure.io/fedora-ci/AtomicCi/pull-request/7
If we do invest more time in this ... I suggest the playbook layout be similar to the PR#7 ... in that many tasks run on both ... and only certain tasks/blocks (or roles) are tagged.
Restructured :)
I don't think gather_facts or remote_user is necessary in the gc tests.
These tags aren't necessary. This task should apply to any tags.
Other than that ... looks ready.
fair
Not from my testing :s
I guess I was wrong about untagged stuff running under any tag.
should we just call this fedora:FEDORA_VERSION ?
if this is in the line above, that doesn't become longer than an earlier line I think
you could also split the args into separate lines if that's too long
I'm still not sure about building the container or just running the fedora container and installing the deps as part of the script
Can we rely on this? Or should we use an ansible module to get a temp dir and register that name? Either way, I think /tmp/gc_test/ (or the new temp) should be in a variable anyway.
/tmp/gc_test/
These comments should probably all be removed
I'd rather be specific to be sure of the source of the image
either way but in the end this is just personal prefs :)
Can we rely on this?
I don't see why not. What do you have in mind?
2 different approaches for the same outcome :)
Agreed, before being submitted upstream, I think we already mentioned that ;-)
Let's close this PR since it got opened upstream
Pull-Request has been closed by pingou