We've been doing manually for too long ;).
The reason why we're assigning the author is it makes it easy to filter
pull requests by assignee on our kanban; it isn't so easy (actually,
might be impossible) to filter by author.
Without this condition, the kanban assignment would be run on every
CONSUL fork and that would result in unpredictable results since they
would try to write on our kanban, and they don't have permission to do
so.
Note that, much to my dismay :D, the code only works if we use single
quotes in the name of the repository owner; it doesn't work if we use
double quotes.
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/
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.
