Talk:Sandboxes

From Koha Wiki
Jump to navigation Jump to search

Things to details more in the workflow

1

Start by creating a sandbox. And without filling the bug number field. Because most bug test plans start without patch to check that the bug is still there. And this allow to immediately start the creation of the sandbox. So that while it's being created, one can pick a ticket to test.

2

dashboard:

  • go to the "Bug statuses" section (middle of the page)
  • see "Needs Signoff"
  • it's a link to the list of all tickets ready to be tested
  • when still unexperienced or short on time: start with bugs, they tend to be simpler to test. The link is on the end of the line:
Screenshot 2022-12-02 21-47-27.png











3

Check if it's testable in a sandbox.

Quickly decide but risk missing actually testable tickets

Look if the test plan mentions running a command, if yes: skip. Simple but will miss a number of testable tickets. Not a problem when the pile of tickets needing testing is big. Get the low handing fruits before you will gradually become familiar with the points in the next section.

Reliably assess testability

List of no-go examples:

  • run tests: the command start with "prove" or test plan says "run something-something.t" (the .t file extension is for tests)
  • edit pretty much any file: like koha-conf.xml, XSLT stylesheets, Zebra configuration like biblio-koha-indexdefs.xml, ccl.properties, authorities.xml
  • run an UPDATE/DROP/INSERT SQL query (anything other than a SELECT, we can't)
  • update translation strings. This is not the same as installing a translation.
  • run overdue_notices.pl
  • LDAP, Shibboleth, OAuth
  • copying files (usually with the cp command)
  • SIP
  • install a Perl library
  • very likely any command that you don't see matching what's in the next list
  • complete this list with any missing case or report it to the koha-devel mailing list or the chat. So we can get this exhaustive enough to make patch testing the most autonomous possible.

List of stuff we can actually do in sandboxes:

  • install translations, it's possible to deploy a few languages via sandboxes management interface => Actions => Install translations. This is different from updating translation strings.
  • restart services/plack. Sandboxes management interface => Actions
  • rebuild the interface or OPAC CSS: go the sandboxes management interface => Actions => Build CSS
  • run a SELECT SQL query: use SQL reports
  • look in logs: sandboxes management interface => Logs
  • use Elasticsearch: change syspref "searchengine" to Elasticsearch and go the sandboxes management interface => Actions => reindex
  • install plugins: you need test this right away before doing the test plan. Between the 3 sandbox providers (BibLibre, ByWater, PTFS-E) they don't all plugin installation working (probably for security reasons). So in your sandbox try to install the kitchen-sink plugin, if it doesn't fail and your interface turn orange it works. Then uninstall it and you can test the patches.
  • send emails, including process_message_queue.pl see https://wiki.koha-community.org/wiki/Sandboxes#Testing_sending_emails
  • refresh schema, (with the dbic command). Sandboxes management interface => Actions => Refresh schema
  • complete this list with any missing case or report it to the koha-devel mailing list or the chat. So we can get this exhaustive enough to make patch testing the most autonomous possible.

4

Find the right (up to date) test plan: Attachments section => click the date of the 1st listed attachement to make the page scroll down to it.