feat: Add job_interruptible option to danger-review template
-
Please check this box if this contribution uses AI-generated content (including content generated by GitLab Duo features) as outlined in the GitLab DCO & CLA
When using the danger-review component on Merge Requests, the job is by default not interruptible, this makes the feature of Auto-cancel redundant pipelines to break, since the danger-review is executed immediately on DAG pipelines, possibly incurring in additional costs of development pipelines when adding this component.
- Update README.md with new job_interruptible input description
- Modify template.yml to include job_interruptible parameter and apply it to the danger-review job
Merge request reports
Activity
added cicomponents label
Thanks for your contribution to GitLab @manuel.remote!
Did you know about our community forks? Working from there will make your contribution process easier. Please check it out!
- If you need help, comment
@gitlab-bot help
or come say hi on Discord. - When you're ready for a review, comment on this merge request with
@gitlab-bot ready
. - Tip: Start @gitlab-bot commands at the beginning of a new comment and do not wrap the command in quotes or backticks.
- We welcome AI-generated contributions! Read more/check the box at the top of the merge request description.
This message was generated automatically. You're welcome to improve it.
- If you need help, comment
added 1st contribution Community contribution workflowin dev labels
assigned to @manuel.remote
mentioned in issue #6 (closed)
@gitlab-bot ready
@manuel.remote thanks for the contribution! Could you please elaborate in the MR description why this change is necessary and what kind of problem it addresses? Thank you
Thanks folks here's the issue that I made this MR for: #6 (closed)
Hi @sdungarwal I have updated the MR description with it, is it clear enough?
@sdungarwal Thanks for the ping and @brytannia thanks for the guidance
@manuel.remote Great catch! Great contribution, thank you
The changes makes sense and I only left one suggestion to make the job interruptible by default. WDYT?
I've also verified the desired outcome via !10 (closed).
It'd be great to make the CI pipeline of this very repo interruptible as well (see !10 (diffs)) but this can be another MR!
Edited by Peter Leitzen@manuel.remote Almost forgot, do you mind adding a git trailer
Changelog: added
(edit: wasChangelog: changed
) so this change and MR is listed in the next release?Edited by Peter Leitzen
added workflowready for review label and removed workflowin dev label
Hi Coach @sdungarwal, this Community contribution is ready for review or needs your coaching.
- Do you have capacity and domain expertise to review this? If not, find one or more reviewers and assign to them.
- If you've reviewed it, add the workflowin dev label if these changes need more work before the next review.
This message was generated automatically. You're welcome to improve it.
requested review from @sdungarwal
mentioned in issue gitlab-org/quality/triage-reports#19294 (closed)
added Danger bot featureaddition labels
added typefeature label
removed review request for @sdungarwal
Hi @sdungarwal
We noticed this MR is marked as workflowready for review but no reviewer is assigned. workflowin dev has automatically been applied to this MR based on the likelihood the review is finished. If additional reviews are still required, please assign a reviewer and reapply workflowready for review.
@manuel.remote you may also request a review by commenting
@gitlab-bot ready
. You can also assign reviewers directly using@gitlab-bot ready @user1 @user2
if you know the relevant reviewer(s), such as those who were involved in a related issue.This message was generated automatically. You're welcome to improve it.
added workflowin dev label and removed workflowready for review label
mentioned in issue gitlab-org/quality/triage-reports#19355 (closed)
mentioned in issue gitlab-org/quality/triage-reports#19375 (closed)
mentioned in issue gitlab-org/quality/triage-reports#19376 (closed)
mentioned in issue gitlab-org/quality/triage-reports#19377 (closed)
mentioned in issue gitlab-org/quality/triage-reports#19378 (closed)
mentioned in issue gitlab-org/quality/triage-reports#19481 (closed)
mentioned in issue gitlab-org/quality/triage-reports#19546 (closed)
mentioned in issue gitlab-org/quality/triage-reports#19547 (closed)
mentioned in issue gitlab-org/quality/triage-reports#19549 (closed)
Hey @splattael can you do a review here ?
requested review from @splattael
changed milestone to %17.4
mentioned in commit a129041b
mentioned in commit aca05480
mentioned in commit 767cd04e
mentioned in commit 6bdc8486
mentioned in commit c4d0ca0b
mentioned in commit 7c02daa3
23 23 default: false 24 24 type: boolean 25 25 description: 'Whether or not the job is allowed to fail' 26 job_interruptible: 27 default: false Suggestion Thoughts on making this job interruptible by default and let folks opt out?
Reason: If users enable auto-cancelling they expect every job to be interruptible by default.
WDYT?
I am actually surprised that CI jobs defined in components do not inherit the
interruptible
settingIt seems I screwed up my verification and CI jobs defined in components should already inherit the
default:interruptible
setting. Thanks @furkanayhan for verifying itI've created !11 (merged) to make CI jobs interruptible in this very repo (Dogfooding!) and I verified it works as expected already - without this MR.
18 18 | Input | Default Value | Description | 19 19 | --------------------------------- | ----------------------------- | ------------------------------------------------------------------------------------------------- | 20 20 | `job_image` | `ruby:3.3` | The image to use for the `danger-review` job. | 21 | `job_interruptible` | `false` | Allow the danger-review job to be interruptible | mentioned in merge request !11 (merged)
mentioned in issue gitlab-org/quality/triage-reports#19550 (closed)
As per #6 (comment 2092261580) I am going to close this MR!
@manuel.remote Thanks again for the conversation and bearing with me
@manuel.remote, how was your code review experience with this merge request? Please tell us how we can continue to iterate and improve:
- React with a
or a on this comment to describe your experience. - Create a new comment starting with
@gitlab-bot feedback
below, and leave any additional feedback you have for us in the comment.
Subscribe to the GitLab Community Newsletter for contributor-focused content and opportunities to level up.
Thanks for your help!
This message was generated automatically. You're welcome to improve it.
- React with a