New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refs #10755 - Recurring actions, job invocation task groups #44
Conversation
@adamruzicka, this pull request is currently not mergeable. Please rebase against the master branch and push again. If you have a remote called 'upstream' that points to this repository, you can do this by running:
This message was auto-generated by Foreman's prprocessor |
request for rebase :-) |
@@ -31,6 +31,11 @@ def create | |||
ForemanTasks.delay action, | |||
job_invocation.delay_options, | |||
job_invocation | |||
elsif job_invocation.trigger_mode == :recurring |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
case job_invocation.trigger_mode
might work better than if/elsif here
@adamruzicka, this pull request is currently not mergeable. Please rebase against the master branch and push again. If you have a remote called 'upstream' that points to this repository, you can do this by running:
This message was auto-generated by Foreman's prprocessor |
2ec2fb6
to
7496e12
Compare
Did another set of testing, the new version, with middleware works much intuitively. |
|
||
def delay(delay_options, job_invocation) | ||
def delay(delay_options, job_invocation, locked = false) | ||
task.add_missing_task_groups(job_invocation.task_group) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, the iterations after the first one don't have their own job invocation instance, so that the events are not shown in job invocations index, so we then can't track status from the job perspective then. We should check here, and in case the job has already a task, we should clone the invocation, rather than use the current one.
Also, since we're mapping the job invocation to 0-1 tasks, we should rename 'last_task_id', to just 'task_id'.
It should be nice, to be able to get to the recurring logic details, where one would be able to get to the next jobs of belonging the the recurring logic group etc. |
This needs rebase :-( |
629a48e
to
68ef136
Compare
@iNecas all the comments should be addressed |
When using
Debugging showed that the |
@@ -0,0 +1,9 @@ | |||
class AddJobInvocationTaskGroup < ActiveRecord::Migration | |||
def up | |||
add_column :job_invocations, :task_group_id, :integer, :index => true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Foreign key?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. Should I add the database constraint or can we allow a job invocation to have no task group?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK you can have foreign key on nullable fields - it should check the contraint just on the case, when the field is entered.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, I'll add the constraints
Should be fixed in adamruzicka/foreman-tasks@20cf8ea |
@@ -0,0 +1,9 @@ | |||
class AddTriggeringToJobInvocation < ActiveRecord::Migration | |||
def up | |||
add_column :job_invocations, :triggering_id, :integer, :index => true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Foreign key again?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again, yes. A job invocation could be created without a triggering so it made sense to me not to enforce the association
Looks better every iteration: from the last testing (some comments might apply to the foreman-tasks PR):
|
addressed in adamruzicka/foreman-tasks@8ee423e
In recurring logic detailsShows type of the resource and count per type, links to job invocations index filtered by the recurring logic id In job invocation detailsShould this show the resources related to the recurring logic too? |
The default time for future execution works for new invocations, but still missing when using the re-run. Minor, but still nice to have enhancement. |
Waiting for theforeman/foreman-tasks#141 to get released |
1bf6411
to
1e56517
Compare
Waiting for rubocop and squash |
416a537
to
2fa2ed3
Compare
No other reasons for not getting this into master. Merging now. Thanks @adamruzicka |
Refs #10755 - Recurring actions, job invocation task groups
requires theforeman/foreman-tasks#141