Run current master of hyteg-operators in the HFG CI

This is not relevant to test whether the operators have changed (so there should not be a diff) but it shall check whether all operators are generated at all. Maybe a nightly run is sufficient(?). To be discussed.

added CI label

mentioned in issue #37 (closed)

This would be needed, as when we change some core functionality in hog, it would be crucial to check atleast the generate.py in hyteg-operators runs without any error. Maybe can just run a simple diffusion operator for this check.

While I understand the problem, I generally disagree with running generate.py in hogs CI. hog is a standalone library and generate.py is "just one script" that uses it. It is the responsibility of the downstream project to ensure compatibility after upgrades. After all, there is no immediate need to regenerate all operators after updating hog.

I deliberately had written the requirements file in hyteg-operators such that it includes the exact commit of hog because of this reason (among others). Unfortunately, the commit hash has been removed (hyteg-operators!8 (merged)) before I could complain ^^. I vote for adding that again, such that the generate script can not be broken by merging MRs in hog and to guarantee (as best as we can) reproducibility.

Nevertheless, it is probably the easiest to update the generate script shortly after introducing breaking changes to hog. And, I guess, it makes sense if the same person is responsible for that. Of course, what I wrote above is just my opinion and up to discussion. I agree that a job in the CI can serve informational purposes that breaking changes have been introduced.

Certainly, if we were to add a job like this to hog, then it must be allowed to fail. Otherwise, we would need to update both projects at the same time so that both pipelines can pass, which is not possible.

Nevertheless, it is probably the easiest to update the generate script shortly after introducing breaking changes to hog

This is exactly the solution and I thought a test in hog would serve this purpose. But I agree that although everything is under hyteg, a compatibility test with a downstream project seems weird.

Adding commit hash is fine for me, so that a given master version will not break. But it would not help when we add new operators in hog and want to make it available in hyteg-operators, then the generate.py should be working nevertheless.

Good point about the forms.

I think there are two problems.

1. Realizing that some changes were breaking.
2. Getting someone to update the generate script.

For 1. we can add a job here, which runs on every MR and is allowed to fail. Or we can add a nightly job in hyteg-operators which generates one operator (like you suggested) using hog's main. Not sure about the pros and cons of either approach. Probably, your suggestion is more reliable. Oh, and if the generate-all-operators.py is adjusted, that probably means that generate.py requires changes, too (and vice versa).

Number 2. I do not think we can enforce anything, because the two projects are separate. We can only look after each other and remind of outstanding todos.

Yes for 1. a CI job would indicate the issue, for me it doesn't matter where we run it.

But for 2. Another not-so-thought-out suggestion, would it make sense to move the generate.py to hog. As we already do opgen tests in hog, what will prevent us from using a single generate.py script for both in hog and in hyteg-operators.

I really like that idea. I think it requires some care to unify the goals of both scripts but do not see any major hurdles right away.

Just some notes

Unfortunately, the commit hash has been removed ( hyteg-operators!8 (merged)) before I could complain ^^. I vote for adding that again

I vote for that, too! Regardless of how we solve this issue.

for me it doesn't matter where we run it.

Same. A practical advantage to have that in HOG would be that the chances are higher that people notice that they break compatibility with hyteg-operators after merging something into HOG's main branch.

---

Maybe we can also add a short CI job to hyteg-operators that signals whether the HOG hash in the requirements points to the latest main commit. Just so it is visible that there is something new available (maybe).