Jenkins builds broken when okapi-3 until ModuleDescriptors have permissionsRequired, then verify
Description
Environment
Potential Workaround
Attachments
is blocked by
relates to
Checklist
hideTestRail: Results
Activity

Adam Dickmeiss June 22, 2020 at 1:16 PM
This latest issue is going to be fixed with

David Crossley June 22, 2020 at 6:20 AM
As explained in this ticket Description, the default permissionsRequired was added to those other modules so that we could proceed with this, and attempt to unpin Okapi version.
There are now still permissions issues with the build. Hongwei and i have tried various changes over the weeekend and today, in this folio-ansible branch.
Built the folio-snapshot-test again today. See folio-snapshot-test/177
but it fails.
It is using the current okapi-3.1.1 release.
See the attached portion of log at okapi-snapshot-test-177-20200622.log (i have more if needed).
There are many errors of the following form (but not sure if that is the actual problem):
Our most recent change to folio-ansible was to extend the "length" of the permission query to "Get all permissionSets" from 500 to 2000. That was for the linked Jenkins run 177. Extended that again to 3000 and ran again for Jenkins build 178, but still failed.

Marc Johnson June 19, 2020 at 11:19 AM
those manual ones can be changed back to use direct ones but do not have to. Both ways should work because perm sets are expanded recursively.
Thanks

David Crossley June 19, 2020 at 7:44 AM
Thanks Hongwei. I merged that and followed with test Jenkins builds:
They failed at different ansible tasks.
However i am out of time today to investigate further.

Hongwei Ji June 18, 2020 at 2:29 PM
, and I created a PR to address the perm count error: https://github.com/folio-org/folio-ansible/pull/360 but I cannot request reviewers due to permission setup for that repo.

Hongwei Ji June 18, 2020 at 1:39 PM
, those manual ones can be changed back to use direct ones but do not have to. Both ways should work because perm sets are expanded recursively.

Marc Johnson June 18, 2020 at 1:32 PM
we added a feature to automatically generate permission set for module permissions
Does that mean that the manual permission sets maintained by modules like mod-circulation should be changed back to direct module permissions in the future?

Hongwei Ji June 18, 2020 at 1:28 PMEdited
In Okapi3, we added a feature to automatically generate permission set for module permissions. Seems the ansible script in this line https://github.com/folio-org/folio-ansible/blob/85ad9988f3c4fd91cfec35ea515140e0a942f5d5/roles/tenant-admin-permissions/tasks/main.yml#L19 should be updated to exclude those permissions. The naming convention for those permissions is prefixing with "SYS#" by the way. and , can you take a look? Thanks.

David Crossley June 18, 2020 at 12:58 PMEdited
Folowing today's Okapi v3.1.1 release, i did a new run of Jenkins build folio-snapshot-test/164
However it fails with this:
Attached the okapi logs. – later deleted because not needed.

Hongwei Ji June 16, 2020 at 2:30 PM
I looked into the attached Okapi log and have an idea why it broke, so I opened .

Marc Johnson June 16, 2020 at 11:11 AM
Given that this issue is still outstanding and the hosted environments are not running Okapi 3.x, does that mean that the official version of Okapi for 2020 Q2 will be Okapi 2.x?
Details
Details
Assignee

Reporter

When okapi-3.0.0 was recently released, the reference environment builds broke with errors of the following form:
That one was soon fixed, but then the breakage moved on to the next module.
Until modules have at least the default empty permissionsRequired array in their ModuleDescriptor, then Okapi has been pinned in folio-ansible to okapi-2.40.0 (pull/352).
Note: updating the ref envs to Okapi 3.0 is in scope of this ticket.
Update: 20200619: Those modules with missing permissionsRequired are fixed.
Now unpin okapi to current v3 reveals other troubles with refenv builds. Perhaps ansible playbook related.