You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, our bindings are never actually tested against commits made in the libgit2/libgit2. I feel like this is suboptimal and we could do better than that. Despite being able to catch breaking changes early before we break any binding by accident, executing tests of the bindings would also increase test coverage for libgit2 itself.
So what I'd like to have is a staged pipeline building libgit2, which is currently not possible with GitHub itself. The following stages should be part of that pipeline:
Build libgit2
Execute libgit2's own tests
Execute tests of bindings
Obviously, we wouldn't want to test all bindings against the new commit, as some bindings are completely out of date and not really maintained at all. So we should pick a set of "supported" or "official" bindings for which we want to guarantee not to break them. This would probably include at least pygit2, git2go, rugged and libgit2sharp.
There's two basic problems I see right now:
We don't currently have any CI with pipelining features. As discussed at the libgit2 contributors summit, we could probably use GitLab's CI for that.
We need to ensure that verification of pull requests won't blow up in time. That might actually be helped by using a third CI system.
This discussion was converted from issue #5875 on May 12, 2021 14:11.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
Right now, our bindings are never actually tested against commits made in the libgit2/libgit2. I feel like this is suboptimal and we could do better than that. Despite being able to catch breaking changes early before we break any binding by accident, executing tests of the bindings would also increase test coverage for libgit2 itself.
So what I'd like to have is a staged pipeline building libgit2, which is currently not possible with GitHub itself. The following stages should be part of that pipeline:
Obviously, we wouldn't want to test all bindings against the new commit, as some bindings are completely out of date and not really maintained at all. So we should pick a set of "supported" or "official" bindings for which we want to guarantee not to break them. This would probably include at least pygit2, git2go, rugged and libgit2sharp.
There's two basic problems I see right now:
Beta Was this translation helpful? Give feedback.
All reactions