+
+
+
diff --git a/administration/getting_started.md b/administration/getting_started.md
index d920f9c..364a700 100644
--- a/administration/getting_started.md
+++ b/administration/getting_started.md
@@ -5,10 +5,11 @@
* Java 8 or 11 only (OpenJDK should be fine)
* At least 1024 MB RAM allocated to the application; at least 2 GB for optimal performance.
* Solr (for ArchivesSpace versions after 3.1)
+* NodeJS
ArchivesSpace has been tested on Ubuntu Linux, Mac OS X, and Windows.
-While ArchivesSpace does include an embedded database, MySQL is required for production use.
+While ArchivesSpace does include an embedded database, MySQL is required for production use.
(While not officially supported by ArchivesSpace, some community members use MariaDB so there is some community support for version 10.4.10 only.)
@@ -29,8 +30,11 @@ You can check your Java version by running the command:
If you are running an earlier version of java upgrade to 1.8 or 1.11 (not the newest version of Java). If you are running a newer version of Java you should revert back to 1.8 or 1.11 or force your machine to use 1.8 or 1.11 for ArchivesSpace.
When you extract the `.zip` file, it will create a directory called
-`archivesspace`. Next, follow the instructions for setting up
-[MySQL](../provisioning/mysql.html), and for version 3.2 and above, [Solr](../provisioning/solr.html).
+`archivesspace`. Next, follow the instructions for setting up:
+
+* [MySQL](../provisioning/mysql.html)
+* The minimum supported version is v18.20.2. We recommend installing the latest LTS version of Node.js. See the [Node.js download page](https://nodejs.org/en/download/) for instructions.
+* for version 3.2 and above, [Solr](../provisioning/solr.html) is also required
**From any ArchivesSpace version > 3.1.0 external Solr is required. Earlier versions provided an embedded Solr v4 instance, which is now unsupported due to its age.**
diff --git a/administration/upgrading.md b/administration/upgrading.md
index 546d845..cf5366c 100644
--- a/administration/upgrading.md
+++ b/administration/upgrading.md
@@ -127,7 +127,7 @@ Or on Windows:
## If you're using external Solr (required beginning with version 3.2.0)
-[Full instructions for using external Solr with ArchivesSpace](provisioning/solr.html)
+[Full instructions for using external Solr with ArchivesSpace](https://archivesspace.github.io/tech-docs/provisioning/solr.html)
## If you've deployed to Tomcat
diff --git a/customization/authentication.md b/customization/authentication.md
index a63ca91..ac48c61 100644
--- a/customization/authentication.md
+++ b/customization/authentication.md
@@ -4,8 +4,8 @@ ArchivesSpace supports LDAP-based authentication out of the box, but you can
authenticate against other password-based user directories by defining your own
authentication handler, creating a plug-in, and configuring your ArchivesSpace
instance to use it. If you would rather not have to create your own handler,
-there is a plug-in available that uses OAUTH user authentication that you can add
-to your ArchivesSpace installation: https://github.com/lyrasis/aspace-oauth.
+there is a [plug-in](https://github.com/lyrasis/aspace-oauth) available that uses OAUTH user authentication that you can add
+to your ArchivesSpace installation.
## Creating a new authentication handler class to use in a plug-in
diff --git a/customization/configuration.md b/customization/configuration.md
index 48c28d6..e469dd7 100644
--- a/customization/configuration.md
+++ b/customization/configuration.md
@@ -18,7 +18,7 @@ ArchivesSpace. Be sure that your new settings are not commented out
Set your database name and credentials. The default specifies that the embedded database should be used.
It is recommended to use a MySQL database instead of the embedded database.
For more info, see
-[Running ArchivesSpace against MySQL](https://github.com/archivesspace/tech-docs/blob/master/provisioning/mysql.html)
+[Running ArchivesSpace against MySQL](https://archivesspace.github.io/tech-docs/provisioning/mysql.html)
This is an example of specifying MySQL credentials:
@@ -177,7 +177,6 @@ Directory to store Solr backups.
`AppConfig[:solr_backup_directory] = proc { File.join(AppConfig[:data_directory], "solr_backups") }`
-
### Default Solr params
#### `AppConfig[:solr_params]`
diff --git a/cypress.config.js b/cypress.config.js
new file mode 100644
index 0000000..222fece
--- /dev/null
+++ b/cypress.config.js
@@ -0,0 +1,7 @@
+import { defineConfig } from 'cypress';
+
+export default defineConfig({
+ e2e: {
+ setupNodeEvents() {}
+ }
+});
diff --git a/cypress/e2e/feedback.cy.js b/cypress/e2e/feedback.cy.js
new file mode 100644
index 0000000..07e6c69
--- /dev/null
+++ b/cypress/e2e/feedback.cy.js
@@ -0,0 +1,45 @@
+const editBaseUrl = 'https://github.com/archivesspace/tech-docs/edit/master/';
+const issuesUrl =
+ 'https://archivesspace.atlassian.net/jira/software/projects/TD/issues';
+
+describe('Feedback', () => {
+ it('includes an edit this page on GitHub link on every page', () => {
+ const editText = 'Edit this page on GitHub';
+ let file = 'README.md';
+
+ cy.visit('http://localhost:4000/');
+ cy.get('a')
+ .contains(editText)
+ .should('have.attr', 'href', `${editBaseUrl}${file}`)
+ .children()
+ .should('have.text', file);
+
+ file = 'readme_develop.md';
+ cy.visit('http://localhost:4000/readme_develop');
+ cy.get('a')
+ .contains(editText)
+ .should('have.attr', 'href', `${editBaseUrl}${file}`)
+ .children()
+ .should('have.text', file);
+ });
+
+ it('includes a report issue on Jira link on every page', () => {
+ const reportText = 'Report issue on Jira';
+ let file = 'README.md';
+
+ cy.visit('http://localhost:4000/');
+ cy.get('a')
+ .contains(reportText)
+ .should('have.attr', 'href', `${issuesUrl}`)
+ .children()
+ .should('have.text', file);
+
+ file = 'readme_develop.md';
+ cy.visit('http://localhost:4000/readme_develop');
+ cy.get('a')
+ .contains(reportText)
+ .should('have.attr', 'href', `${issuesUrl}`)
+ .children()
+ .should('have.text', file);
+ });
+});
diff --git a/cypress/fixtures/example.json b/cypress/fixtures/example.json
new file mode 100644
index 0000000..02e4254
--- /dev/null
+++ b/cypress/fixtures/example.json
@@ -0,0 +1,5 @@
+{
+ "name": "Using fixtures to represent data",
+ "email": "hello@cypress.io",
+ "body": "Fixtures are a great way to mock data for responses to routes"
+}
diff --git a/cypress/support/commands.js b/cypress/support/commands.js
new file mode 100644
index 0000000..66ea16e
--- /dev/null
+++ b/cypress/support/commands.js
@@ -0,0 +1,25 @@
+// ***********************************************
+// This example commands.js shows you how to
+// create various custom commands and overwrite
+// existing commands.
+//
+// For more comprehensive examples of custom
+// commands please read more here:
+// https://on.cypress.io/custom-commands
+// ***********************************************
+//
+//
+// -- This is a parent command --
+// Cypress.Commands.add('login', (email, password) => { ... })
+//
+//
+// -- This is a child command --
+// Cypress.Commands.add('drag', { prevSubject: 'element'}, (subject, options) => { ... })
+//
+//
+// -- This is a dual command --
+// Cypress.Commands.add('dismiss', { prevSubject: 'optional'}, (subject, options) => { ... })
+//
+//
+// -- This will overwrite an existing command --
+// Cypress.Commands.overwrite('visit', (originalFn, url, options) => { ... })
\ No newline at end of file
diff --git a/cypress/support/e2e.js b/cypress/support/e2e.js
new file mode 100644
index 0000000..0e7290a
--- /dev/null
+++ b/cypress/support/e2e.js
@@ -0,0 +1,20 @@
+// ***********************************************************
+// This example support/e2e.js is processed and
+// loaded automatically before your test files.
+//
+// This is a great place to put global configuration and
+// behavior that modifies Cypress.
+//
+// You can change the location of this file or turn off
+// automatically serving support files with the
+// 'supportFile' configuration option.
+//
+// You can read more here:
+// https://on.cypress.io/configuration
+// ***********************************************************
+
+// Import commands.js using ES2015 syntax:
+import './commands'
+
+// Alternatively you can use CommonJS syntax:
+// require('./commands')
\ No newline at end of file
diff --git a/development/dev.md b/development/dev.md
index 82cda56..a7056f4 100644
--- a/development/dev.md
+++ b/development/dev.md
@@ -2,7 +2,7 @@
System requirements:
-- Java 8 or 11 (11 recommended)
+- Java 8, 11 (11 recommended) or 17
- [Docker](https://www.docker.com/) & [Docker Compose](https://docs.docker.com/compose/) is optional but makes running MySQL and Solr more convenient
- [Supervisord](http://supervisord.org/) is optional but makes running the development servers more convenient
@@ -29,6 +29,19 @@ jabba use openjdk@1.11.0-2
jabba alias default openjdk@1.11.0-2 # [optional] make this the default java
```
+On Linux/Ubuntu it is generally fine to install from system packages:
+
+```bash
+sudo apt install openjdk-$VERSION-jdk-headless
+# example: install 11 & 17
+sudo apt install openjdk-11-jdk-headless
+sudo apt install openjdk-17-jdk-headless
+
+# update-java-alternatives can be used to switch between versions
+sudo update-java-alternatives --list
+sudo update-java-alternatives --set $version
+```
+
If using Docker & Docker Compose install them following the official documentation:
- [https://docs.docker.com/get-docker/](https://docs.docker.com/get-docker/)
diff --git a/development/release.md b/development/release.md
index cb07fbf..b2199e6 100644
--- a/development/release.md
+++ b/development/release.md
@@ -31,26 +31,32 @@ git checkout release-v1.0.x
```
Patch versions typically arise because a regression or critical bug has arisen since
-the last major or minor release. If the "hotfix" has been merged to the release branch,
-it will need to be cherry-picked back to the master branch. If it has been merged to the
-master branch (more likely given current code review / QA workflow), it (they) will
-need to be cherry-picked to the release branch.
+the last major or minor release. We try to ensure that the "hotfix" is merged into both
+master and the release branch without the need to cherry-pick commits from one branch to
+the other. The reason is that cherry-picking creates a new commit (with a new commit id)
+that contains identical changes, which is not optimal for the repository history.
+
+It is therefore preferable to start from the release branch when creating a "hotfix"
+that needs to be merged into both the release branch and master. The Pull Request should
+then be based on the release branch. After that Pull Request has been through Code review,
+QA and merged, a second Pull Request should be created to merge the updated release branch
+to master.
Consider the following scenario. The current production release is v1.0.0 and a critical
bug has been discovered. In the time since v1.0.0 was released, new features have been
added to the master branch, intended for release in v1.1.0:
``` shell
-git checkout master
-git checkout -b oh-no-some-migration-corrupts-some-data
+git checkout -b oh-no-some-migration-corrupts-some-data origin/release-v1.0.0
( fixes problem )
git commit -m "fix bad migration and add a migration to repair corrupted data"
-gh pr create --web
-( PR is reviewed and merged to master)
+gh pr create -B release-v1.0.x --web
+( PR is reviewed and merged to the release branch)
git checkout release-v1.0.x
-git cherry-pick [SHA of hotfix commit]
-git push origin release-v1.0.x
+git pull
git tag v1.0.1
+gh pr create -B master --web
+( PR is reviewed and merged to the master branch)
```
##