That seems like a great Microsoft idea 😄
We were struggling with getting logs from azure because Microsoft decided to make one part of the storage url random 🤦♂️
Ajit D'Sa and I have been working on some DB updates. Updated MongoDB, added a postgres, but also we could update SQLite.
The main reason is this:
Skills should be allowed to specify which table they save to.
Right now, one opsdroid instance with one DB, two different skills will save into the same table/collection of the same db.
So we allow:
getfunctions as an optional kwarg.
I do not know how to write good tests for this. Is there a way to spin up a postgres instance on commit and run unit tests against it? Or decent mock modules available?
Awesome thanks! I'm excited to see this work happening.
I'm curious about the desire to have different tables/collections for each skill. I've always considered it a feature that the opsdroid memory object is accessible from any skill. Each skill can just choose a prefix for the key name if there are concerns about collision.
pytest-dockerto start a postgres database as part of the pytest fixtures.
assert event.abc == "pyup-bot"and then run
pytest opsdroid/connector/github/tests/test_connector_github.py::test_pr_mergedit still passes. Any reason why this would be?
Exception when running skillis not logged once the skill has been run.
tryand then catch the exception coming back, yah? If not, lemme know if you can pseudocode it out for me, and I'll try making the change
caplogto the arguments here https://github.com/opsdroid/opsdroid/blob/a45490d1bdceca39b49880e20262b55ea0be101d/opsdroid/connector/github/tests/test_connector_github.py#L227
assert "Exception when running skill" not in caplog.texthere https://github.com/opsdroid/opsdroid/blob/a45490d1bdceca39b49880e20262b55ea0be101d/opsdroid/connector/github/tests/test_connector_github.py#L249
caplogstuff working. But I read all about
caplogand there's no reason it shouldn't work. So I tried just straight raising an exception in the skill, and finally just tried putting a breakpoint (like a
pdb.set_trace()) in the skill... and none of it registered. There didn't seem to be any change I could make in the skill that would affect anything at all. I tried this with multiple skills. I only tried this with skills in the github connector so far.
assert resp.status == 201which waits for the skill to be called. Maybe even adding an
asyncio.sleepafter will be enough to get it to hit your breakpoint. But we probably need some testing utility which blocks until the skill has been called.