This way we'll be able to customize some of the rules, which doesn't
seem to be possible when using the `.mdlrc` file.
For simplification purposes, instead of including all rules one by one,
we're excluding the few rules we don't use.
Since the page contains an <h1> tag (the title of the issue), the main
headings of this file should be level 2 headings.
We're removing the "How" section in the flaky specs template for
simplicity (and because we usually don't use this template at all).
Note that MDL reports that the first heading should be a level 1
heading, but, as mentioned earlier, this doesn't make sense in the
context of a github issue. We'll probably exclude these files from MDL
checks in order to avoid this issue.
These files are essentially the same as our README files, only our
README files contain information that only makes sense in the context
of a repository.
On GitBook, currently Spanish and English belong in different spaces, so
we're going to provide two different github integrations (one per
language).
So we're using a different SUMMARY.md file per language.
For consistency, since there was a link to the README file in the
Spanish summary, we're also adding it to the English one. It was working
in any case because on our current gitbook page the summary was
generated through gitbook.
Since we no longer have any of the files referenced in the
`.gitbook.yaml` file, we're removing it as well.
Note that there was a typo in the English summary, which pointed to the
Spanish license. It didn't matter, though, since the license file is
actually in English in both cases.
These files were both in the Consul Democracy repository and the
documentation repository. Since now both repositories have been merged
into one, we can remove the duplicate files.
Note there was a small difference in the `.mdlrc` file because we
changed it in commit b3a718ae6. We're keeping this change so we don't
get these syntax warnings in the documentation.
The main reason for this change is that Pronto doesn't run in pull
requests opened by external contributors, and we haven't found how to
fix this issue.
Another reason is that Pronto only detects issues in the lines where the
changes are done, but sometimes we introduce issues related to other
lines and those aren't detected by Pronto. Also, when adding or changing
Rubocop rules, or when we update Rubocop, Pronto doesn't check whether
those rules are applied in every Ruby and ERB file, and we sometimes
forget to do so (particularly in ERB files).
So, from now, the linters will check all the code in every pull request.
Note we're now excluding the `vendor` folder in our linters because the
`setup-ruby` action actions generates a `vendor/bundle/` folder with all
our gem dependencies, and we don't want to check those files.
We had the `*` because, in the past, pull request could be opened by
either dependabot or dependabot-bot. That's no longer the case since we
started using dependabot v2.
We can't simply remove the nesting selector in this case since it's
inside a `:not` pseudo-class. Removing the nesting selector would cause
a syntax error.
This file was generated by a different developer who ignored the nesting
rules. Refactoring it has been in our TODO list for years, but we
haven't done it yet.
Since we want stylelint to check that there are no errors after the
changes in a pull request, but we've still got errors in this file,
we're ignoring them for now.
Since now we aren't just using ESLint in the context of a pull request
(with pronto-eslint), we're also adding the `ignorePatterns` option so
it ignores third-party files.
Note we're using ESLint 8 because ESLint 9 doesn't support our
`.eslintrc` configuration file, which we need because it's required by
pronto-eslint. However, when running pronto-eslint, we're using ESLint 6
(I think); this means that now the eslint command we run in development
and the one run by pronto might behave differently, particularly if we
add rules that have been introduced in ESLint 7 or 8. For now, since we
generated the `.eslintrc` file using ESLint 6.0.1, everything works as
expected in both situations.
We're excluding these files because they use `raw` to render content
than only administrators can edit, and we trust administrators not to
provide unsafe HTML. We should definitely sanitize them at some point
but, at the same time, we should also try to keep compatibility in
installations taking advantage of `raw`.
Also note that ERB Lint does not allow customizing the severity of a
linter; if it ever does, we'll use the severity rule instead of
excluding files.
In commit 9329e4b6e, `try` was added because there was a case where this
partial was rendered and the `current_booth` method didn't exist.
However, that's no longer the case since commit d5c7858f6. Since then,
this partial is only rendered in the officing section, where the
`current_booth` method is defined.
So we can use the safe navigation operator instead of `try`.
In commit 35659d441, we started using an <svg> tag instead of an <img>
tag to render avatars. That meant that the `vertical-align: middle` rule
we've got for images was no longer being applied.
So we're adding it back.
The only places where this icon wasn't rendered correctly were "my
account" and the show action in the users controller. The comments were
not affected because we've got a `float: left` rule for the
`comment-avatar svg` selector, which causes the browser to ignore the
value of the `vertical-align` propertly, and the avatars showing author
information were not affected because the `.author-photo` selector
already had a `vertical-align` rule.
We were doing it most of the time, but in some cases we were clicking
the "Sign out" link instead. These actions aren't the same, just like
using `login_as` is not the same as visiting the sign in page and
submitting the form.
Some of these tests failed sometimes because the user wasn't signed in
after using `login_as`. One possible cause could be that we weren't
adding an expectation after clicking the "Sign out" link.
So using `logout` adds consistency, simplifies the code, and might
reduce the chance of these tests failing in the future (although they
might still fail in the future because some of these tests check the
database after a `visit` call).
In this test, we were signing out after confirming a vote, but we
weren't waiting for the request to finish before using the `login_as`
method. Sometimes this test failed with a screenshot showing that the
user wasn't signed in after the `login_as` call, so this might have been
the cause.
We could use the `logout` method instead, but since we don't have any
other tests that click the "Sign out" link from the officing area, we're
leaving it as it was; we might change it to `logout` in the future if
the test keeps failing once in a while.
Note we're also replacing a `visit` call which my guess is was there
because the "Sign out" link wasn't visible due to the notice covering
it. So we're closing the notice instead.
We use caching in our application in two different ways:
1. Rails.cache.fetch in models/controllers/libraries
2. Fragment caching in the views
When using Rails.cache.fetch, we usually set an expiration date or
provide a precise way to invalidate it. If the code changes and the
information stored in the cache is different from what the new code
would return, it's usually not a big deal because the cache will expire
in an hour or a day. Until commit a4461a1a5, the statistics were an
exception to this rule, but that's no longer the case. The actual
exception to this rule are the i18n translations, but the code caching
them is very simple and hasn't changed for more than three years (when
it was written for the first time).
When using fragment caching, on the other hand, Rails automatically
invalidates the cache when the associated _view code_ changes. That is,
if a view contains cache, the view renders a partial, and the partial
changes, the cache is correctly invalidated. The cache isn't invalidated
when the code in helpers, models or controllers change, though, which
the Rails team considers a compromise solution.
However, we've been moving view partials (and even views) to components,
and the cache isn't invalidated when a component changes (it doesn't
matter whether the component Ruby file or the component ERB file
changes). That means that the cache will keep rendering the HTML
generated by the old code.
So, now, we're clearing the cache when upgrading to a new version of
Consul Democracy, as part of the release tasks. That way, institutions
upgrading to a new version don't have to worry about possible issues
with the cache due to the new code not being executed.
I was thinking of adding it to a Capistrano task, but that would mean
that every time people deploy new code, even if it's a hotfix that
doesn't affect the cache at all, the cache would be cleared, which could
be inconvenient. Doing it in a release, that usually changes thousands
of lines of code, sounds like a good compromise.
The upload-artifact action does not support using the same artifact name
in different jobs (or in different matrix scenarios) since version 4,
which we started using in commit acfaada82. That meant that screenshots
were not uploaded correctly when two or more knapsack nodes failed.
Since we upgraded to Rails 7.0 in commmit 8596f1539, the screenshots
started to be stored in `tmp/capybara`, so the step uploading
screenshots wasn't doing anything.
