Create developer install TestPlan.md document

[johnsaigle]

We should create a document defining steps to take to verify the install of a developer instance of LORIS. This document would be followed by a developer during our release testing to determine that it is easy and straight-forward to install a dev instance.

This could include steps to take during post-install, such as

• "Bootstrapping": installing additional dependencies for the dev tools
• Getting a working copy of test data (i.e. the "Raisinbread" data set)
• ...

---

Some other things:

• This document would need to be thoroughly vetted each release to be up-to-date with our dependencies, etc. This would help us toward our goal of reducing the need for ad-hoc Wiki hotfixes, which are a necessary evil while there are gaps in our documentation.

• The document should be as general as possible and should not contain information pertaining to our internal IT procedures.

• There should also be a companion document for Vagrant installs, if specific information is needed for that context.

• There is existing information available to help with this task: the "LORIS 101" document, existing Wiki pages, as well as institutional knowledge not written down but known by members of the team. There are likely some common bugs as well that can be fixed as we codify this process.

[johnsaigle]

#4168 is relevant to this ticket. phan has a dependency on the PHP ast extension. This is required only for developer instances of LORIS and so is not installed by default. It should be done automatically on dev installs or at the very least explicitly documented for developer installs.

[johnsaigle]

https://github.com/aces/Loris/issues/3313 is related. Need to make sure Vagrant install works effortlessly.

[johnsaigle]

@ridz1208 Following up on the discussion in #4168 would you be able to do a small talk to the group about the status of the Wiki? What branch it's on, tentative schedule, how to contribute, etc?

[johnsaigle]

#4365 is an attempt at automating some of the post-install steps and satisfying (Ubuntu) system dependencies as LORIS moves forward.

[johnsaigle]

EDIT: I've updated this comment to install node version 10. I originally had these instructions install version 8 which has since been abandoned. (written: May 13, 2020)

@kchatpar and I discovered more issues for Ubuntu-based developer installs today.

• Fresh Ubuntu installs lack the following tools by default:

  • make
  • npm

• The version of node shipped with Debian (and therefore Ubuntu) is very out of date to the point where it does not work with webpack. To remedy this we updated node using the following commands

curl -sL https://deb.nodesource.com/setup_10.x | sudo -E bash -
sudo apt-get install -y nodejs

As a result, development on major is frustrated as make dev cannot be run which means JS files cannot be compiled. LORIS will load blank decorated pages.

These steps will likely be important for the bootstrap script, the Vagrant file, as well as the Wiki.

[johnsaigle]

CentOS configuration is probably related to this issue.

[johnsaigle]

Note that these issues just came up again with Clark, our new volunteer.

[christinerogers]

• The version of node shipped with Debian (and therefore Ubuntu) is very out of date to the point where it does not work with webpack. To remedy this we updated node using the following commands

John's March 12 comment appears to be an issue for users installing the 21 release, not documented in the Release notes or Readme. Adding it to Doc project. @johnsaigle do you feel this should be split into a new issue?

[johnsaigle]

Yes I think that point specifically is probably worthy of being treated as its own bugfix givent hat the release is already out.

[christinerogers]

Thanks for #5017 👍

[johnsaigle]

I feel confident for the most part that this is covered by what I've written in #5253. While not labeled as a "test plan" this document enumerates all the steps necessary for getting LORIS set up for a developer, starting from a fresh Ubuntu (with prereqs such as PHP, node, etc. already installed) all the way to getting raisinbread working.

We can use these instructions during release testing.

[johnsaigle]

I've changed #5253 to focus on production. A new document will be needed for modifications needed for a development installation.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[christinerogers]

Following on John's comment above and #2523 This issue is partially advanced by our GSOC2020 team (led by) @AlexandraLivadas , @h-karim and @spell00 also with @laemtl
A test plan could still be contributed, based on the following updated PRs for the Loris 23 release:

• #6510 - install markdowns updated for dev and prod
• #6511 - installation Troubleshooting guide

Also side note, later in summer 2020 a future PR will flesh out the 99_developer_guide/ markdowns (in the "new wiki"), based on GSOC2020 training materials - to provide useful info for LORIS developers out in the wild.

[laemtl]

@christinerogers Can we benefit from @haoweiqiu help on this?

[laemtl]

@driusan @christinerogers Do we still support Vagrant?

[driusan]

No

[laemtl]

@haoweiqiu This document is a good starting point, and needs modifications for a development installation. You can take a look at this version for dev specific sections you can add in the new document, as well as the suggestions made in this thread.

[ridz1208]

@driusan @christinerogers and others who might care about this

My instinct is to close this issue, here is why:

1. We have official install documentation so we don't need a new one, if changes are required they should be made there
2. Every new developer ends up making their own documentation which ends up being 95% reusable with other developers but requiring 5% environemnt differences that makes the next new hire rewrite another new documentation.... the cycle keeps repeating
3. the description asks for documentation which is not specific to MCIN but includes several aspecs that are specific to MCIN. Raisinbread for example is a public dataset but installed VERY differently for MCIN developers vs non-mcin developers and I would suspect non-MCIN developers to be a rather rare usecase no warranting a whole document written for them? (they wouldnt even use RB since RB is mainly used internally)
4. Same logic applies to multiple other MCIN vs non-MCIN developer differences, this is why the developer install documentation always resided in the google drive and not on the branch (since it wouldnt work for non-MCIN developers with access to the repo)

If we are talking about a google doc... this issue does not belong here and MULTIPLE google docs already exist so we dont need the issue