Incoming shares are no longer automatically added to the file list of
the sharee. Instead, the user now needs to explictly accept the share.
Currently shares can be accepted only from the Notifications app, so it
must be explicitly cloned before installing Nextcloud if it is not found
in the "apps" directory. Note that the development branches are already
built, so there is no need to explicitly build the app.
With the new sharing behaviour the "share a skeleton file with another
user before first login" scenario is no longer valid (as the user will
need to log in to accept the share, so at that point the skeleton is
already created), so it was removed.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
In order to run the acceptance tests in Apache "/var/www/html" has to be
linked to the root directory of the Nextcloud server. Before this was
automatically done when launching the acceptance tests through
"./run.sh", but an explicit command was needed when run in Drone. Now
the linking was moved from "run.sh" to "run-local.sh", so it is
automatically done when run through "./run.sh" and in Drone, including
when running the tests for an app instead of for the server.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before each scenario of the acceptance tests is run the Nextcloud server
is reset to a default state. To do this the full directory of the
Nextcloud server is commited to a local Git repository and then reset to
that commit when needed.
Unfortunately, Git does not support including empty directories in a
commit. Due to this, when the default state was restored, it could
happen that the file cache listed an empty directory that did not exist
because it was not properly restored (for example,
"data/appdata_*/css/icons"), and that in turn could lead to an error
when the directory was used.
Currently the only way to force Git to include an empty directory is to
add a dummy file to the directory (so it will no longer be empty,
but that should not be a problem in the affected directories, even if
the dummy file is not included in the file cache); although Git FAQ
suggests using a ".gitignore" file a ".keep" file was used instead, as
it conveys better its purpose.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
As "selenium.server" is a simulated variable it is not recognized by
Mink, so it must be always replaced by its value in "behat.yml" before
the file is parsed by Behat.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
The "wd_host" parameter of Selenium2 sessions specify the URL used by
the Selenium driver to connect with the Selenium server. Thus, when the
Selenium server is at a different host or port than the default one (for
example, when run on Drone) the "wd_host" parameter must be set for each
of the Selenium2 sessions defined in "behat.yml".
The "BEHAT_PARAMS" environment variable, which extends the "behat.yml"
configuration file, was used for that. However, this required adding to
the "BEHAT_PARAMS" in "run-local.sh" each new session added to
"behat.yml", including those added in the acceptance tests of apps.
To address that limitation, this commit introduces a simulated variable,
"selenium.server"; just before the acceptance tests are run the
"selenium.server" variable in the "wd_host" parameter is replaced in the
"behat.yml" file used by the acceptance tests. Note that the file that
is modified is the one inside the Docker container used to run the
acceptance tests, so the original file is not touched.
Note that a simulated variable is needed because Behat does not support
overridding nor setting configuration parameters with environment
variables.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Due to a bug in the Mink Extension for Behat it is not possible to use
the "paths.base" parameter in the path to the custom Firefox profile.
"paths.base" is a special parameter in the Behat configuration that
refers to the directory in which "behat.yml" is stored. This comes in
very handy to set the path to custom Firefox profiles in the acceptance
tests for apps, as even if the "behat.yml" file belongs to an app its
paths are relative to the directory in which the tests are run, that is,
the "tests/acceptance" directory of the server.
Until the bug is fixed, just before the acceptance tests are run the
"paths.base" parameter in the path to the custom Firefox profile is
replaced by its value in the "behat.yml" file used by the acceptance
tests. Note that the file that is modified is the one inside the Docker
container used to run the acceptance tests, so the original file is not
touched.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Before, the domain was automatically added assuming that the
NextcloudTestServerContext had no parameters defined in the Behat
configuration. However, in order to use a helper for Apache it would
need to be specified in the configuration with something like:
- NextcloudTestServerContext:
nextcloudTestServerHelper: NextcloudTestServerLocalApacheHelper
The substitution now works both when a helper is specified and when it
is not; note, however, that providing custom parameters to the helper is
not supported, although they are not needed anyway so it is not really a
problem.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Apache sub-processes are run as the www-data user, and they need to be
able to write to the "apps", "config" and "data" directories, so they
have to belong to that user, and therefore the Nextcloud server has to
be installed and configured too as the www-data user. The PHP built-in
web server will still be run as the root user, but in that case the
owner of those directories makes no difference, so this is compatible
with both cases.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
When the acceptance tests were run they were always loaded from the
"tests/acceptance" directory of the Nextcloud server. Now it is possible
to set the directory used to look for the Behat configuration and the
Nextcloud installation script, which makes possible to run acceptance
tests for the apps too instead of only for the server (although if no
directory is explicitly given the tests for the server are the ones
run).
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
By default "127.0.0.1:4444" is used, so nothing needs to be set when the
acceptance tests and the Selenium server share the same network (like
when called by "run.sh").
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
By default "127.0.0.1" is used, so nothing needs to be set when the
Selenium server and the Nextcloud test server share the same network
(like when called by "run.sh").
Besides passing the domain to the acceptance tests the Nextcloud test
server configuration must be modified to see the given domain as a
trusted domain; otherwise the access would be forbidden.
Signed-off-by: Daniel Calviño Sánchez <danxuliu@gmail.com>
Joas Schilling
Arthur Schiwon
Daniel Calviño Sánchez