Allow running several CI steps with the view

[vvolkl]

It's arguably nicer to have the different phases of a CI job - which are usually configure, compile, test, install - in their own steps, as this makes the logs more accessible in github and shows at a glance where an error occured.

[tmadlener]

It looks like having "proper" steps would require to split up the action into several smaller actions, e.g. a lcg-view-setup-container that could be used as a prerequisite by a run-lcg-view action that can be invoked multiple times that simply runs inside the container. The problem with that the two would be pretty strongly coupled and using them might become a bit less convenient than the current version.

A slightly different approach, that could work with the current action already would be to explicitly introduce grouping of log lines in the workflows directly, essentially:

  run: |
    echo "::group::Build"
    # build commands
    echo "::endgroup::"
    echo "::group::Run tests"
    # test commands
    echo "::endgroup::"

This results in collapsed log lines for the groups, e.g. all build outputs will be collapsed under a Build group, and all test command outputs will be collapsed under a Run tests group. If there is an error in a group it will remain uncollapsed. The grouping of log lines looks like this in the output, and would essentially introduce a substructure inside a given action.

To group the setup parts of the current action it would also be rather straight forward to introduce some logging groups in the setup scripts, that would at least make the payloads easier to see.

[wdconinc]

FYI, eic/run-cvmfs-osg-eic-shell#6 implements this in our EIC workflow environments (we only use singularity, though). Requesting the same container will reuse the container instance. Requesting a different container will start a new one.

[tmadlener]

Ah very nice. In principle that should work very similar with docker (apart from the slightly different syntax for getting running instances and getting a shell in them)

From what it looks like the EIC solution uses images that already have the complete environment setup inside of them? So for the use case here, we would essentially have to inject a source <setup-script> into the payload of each step that we want to use.

[wdconinc]

Yes, our containers include the whole kitchen sink.