This change
- removes instructions about commit headers that nobody follows,
- links to useful resources for first-time contributors,
- simplifies some text, and
- hides all text inside <!-- -->.
* tests: CI of updating from master > this commit.
In response to cypress eslint I thought I'd put some CI testing for if a PR might break automated upgrading.
Matrix usage is probably overkill.
* Update major-version-git-pull-update.yml
* Name...
* include a front end test
* fix pathing
* Clarity on what's happening
* Update .github/workflows/major-version-git-pull-update.yml
Co-authored-by: Richard Hansen <rhansen@rhansen.org>
* Update .github/workflows/major-version-git-pull-update.yml
Co-authored-by: Richard Hansen <rhansen@rhansen.org>
* Update .github/workflows/major-version-git-pull-update.yml
Co-authored-by: Richard Hansen <rhansen@rhansen.org>
Co-authored-by: Richard Hansen <rhansen@rhansen.org>
* tests: Frontend test Windows ZIP
This PR introduces Frontend testing within Github actions!
We're depending a lot on saucelabs recently and that's fine but sometimes we just want to quickly do a frontend simple test on a weird environment (IE windows build) so this PR solves that problem.
Things to note.
It still builds the windows .zip if the cypress tests fail.
It does not add any heavy deps to Etherpad as cypress must be installed in CI.
Cypress is responsible for running the Etherpad instance.
It's up to us how much we use this or not, I know it introduces a bunch of technical debt but I tried to keep that a minimum by compartmentalizing things and documenting where required.
* Update .github/workflows/windows-zip.yml
Co-authored-by: Richard Hansen <rhansen@rhansen.org>
* remove timeouts
* Move folder structure up a level
* Update windows-zip.yml
* Update test.js
Co-authored-by: Richard Hansen <rhansen@rhansen.org>
* Windows CI Installer
This PR introduces CI builds of a windows installer(using NSIS) .
It builds an executable that installs Etherpad and runs it.
There are obvious steps to make once this has been merged. But I'd suggest on each release we include both the .zip and the .exe and allow users to have a portable zip or an installed executable.
https://github.com/ether/etherpad_nsis
This was a relatively rushed project (4 hours) and I didn't want to spend any more time on it so it will need a foster parent to maintain it :)
props to @joncloud for https://github.com/joncloud/makensis-action-test and the nsis team that while have a horrible UX make relatively easy to use and rapid tools.
Note for review: I'm using linux to build the windows executable, this may need to be reviewed and we might want to switch to Windows if we can confirm building on linux causes a problem.
* CI: Use Windows to build the .zip
* CI: Leave log level at INFO for frontend tests
* CI: Disable frontend admin tests for non-admin workflow
* CI: Disable import/export rate limiting for frontend tests
* tests: fix importexport tests
The testing approach was redone to fix numerous issues:
* Even if the tests had been working, none of them would have caught
https://github.com/ether/etherpad-lite/issues/4808 because they
didn't exercise the client-side import logic. Now they do.
* Follow-up logic was not in the `helper.waitFor()` callback like it
should have been. Now the code uses `async` and `await` to ensure
proper execution order.
* All `$.ajax()` calls used `async: false`. Now they're properly
asynchronous.
* The `helper.waitFor()` condition callbacks threw instead of
returning false.
* The string comparisons didn't allow for different attribute
order (e.g., `<ol start="1" class="list-number1">` vs. `<ol
class="list-number1" start="1">`). Now `Node.isEqualNode()` is
used to reduce fragility. (`Node.isEqualNode()` is not perfect, so
the tests are still a bit fragile: If class names or style strings
are in a different order then `Node.isEqualNode()` will return
false even if the nodes are semantically equivalent.)
Co-authored-by: Richard Hansen <rhansen@rhansen.org>
Co-authored-by: Richard Hansen <rhansen@rhansen.org>
Due to a recent release that wasn't functioning properly this CI will help us catch the majority of Microsoft Node Quirks before they make it into a release.
I'm not sure how these tests ever worked. I guess some version of
Node.js and npm come pre-installed on the ubuntu-latest images?
I would have prefered to use Node.js v10 because that is our current
minimum supported version, but we have a surprising number of tests
that don't work on Node.js v10 (mostly due to `assert.match()`, which
was added in Node.js v12).
Richard Hansen