2019-06-11 TC Meeting notes
Date
6am PST / 4pm CEST
Meeting Link
Attendees
Discussion items
Time | Item | Who | Notes |
---|---|---|---|
5m | Agenda and action item review | Josh Zamor | |
15 m | Collecting notes on next steps on reporting stack | Josh Zamor | We have:
Can we focus everything into production readiness #2 epic? |
PouchDB and flaky tests | Chongsun Ahn (Unlicensed) | Testing that involves the wrapper for PouchDB causes the UI tests to be flaky (what we sometimes refer to as random failures):
| |
10m | Orderable versioning (fulfillment) | Klaudia Pałkowska (Deactivated) |
|
Reducing Jira costs | Sebastian Brudziński / Wesley Brown |
| |
(next time) | Schedule for July 9th and on | Overlap with Governance committee every other week
| |
(next time) | Jenkins monitoring | Show only if time, roadmap for influxdb | |
(next time) | Look at streaming from Casper |
Notes
Pouch DB and flaky tests
- Ticket on tests failing from PouchDB: link (Josh Zamor find this search for local database failing randomly)
- Quarantining tests that are failing (disable and create tickets to fix)
- We expect that if we follow the patterns laid out now, that they won't be flaky. Wrote a tool to convert tests from JS promises, to Angular JS promises which work Jasmine.
Orderable incrementing
- Context is Fulfillment service and use of versions in Orderable
- New class - reference the version # along with orderable id
- works as nothing is snapshotted (mostly)
- One thing that is snapshotted today is useVVM in POD Line item
- Suggestion to remove the snapshotting, retrieve it directly from Orderable's (extra data)
- Will need to update reports (pick pack list and printing orders)
- Josh Zamor: take a look at https://github.com/OpenLMIS/openlmis-fulfillment/blob/master/src/main/resources/schemas/referenceObjectDto.json
- We might want to have a separate reference to orderable id and version # in json fields - make it easier for caching
- On incrementing:
- trigger?
- generated version id (marked as it doesn't work)
- hibernate envers
- We do have this at the service level, there is an issue to move it to repo layer (avoid race-condition)
- Josh Zamor: take a loot at this today
- Paulina Buzderewicz: create a forum post, with a link to the ticket
Jira costs
- Zephyr is expensive - considering ideas to a different tool (others don't support every feature we're using)
- Idea to have separate Jira instances:
- cloud instance to another could use a full backup... (look at link in table)
- managing access would add overhead
- We could turn it off for a couple months
- think it might come back when we turn it back on
- wouldn't be able to enter new test cases while it's off
Action Items
- Josh Zamor schedule future tech comm calls for Zoom and calendar
OpenLMIS: the global initiative for powerful LMIS software