- added 2 new types
- modified the models to get data through graphQL
- modified the corresponding spec
- also testing that hidden comments do not show up
- modified comments specs bc now it returns comments on budget
investments
Most of it was up-to-date, except for the fact that Consul Democracy
already uses Rails 7.0 and that it's possible to use different languages
per tenant since commit 6de4737b7.
The test "request a translation of an already translated text" was
failing sometimes on our CI since August 29, maybe due to a change in
GitHub Actions since the test had been passing for a year and a half and
we didn't change any code around that time (we were updating the
documentation). While the root cause is unknown, debugging shows that
sometimes (usually the first time this test is executed on our CI, and
only the first time, since running it 600 tests in a row also resulted
in only one failure) the request done by clicking on "Traducir página"
is done with a user session where the locale is in English.
This doesn't make much sense, since both user sessions are already in
Spanish (and we had either explicit or implicit expectations to confirm
that), and debugging shows that the session is indeed in Spanish during
the previous request.
In any case, we're solving it by never using English during the test,
since it wasn't necessary; it was only done that way because all the
tests on this file used the language selector to get to the Spanish
pages. We're simplifying some of the other tests the same way.
The test failure was:
```
Failure/Error: expect(page).to have_content "Se han solicitado
correctamente las traducciones"
expected to find text "Se han solicitado correctamente las traducciones"
in
"Idioma: \n
\nEnglish\nDeutsch\nEspañol\nFrançais\nNederlands\nPortuguês
brasileiro\n中文\n
Entrar\nRegistrarse\nDebates\nPropuestas\nVotaciones\nLegislación
colaborativa\nPresupuestos participativos\nODS\nAyuda\n×\nTranslations
have been correctly requested.\nPropuestas más activas\nAhora mismo no
hay propuestas\nDebates más activos\nndfrrqufrp\nVer todos los
debates\nProcesos abiertos\nAhora mismo no hay procesos
abiertos\nGobierno abierto\nEste portal usa la aplicación CONSUL
DEMOCRACY que es software de código abierto.\nParticipación\nDecide cómo
debe ser la ciudad que quieres.\nCONSUL DEMOCRACY, 2024 Política de
privacidad Condiciones de uso Accesibilidad"
```
Note that most of the text is in Spanish (as expected) but the flash
message itself is in English.
In the past, having this kind of expectations after the process running
the browser has started has resulted in flaky issues with the database
connection.
In one case, we're removing the test because there are controller tests
covering the same scenario and a system test checking what happens from
the user perspective.
In the other case, we're replacing the expectations with expectations
from the user's point of view.
We were using the same setup in these tests, and we were only changing
the expectations or adding an extra step.
Note we're also using `refresh` to simplify the code and because we were
using `select "Español", from: "Idioma:"` when that language was already
selected.
After changing the language, we were checking that certain content isn't
there.
However, the content wasn't there before changing the language either,
so the test will pass even if the request to change the language hasn't
finished.
Although this is probably OK because we aren't changing the language
using an AJAX request, and so Capybara will correctly wait until the
request is finished before finishing the test, confirming that the page
has changed after a request is something we try to do in every test.
The alternative text of the image was useless, and we were depending on
an external server in order to display it. Furthermore, the text inside
the image was pretty small.
So we're displaying the output of the command as plain text.
There was a typo where we said we were creating the containers but we
were building the image.
While none of these commands are necessary because they're run
automatically when first running the `db:create` rake task, I think it's
better to show them separately, since the `build` command might be used
to rebuild the image, and running the `create` command separately makes
it easier to know what's going on.
We're also removing the "start database service" step, since it's
automatically started because the app service depends on it.
Finally, we're updating one command for macOS.
Docker and Docker Compose are included in most Linux distributions, and
we don't know whether the windows error we talked about is still
relevant in 2024. In any case, the Docker documentation to install
windows is a better resource for that than our documentation.
We're also using the same Docker commands for every operating system.
Other than checking typos and styling, we're removing references to
"Main URL" (which isn't used since commit f87165851), and updating the
process to configure the map.
In a fork of Consul Democracy, people can use the `:consul` task on a
test that is relevant in the original Consul Democracy but doesn't apply
to them due to their custom changes. So we're excluding tests with this
tag when running the test suite.
Knapsack 7, which we adopted in commit 070cb3185, changed the way to
exclude these tags in RSpec when using Queue Mode [1]. It now ignores
the `filter_run_excluding` option, so we have to pass the argument
directly to the knapsack task.
We're still keeping the `filter_run_excluding` option so it's used when
running the tests on a development machine. The downside, of course, is
that now we have duplicate code.
[1] https://github.com/KnapsackPro/knapsack_pro-ruby/blob/master/CHANGELOG.md#700
Using a recent version of Docker Compose, we were getting a warning:
```
docker-compose.yml: the attribute `version` is obsolete, it will be
ignored, please remove it to avoid potential confusion
```
This attribute is obsolete since Docker Compose 1.27, released in 2020,
so most developers won't be affected by this change. Developers using
really old versions of Docker Compose might have to upgrade their Docker
Compose.
We were getting warnings in our CI:
> Legacy key/value format with whitespace separator should not be used
> LegacyKeyValueFormat: "ENV key=value" should be used instead of legacy
> "ENV key value" format
So we're updating the code as mentioned in the Docker documentation [1]
[1] https://docs.docker.com/reference/build-checks/legacy-key-value-format/
We're using version 13 because it's the one included in Debian Bullseye,
which is the operating system we currently use in our Dockerfile.
For consistency, we're using the same version in GitHub Actions.
Note this image requires setting a password. Otherwise we get an error:
> Database is uninitialized and superuser password is not specified.
> You must specify POSTGRES_PASSWORD to a non-empty value for the
> superuser. For example, "-e POSTGRES_PASSWORD=password" on
> "docker run".
Since now we're setting a password in the postgres service, we also need
to provide the `PGPASSWORD` environment variable (or to specify the
password in the `database.yml` file, which we do for GitLab since it
uses a separate database configuration file). Otherwise we get an error:
```
PG::ConnectionBad: connection to server at "::1", port 5432 failed:
fe_sendauth: no password supplied (PG::ConnectionBad)
```
When creating the Dockerfile, we run `npm install`, which creates a
`node_modules` folder inside the working directory.
However, when using docker-compose, we overwrite the contents of that
working directory (/var/www/consul) with the contents of the host
machine's working directory. This means that, unless the `npm install`
command is run on the host machine to create a `node_modules` folder on
the host machine (which would pretty much defeat the point of using
Docker), the container won't have a `node_modules` folder and the
application won't run.
So we're defining a volume in docker-compose.yml to make sure we keep
the container's `node_modules` folder.
When running delayed_job on reboot using Consul Democracy 2.2.0, we were
getting an error:
```
`require': cannot load such file -- sassc-embedded (LoadError)
from <internal:rubygems/core_ext/kernel_require.rb>:86:in `require'
from config/application.rb:1:in
```
No idea why this gem isn't detected when running `bin/delayed_job`.
When deploying with Capistrano, we use `bundle exec bin/delayed_job`,
and that works fine, so we're using it here as well.
We had already fixed this issue in the Cosul Democracy installer [1],
but forgot to configure the Cron job to do the same.
[1] https://github.com/consuldemocracy/installer/commit/3dc69eb6
The resolution of most devices is at least 640 pixels in at least one of
their dimensions. Since we need the width to be smaller than 640 pixels,
having a height of 479px wasn't realistic.
Doing so caused the tests checking the sticky "support proposal" tests
to fail because on 480px-high devices the sticky message covers the
whole screen.
This is a usability issue, but since I'm not sure how many people use
such a small window when browsing the web, for now I'm simply changing
the tests.
We're changing the width to 320px since it's the width required by the
Web Content Accessibility Guidelines 2.2. Quoting these guidelines [1]:
> Content can be presented without loss of information or functionality,
> and without requiring scrolling in two dimensions for:
> * Vertical scrolling content at a width equivalent to 320 CSS pixels;
> * Horizontal scrolling content at a height equivalent to 256 CSS
> pixels.
Note that, using a height of 256px, the sticky message would make the
application unusable, though. IMHO we'll have to get rid of the sticky
message sooner or later.
Since August 29, probably due to a change in the browser used by GitHub
Actions (since branches whose code we didn't change were suddenly
affected that day), many tests related to proposals are failing on
GitHub Actions. Although every time the test suite is run different
tests fail, on each run at least half a dozen tests fail.
Most tests have one thing in common: they click on an element on the
`proposals#show` page, and the click isn't done correctly.
One possible explanation is that the video included on the page causes
the page to scroll at the exact same time that Capybara is clicking on a
link, which results in a misclick.
I haven't been able to reproduce the issue on my machine, so I'm not
sure whether giving the video element a fixed height using CSS (so the
page doesn't scroll when the iframe is loaded) could solve the issue.
But, after using proposals without videos in the tests (except the tests
testing the videos themselves), all these tests are passing in the test
suite.
So, for now, we're simply removing the videos in the proposal factories.
Note this issue wasn't caused by the "no cookie" changes done in commit
ee64efe659, since running the tests in Cosul Democracy 2.1.1 (which
didn't contain those changes) also fails on GitHub Actions.
