So now, newly opened pull requests will automatically be added to the
"Reviewing" column, while newly opened draft pull requests will
automatically be added to the "Doing" column.
I've added the "reopened" event just in case (and was indeed very useful
while testing this feature), although we rarely reopen pull requests.
Note that this only works on pull requests that aren't already in the
project; that is, if a pull request is already in the "Doing" column,
closing it and reopening it will *not* move it to the "Reviewing
column".
So it looks like we won't easily be able to extend this feature in order
to automatically move pull requests when they're marked as ready for
review.
Since the target branch was in a different repository, the action failed
since it couldn't find the reference.
The code here is based on a recent change in Pronto [1] and with a comparison
between the repo.url property of pull_request.head and pull_request.base
to determine if the pull request was created from a forked repository
[1] https://github.com/prontolabs/pronto/commit/4fe28418b6
Sometimes a test gets stuck and and we have to wait until it times out
in order to check which files were being tested at the time.
The default timeout is six hours. I'm reducing it to one hour which
should still be plenty of time even on repositories with no knapsack
token.
Somehow I thought it worked automatically, but we had to provide the
token.
The configuration is based on Coveralls instructions to run parallel
builds [1].
Alternatively we could use the Coveralls GitHub Action [2] which
slightly simplifies the workflow configuration and removes the
dependency of the coveralls gem. However, it also adds a dependency on
simplecov-lcov and requires configuring it to renerate LCOV files on
each run, so the benefits of using it are not that big.
[1] https://docs.coveralls.io/parallel-build-webhook
[2] https://github.com/coverallsapp/github-action/
Due to a bug in dependabot (see issue 2198 in the
`dependabot/dependabot-core` repository), Dependabot would open pull
requests on every fork, which would be inconvenient.
So we're disabling the updates until this issue is fixed; since we
currently have almost 50 open pull requests, it shouldn't affect us that
much.
These lines were added when we were trying the pronto-eslint_npm gem,
which isn't maintained anymore and is not compatible with the latest
Pronto version.
Since we're now using the pronto-eslint gem, and this gem depends on the
eslintrb gem (which includes ESLint), we don't need these lines anymore.
This way developers can run the checks on their machines and using
`bundle exec` we guarantee the right versions of all our gems are being
used; with Hound we can only use the versions supported by their
service.
When including the pronto-erb_lint gem, we're getting errors in
development where our ERB does not follow the conventions Better HTML
expects. Since we only use Better HTML because ERB Lint depends on it,
and right now we are not ready to follow its conventions, we're
disabling it.
Note pronto depends on rugged, which requires CMake and pkg-config to
build the `libgit2` library it depends on. CMake and pkg-config are
installed by default in some GNU/Linux distributions like Ubuntu, but
might not be installed on other systems, so we're adding them as
development dependencies.
Using GitHub Actions has a few advantages over using Travis CI:
* More jobs can be run in parallel
* All CONSUL repositories on GitHub will be configured automatically
Besides, Travis have recently changed their policy twice. First, they
announced their site for free software projects would be shut down but
free software projects could still use their site for private projects.
And then, they limited the usage of their services for free software
projects.
Just like we used to do with Travis, we're enabling builds for pull
requests but not for pushed branches.
We're also building the master branch. Even if we never push to the
master branch directly, we're aware other CONSUL repositories do, so
we're running the tests for this case.
The actual PR template feels more like bureaucracy than an actual guide
or checklist to help the PR author explain all important thigs that any
reviewer or changelog reader may need to understand.
We'll be moving most of the redundant things (like remembering tests are
needed, or explaning how things where implemented with a clear and
granular commit history) into a Wiki/Doc entry.
For regular contributors there is no need for reminders, we need to
improve new contributors landing with good guides and lowering the bar
for first PR's
Why:
* The template tried to specify a placeholder for the title, but instead it was used as first line in the description
* The template tried to specify a guide for each section with a `>` character to imply it was a comment, but people didn't remove it
How:
* Removing the first line specifying the title placeholder that has no use
* Changing the `>` character on each section guide for a `-` that can be easily reused for enumerations
