| Age | Commit message (Collapse) | Author | 
|---|
|  |  | 
|  |  | 
|  | 4963 import cron should abort old imports | 
|  | A new recurring job that does exactly the same thing as the import job.
This finalises `ComplianceCheckSet`s.
First we need to abort all unfinished `ComplianceCheckSet`s older than
four hours. Then we finalise the imports by doing the same work in
`Api::V1::Internals::ComplianceCheckSetsController#notify_parent`,
namely calling `#notify_parent` on `ComplianceCheckSet`s (here, only on
the ones that are finished).
Add a couple new Rake tasks for compliance check sets that mirror those
for imports, and do the work required by the cron job.
Refs #4758 | 
|  | After re-reading the ticket, I see now that the aborting of old imports
should only apply to `NetexImport`s. Update the code to make this
happen.
Refs #4963 | 
|  | As a result of a new requirement, before doing the existing work we were
doing in the imports cron job (notifying parent imports), we first need
to clear out old imports and mark them as 'aborted'.
Refs #4963 | 
|  |  | 
|  | This task will run every 5 minutes, synchronising parent imports with
the status of their children.
When all children have finished, if none of them have failed, the parent
import should get a status of "successful":
    WorkbenchImport status: :successful
      NetexImport status: :successful
      NetexImport status: :successful
When all children have finished, if any of them have failed, the parent
import should get a status of "failed":
    WorkbenchImport status: :failed
      NetexImport status: :failed
      NetexImport status: :successful
We need a Cron job for this instead of being able to do it via a Ruby
method because the thing that's setting the status on the sub-imports
when they're complete is the STIF Java IEV application. Thus there's no
way for our Ruby code to know that a sub-import has finished. Because of
that, we do this polling mechanism every five minutes to update the
imports that need updating.
Created a Rake task to use in the Whenever schedule because the `runner`
method from Whenever expanded to `script/rails`, which is a bloody
ancient file, and tries to run via JRuby lolwat. Didn't want to bother
adding a configuration to Whenever to use something more modern, and
didn't know whether the binstub in `bin/` for `rails` is available since
we don't commit those to the repo apparently (although I knew that fact
from before).
Refs #3511 | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  |  |