| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is one of those situations where you go in to make a small change,
see an opportunity for some refactoring, and get sucked into a rabbit
hole that leaves you wondering if you have any idea how computers
actually work. My initial goal was simply to update the Erlang version
used in our binary packages to a modern supported release. Along the
way I decided I wanted to figure out how to eliminate all the copypasta
we generate for making any change to this file, and after a few days of
hacking here we are. This rewrite has the following features:
* Updates to use Debian 11 (current stable) as the base image for
building releases and packaging repos.
* Defaults to Erlang 24.2 as the embedded Erlang version in packages.
* Dynamically generates the parallel build stages used to test and
package CouchDB on various OSes. This is accomplished through a bit
of scripted pipeline code that relies on two new methods defined at
the beginning of the Jenkinsfile, one for "native" builds on macOS
and FreeBSD and one for container-based builds. See comments in the
Jenkinsfile for additional details.
* Expands commands like `make check` into a series of steps to improve
visibility. The Jenkins UI will now show the time spent in each step
of the build process, and if a step (e.g. `make eunit`) fails it will
only expand the logs for that step by default instead of showing the
logs for the entire build stage. The downside is that if we do make
changes to the series of targets underneath `check` we need to
remember to update the Jenkinsfile as well.
|
|
|
|
|
| |
It seems different versions of mix cannot agree on how these lines
ought to be formatted, so let's try to help out.
|
|
|
|
|
|
|
|
| |
This makes it easier to observe the pipeline progres in the UI. We get
timings for each step in the build, and if one of the steps fails the
logs for that step will be the only ones expanded by default. We can
also label each of the steps to provide a bit more context to the
developer about what the CI pipeline is actually doing.
|
|
|
|
|
|
|
|
|
| |
This avoids the situation where a build fails with a timeout because
all the docker-based agents were busy running other jobs. Jenkins'
semantics for options.timeout is that the stage-specific timeout starts
the countdown even while waiting for an agent matching the selected
label to become available. We see occasional spurious job failures as a
result.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of building one image with all supported Erlang versions through
kerl, this configuration looks for a specific container image for each
Erlang version. Decoupling it like this enables us to more easily adopt
newer distros for newer Erlang versions, and to build new images with
patch releases of Erlang without needing a simultaneous PR to the
CouchDB repo to pick them up in CI (although some change to Jenkins
might be needed to avoid images being cached for too long when a stable
tag changes).
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Win32-SM91 support and fixes
* spidermonkey_68 identified as spidermonkey_60 and erroneously(?) blocked by configure on aarch64 #3149
* remove unnecessary shell when setting ERL_AFLAGS
* fix foundationdb urls in github workflow
* quote AFLAGS like win echo and fix references to pwd
Co-authored-by: Will <w.young@schaetz-cro.ch>
|
| |
|
| |
|
|\
| |
| | |
Always send all cookie attributes
|
|/ |
|
| |
|
|\
| |
| | |
Add SameSite setting when clearing session cookie
|
|/ |
|
| |
|
|
|
|
|
|
|
| |
Should fix:
```
Warning: A secret was passed to "mail" using Groovy String interpolation, which is insecure.
```
|
|
|
|
|
|
|
|
|
|
| |
I didn't touch the mango-test invocation because it confused me. I'm
not sure how Python.exe and dev\run are interacting there.
I'm also not sure about forward vs. backslash in these quoted mix
invocations. I stuck with the convention I saw already in the Makefile;
i.e. forward slashes for regular arguments to dev\run, backslashes for
quoted arguments to the mix invocation issued by dev\run.
|
|
|
|
|
| |
* Eliminate remaining use of TEST_OPTS
* Standardize dev/run invocation, matching elixir-integration
|
|
|
|
|
|
| |
This also allows us to eliminate the `check-all-tests` target, since
we've re-enabled all the test suites (and excluded specific tests as
needed).
|
|
|
|
| |
Frankly I have no idea what this does, but it doesn't seem relevant.
|
|
|
|
|
|
|
|
|
|
|
| |
I removed the `elixir-init` dependency from everything except the
`elixir-suite` target. The other targets are likely to be run
interactively, in which case mix will ask if the local rebar / rebar3
etc. should be installed if they're not already (and they almost always
will be). A little less log cruft, a little more speed.
I also removed `MIX_ENV` exports where their inclusion didn't seem to
matter, e.g. on the code formatting and static analysis checks.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Two main pieces of work here:
1) Consoidate elixir / elixir-only / elixir-suite into two targets:
- elixir-integration, which only runs ExUnit integration tests
- elixir-suite, which depends on elixir-integration and also calls
format + credo
This preserves the flexibility of the previous targets while reducing
code duplication and removing some obsolete configurations
2) Limit the number of places where we define test configurations
Previously we were relying on dev/run to inject config entries in
addition to specifiying a .ini file on the command-line. We sometimes
also write config settings in the test definitions themselves. This is
at least an initial attempt to just define the config settings in one
place.
|
|
|
|
|
|
| |
This is the result of running
MIX_ENV=integration mix suite > test/elixir/test/config/suite.elixir
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code that generates suite.elixir will repeatedly strip the "test "
from the name of the test when writing the file, resulting in a mismatch
between the actual test name and what's in suite.elixir. You can see
this by searching for e.g. COUCHDB-497 in the suite file.
I tried using String.replace_prefix instead of String.replace_leading in
test_name() but that function seems to get called multiple times during
the test grouping. Simpler to just avoid naming the tests that way for
now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have been redundantly excluding tests by listing them in the
skip.elixir file and also adding a `:pending` or `:skip` tag. Output of
`elixir-suite` before:
Finished in 88.4 seconds
306 tests, 0 failures, 16 excluded, 1 skipped
and after:
Finished in 85.8 seconds
438 tests, 0 failures, 135 excluded, 1 skipped
|
|
|
|
|
|
|
|
|
|
|
| |
The intent here is to require "branch must be up to date
before merge / squash / rebase", and to further require a clean bill of
health from Jenkins for `main` and `3.x`. I'm not so confident about
the CI health of older branches to enable that protection there, and at
any rate it's unlikely we'd be committing anything to those branches
anyway.
Co-authored-by: Glynn Bird <glynnbird@apache.org>
Co-authored-by: Adam Kocoloski <kocolosk@apache.org>
|
| |
|
| |
|
|
|
|
|
| |
This change tags all tests that are currently failing against main with
a `pending` tag that is then excluded.
|
|
|
|
| |
Quorum is no longer a thing now that we rely on FoundationDB.
|
|\
| |
| | |
support maximum changes_duration configuration option
|
|/ |
|
|\
| |
| | |
Fix logic in ensure_exunit_started
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of running as a single test, separate each corresponding field
and error into its own test, with its own timeout. A typical run now
looks like:
make eunit apps=couch_views suites=couch_views_batch_impl tests=bad_config_test_
======================== EUnit ========================
couch_views_batch_impl:186: bad_config_test_ (batch_initial_size)...[0.104 s] ok
couch_views_batch_impl:186: bad_config_test_ (batch_search_increment)...[0.077 s] ok
couch_views_batch_impl:186: bad_config_test_ (batch_sense_increment)...[0.074 s] ok
couch_views_batch_impl:186: bad_config_test_ (batch_max_tx_size_bytes)...[0.077 s] ok
couch_views_batch_impl:186: bad_config_test_ (batch_max_tx_time_msec)...[0.076 s] ok
couch_views_batch_impl:186: bad_config_test_ (batch_threshold_penalty)...[0.074 s] ok
=======================================================
All 6 tests passed.
Previously, these tests were timing out when CI became resource
constrained. Examples of multiple runs show how prone to timing out
after 5 seconds the old monolithic bad_config_test was:
couch_views_batch_impl: good_config_test...[0.217 s] ok
couch_views_batch_impl: bad_config_test...[1.347 s] ok
couch_views_batch_impl: good_config_test...[0.393 s] ok
couch_views_batch_impl: bad_config_test...[2.332 s] ok
couch_views_batch_impl: good_config_test...[0.358 s] ok
couch_views_batch_impl: bad_config_test...[2.211 s] ok
couch_views_batch_impl: good_config_test...[0.942 s] ok
couch_views_batch_impl: bad_config_test...*timed out*
couch_views_batch_impl: good_config_test...[1.179 s] ok
couch_views_batch_impl: bad_config_test...*timed out*
couch_views_batch_impl: good_config_test...[0.497 s] ok
couch_views_batch_impl: bad_config_test...*timed out*
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This doubles the default timeout to 10 seconds for these two tests.
They typically take a long time to run:
couch_views_active_tasks_test:69: active_tasks_test_ (verify_basic_active_tasks)...[2.444 s] ok
couch_views_active_tasks_test:70: active_tasks_test_ (verify_muliple_active_tasks)...[2.678 s] ok
couch_views_active_tasks_test:69: active_tasks_test_ (verify_basic_active_tasks)...[2.646 s] ok
couch_views_active_tasks_test:70: active_tasks_test_ (verify_muliple_active_tasks)...[2.743 s] ok
couch_views_active_tasks_test:69: active_tasks_test_ (verify_basic_active_tasks)...[2.910 s] ok
couch_views_active_tasks_test:70: active_tasks_test_ (verify_muliple_active_tasks)...[3.063 s] ok
and when resources are constrained, often time out:
couch_views_active_tasks_test:69: active_tasks_test_ (verify_basic_active_tasks)...[2.044 s] ok
couch_views_active_tasks_test:70: active_tasks_test_ (verify_muliple_active_tasks)...*timed out*
couch_views_active_tasks_test:69: active_tasks_test_ (verify_basic_active_tasks)...[1.777 s] ok
couch_views_active_tasks_test:70: active_tasks_test_ (verify_muliple_active_tasks)...*timed out*
couch_views_active_tasks_test:69: active_tasks_test_ (verify_basic_active_tasks)...*timed out*
couch_views_active_tasks_test:70: active_tasks_test_ (verify_muliple_active_tasks)...*timed out*
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Suppress excessive debug logging of the form:
mix test --cover --trace src/chttpd/test/exunit/pagination_test.exs:232
* test Legacy API (10 docs) : _all_docs/queries
12:40:01.895 [debug] [user: "adm", what: :login_attempt]
12:40:01.906 [debug] [username: 'adm', what: :successful_cookie_auth]
12:40:01.925 [debug] [username: 'adm', what: :successful_cookie_auth]
12:40:01.934 [debug] [username: 'adm', what: :successful_cookie_auth]
12:40:01.944 [debug] [username: 'adm', what: :successful_cookie_auth]
12:40:01.952 [debug] [username: 'adm', what: :successful_cookie_auth]
12:40:01.960 [debug] [username: 'adm', what: :successful_cookie_auth]
12:40:01.968 [debug] [username: 'adm', what: :successful_cookie_auth]
12:40:01.977 [debug] [username: 'adm', what: :successful_cookie_auth]
12:40:01.985 [debug] [username: 'adm', what: :successful_cookie_auth]
12:40:01.995 [debug] [username: 'adm', what: :successful_cookie_auth]
12:40:02.004 [debug] [username: 'adm', what: :successful_cookie_auth]
12:40:02.013 [debug] [username: 'adm', what: :successful_cookie_auth]
12:40:02.019 [debug] [username: 'adm', what: :successful_cookie_auth]
* test Legacy API (10 docs) : _all_docs/queries (152.2ms)
|
| |
|
|
|
|
| |
See: https://github.com/apache/couchdb/commit/3907e9f0abd2bfc26e8384a819939ea964daf157
|
| |
|
|
|
|
|
|
| |
Fixes this warning:
couchdb/src/couch_eval/src/couch_eval.erl:168: Warning: this clause cannot match because a previous clause at line 167 always matches
|
|
|
|
|
|
| |
Use couch_eval when filtering docs with a filter function or a map
function. This allows CouchDB to configured to use different engines
through couch_eval.
|
| |
|
| |
|