chore: fix CI pipeline #38
Conversation
This will always pull from `main` when testing against `slurmctld-operator`, which is arguably better when trying to do breaking changes in integrations between the charms.
There was a problem hiding this comment.
I agree with dropping slurmdbd from the tests since we now only need slurmctld and slurmd to reach active state for both charms. I just have two comments. Comment number 1 I'd like to have addressed in this PR, and comment 2 is 🌮4️⃣🤔 that we should discuss in the future:
-
I think we should still be testing against the edge branch of the slurmctld operator in Charmhub as a non-gating test. Reason saying is that we should at least have some insight into whether the latest changes to the slurmd operator are compatible with the latest published version of slurmctld. That way we have a flag for whether we're intentionally or unintentionally breaking the API between the two charms. If we're intentionally breaking, we can comment the context on the PR, and if we're unintentionally breaking, we know that we have some further debugging to do. Let me know your thoughts on this.
-
We should have discussion about what smoke testing will look like for Charmed HPC. I definitely think that a full-scale Charmed HPC cluster will quickly overwhelm a single GitHub Runner, so we should brainstorm what those tests will eventually look like, and where to run them.
I think that would be good, that way we do breaking changes in a more controlled way. |
Sweet! Let's do that then, we can have the integration test against the edge branch in Charmhub run concurrently with the main integration test against the cloned version of slurmctld. |
|
@NucciTheBoss Added a non-gating job that tests against Charmhub edge, PTAL. |
This will always pull from
mainwhen testing againstslurmctld-operator, which is arguably better when trying to do breaking changes in integrations between the charms.How was the code tested?
Locally using a development environment based on Ubuntu Jammy.
Checklist