-
Notifications
You must be signed in to change notification settings - Fork 123
Integrate go-elektra binding to main repo #3458
Comments
It is possible that bumping the version of go-elektra in elektrad would have been enough, but I did not know that this needs to be done. Edit: integrating the repos might not work well because of the way that go packaging works, but maybe Raphi knows how this could be done. |
Or we can simply use latest master from elektra-go from now on? Maybe we could have made libelektra's CI happy if the branch of libelektra would have used the branch of elektra-go. |
The go-elektra builds are broken, seems like nobody notices it: https://travis-ci.org/github/ElektraInitiative/go-elektra |
I don't have access or notifications for that repo. Can't trigger a rebuild or anything. Not that I have the capacity to maintain the go bindings. |
I gave the "core" team admin access to the repo. Is there any other repo the "core" team doesn't have access to? |
The repo was broken with some old packages that 404'd.
I fixed it manually now, but we really need to automate this. It seems that the builds are now fixed. |
I just rerun the tests of the go repo and it succeeded. This obviously means that it still tests against an old version of Elektra, as there are many old-style key names in the tests of the go binding (e.g. kdb/keyset_test.go kdb/key_test.go) Somehow, we need to take care of the go repo in the release management. So either:
|
The ubuntu repo needs to be updated by hand, which explains why there is no (new) CI failure there. I will update the repo now. Regarding release management: |
I agree. Just to be sure, with the 4th option you mean adding the automatic steps to the release pipeline and not to the "main" pipeline? |
In general we should put as much as possible to the main pipeline (maybe with some extra nightly build that does not build on every push if we produce overload on the build server), as the release manager wants to avoid a painful release: and every error detected so late is quite problematic. So also these go tests: ideally they are executed on every push. And they are very fast compared to other tests, so there should be no problem. They are only quite different in their nature, as they work from a different repository. They are not high-prior though, I added them to the backlog. |
Now the Ubuntu and Debian packages are finally being built again, thanks to @sanssecours. I've triggered a re-build for the go-elektra tests and now it is finally failing (as expected due to Keyname overhaul). The bindings need to be updated now. |
Thank you very much! I just got the update from 0.9.3-1.2841 to 0.9.3-1.2961.
Yes, this is tracked in #3570 |
I mark this issue stale as it did not have any activity for one year. I'll close it in two weeks if no further activity occurs. If you want it to be alive again, ping the issue by writing a message here or create a new issue with the remainder of this issue. |
I closed this issue now because it has been inactive for more than one year. If I closed it by mistake, please do not hesitate to reopen it or create a new issue with the remainder of this issue. |
@lukashartl did you look at this already? Maybe you can describe more precisely what should be done? |
To be fixed by #4895 |
It looks like on every incompatible change in Elektra, both CIs (go-elektra and libelektra) will fail.
Was disabling the build stages necessary or would 2f29a65 have been enough?
Any other ways to improve the situation except of integrating the repo into the main one?
@raphi011 what do you think?
The text was updated successfully, but these errors were encountered: