.github/workflows: use write-artifacts and prevent rebuild

[laurentsenta]

fixes #39

Use the write-artifacts option during the build.
With this option, Testground replaces the composition file with the one produced by the build step (template generation applied, build artifact set).

With this we:

• Never rebuild the containers, even on Docker cache miss,
• Can save the generated composition (templating applied) as a useful debug artifact

Tasks

• merge cmd/build: fix write-artifacts to correctly truncate & close the output testground/testground#1444
• drop the debug commit

[laurentsenta]

Will need to fix the option in Testground, it looks like we got a frankenfile: half input, half output.

...
    [groups.build_config.build_args]
      CARGO_FEATURES = "libp2pv0470"
  [groups.build]
  [groups.run]
    artifact = "73b08cb20924"
tTarget }}
        target = "{{ $.Env.GitTarget }}"
        {{ end }}

      [groups.build_config]
        path = "./go/"
        build_base_image = 'golang:{{ .GoVersion }}-buster'
        modfile = "{{ .Modfile }}"

      [groups.build_config.dockerfile_extensions]
        # deal with dependency changes in master until we create the new vx.y.z instance
        pre_build = """
          RUN cd ${PLAN_DIR} && \
              go mod download github.com/libp2p/go-libp2p && \
              go mod tidy -compat={{ .GoVersion }}
          """
  {{ end }}
  {{ end }}
  {{ end }}
{{ end }}

{{ with (load_resource "./rust.toml") }}
  {{ with (index .groups 0) }}
...

[laurentsenta]

I just experience another docker pull error during the install:

Run /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/testground/testground/master/install.sh)"
  /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/testground/testground/master/install.sh)"
  shell: /usr/bin/bash --noprofile --norc -e -o pipefail {0}
  env:
    TEST_PLAN_REPO: libp2p/test-plans
    TEST_PLAN_BRANCH: ecf4a84af35ae31ffc9fe2e0313ad3d7f97e9878
    TESTGROUND_ENDPOINT: 
    COMPOSITION_FILE: ping/_compositions/rust-cross-versions.toml
Error response from daemon: Get "https://registry-1.docker.io/v2/": EOF

adding back the retry during install.

I also bumped the build timeout because it creates noise in the long tests. Bear with me, we'll eventually drop this.

[laurentsenta]

@mxinden @marten-seemann @galargh I'm for the week but feel free to merge (it fixes #39)

• Stats will be in: https://github.com/laurentsenta/test-plans/actions?query=is%3Aqueued+branch%3Alaurent-statistics-0909-bis
• There should be no failure in https://github.com/laurentsenta/test-plans/actions?query=is%3Afailure+branch%3Alaurent-statistics-0909-bis maybe a couple of timeouts for the all tests.

[marten-seemann]

What does write-artifacts do? I googled it, but there seems to be little documentation about this flag?

Where are these artifacts saved? How large do we expect them to be? Where are they stored between builds?

[galargh]

What does write-artifacts do? I googled it, but there seems to be little documentation about this flag?

From https://docs.testground.ai/running-test-plans#building-a-composition and https://docs.testground.ai/concepts-and-architecture/builders#examples I gather that write-artifacts, just as Laurent mentioned, overwrites the provided composition file template (in our case -f "${COMPOSITION_FILE}") with a concrete composition file which has all the template variables replaced with concrete values already. The docs also suggests that it's really the only thing this option does (side note: I think it could use a better name).

Where are these artifacts saved?

If I understand the documentation correctly, we wouldn't be creating any new artifacts but only modifying the provided composition file.

How large do we expect them to be?

I think it should be comparable to the input composition file so I don't think we need to worry about the size.

Where are they stored between builds?

test-plans/.github/workflows/run-composition.yml

Lines 96 to 103 in d523e5c

	- uses: actions/upload-artifact@v3
	if: ${{ failure() }}
	with:
	name: testground-output
	path: |
	~/testground/
	~/test-plans/result.tgz
	${{env.COMPOSITION_FILE}}

Laurent added the composition file to the build bundle artifact here.

[galargh]

Now that there are retries we could download the shell script ahead of the loop.

[BigLep]

2022-09-16 libp2p triage conversation: @libp2p/ipdx feel free to merge. You're trusted on what's right to do here.

[galargh]

2022-09-16 libp2p triage conversation: @libp2p/ipdx feel free to merge. You're trusted on what's right to do here.

I saw some other PR mentioning write-artifacts with a merged icon and assumed it was this one. Thanks for the ping, we'll proceed with this on Monday.

[laurentsenta]

Thanks team, I just rebased over master, will merge soon,

A few answers:

Where are these artifacts saved? How large do we expect them to be? Where are they stored between builds?

• Test artifacts are the result of Testground's build phase and the input for the run phase. In our cases, the test artifacts are docker images, and the artifact field in the composition is the docker image id.
• We're not caching or moving artifacts between CI runs here. This only changes the I/Os of the build and run steps within a single CI job. (more details on caching and artifacts here: Use CI Caching during Interop Tests #31)

What does write-artifacts do? I googled it, but there seems to be little documentation about this flag?

Ignore write-artifacts for a second, this is what we want to do:

testground build --file my-composition.toml --output composition-after-build-that-contains-build-outcomes.toml
testground run --file composition-after-build-that-contains-build-outcomes.toml

Right now, this feature exists behind the write-artifacts flag, which overwrites the input file.

(I'm not happy with the name and implementation either, we'll deprecate/break this flag later).