Fix nightly execution of requirements tracing

[sophokles73]

The check has failed recently because it had been erroneously using
the file patterns that refer to the current (not yet released) state
of up-spec.

Also replaced GitHub repo variables with explicit specification of
file patterns in order to have more flexibility when defining the
scope of the check.

[AnotherDaniel]

Looks good

[sophokles73]

@AnotherDaniel would you mind taking another look? I have added some changes making the distinction between compliance with current spec and compatibility with latest spec more explicit.

[AnotherDaniel]

I like the differentiation you're introducing here, between the Programmatic and the Conceptual.

One question: is there a better place to define the file patterns? I really have not thought this through, first thing that comes to mind: is this information actually worth putting in an explicit little file in the repo, so that it be defined and managed together with the code it pertains to? (I realise that this is kind of the case now, inline in the action definition. But I think this is somewhat obscure, plus changes to the file-pattern scope shouldn't necessarily result in changes to the CI pipeline itself...)

[sophokles73]

One question: is there a better place to define the file patterns? I really have not thought this through, first thing that comes to mind: is this information actually worth putting in an explicit little file in the repo, so that it be defined and managed together with the code it pertains to?

That is exactly what I tried to achieve by having the respective file patterns being defined in one place only: the two specific workflows. The compliance check uses (potentially) different files than the compatibility check (which needs to consider the latest developments in up-spec).

[AnotherDaniel]

I amended my comment while you wrote yours :)

The little nag I feel is that, it feels not optimal to have to modify CI pipeline files (infrastructure) for this kind of scan-scope change.
But that might just be me...

[sophokles73]

I amended my comment while you wrote yours :)

The little nag I feel is that, it feels not optimal to have to modify CI pipeline files (infrastructure) for this kind of scan-scope change. But that might just be me...

So you would prefer to read the patterns from text files in the repo?

[AnotherDaniel]

I'd at least like to get your thoughts on separating this out from the CI scripts. I'm not certain how strongly I feel about this right now.

[sophokles73]

I'd at least like to get your thoughts on separating this out from the CI scripts. I'm not certain how strongly I feel about this right now.

These file patterns are supposed to be adapted over time to reflect the changes being made to up-spec and up-rust. Given that the workflows are part of the code base in the same way that the rust source code files are, I do not see a real problem with having the file patterns in the workflows themselves. We have already factored out the reusable parts (i.e. running the OFT check) into the ci-cd repo, so everything that is left over is indeed specific to the repository/component at hand. Moving the file patterns into some other file, would not change any of that but would require additional logic to be implemented in the workflows to extract the information from these files.

I would therefore suggest starting like this and adapting along the way ...

[AnotherDaniel]

Ok fair enough.

[AnotherDaniel]

LGTM