#6 First pass on the gc tests
Closed by pingou. Opened by pingou.

no initial comment

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.

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

  • Have ansible install the tst-gc.c file and make it accessible in the container

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

1 new commit added

  • Use a block construct and sync the artifacts outside

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.

1 new commit added

  • Restructure the playbook to be more linear

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.

Not from my testing :s

1 new commit added

  • Drop couple of un-needed instructions

I guess I was wrong about untagged stuff running under any tag.

1 new commit added

  • Adjust/fix the tag situation

1 new commit added

  • Build the container locally, speeds things up quite a bit

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.

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