feat: Add CircleCI workflow rerun when a specific label is added to a PR #41
Conversation
| return; | ||
| } | ||
| const {owner, repo} = context.repo(); | ||
| const circleCiUrl = `https://circleci.com/api/v1.1/project/github/${owner}/${repo}/build?circle-token=${circleToken}`; |
There was a problem hiding this comment.
Still need to determine how to store and retrieve this token at runtime.
|
Igor and I were talking about this method of being able to trigger reruns of CircleCI ad hoc. |
josephperrott
force-pushed
the
rerun-circle
branch
2 times, most recently
from
5f7797b to
fe8c1b9
Compare
IgorMinar
left a comment
IgorMinar
left a comment
There was a problem hiding this comment.
@ocombe's comments +1
but do rework the naming and labels - it must be clear what this check does. And we don't need to mention "CircleCI" in the label, because once we add buildkite for real, we should rerun buildkite builds with the very same label.
| // set to true to disable | ||
| disabled: true, | ||
| // the label which when added triggers a rerun of the default CircleCI workflow. | ||
| triggerRerunLabel: 'Trigger CircleCI Rerun'; |
There was a problem hiding this comment.
this default label is too long and misleading. We are not just rerunning the CircleCI workflow, we are rerunning it rebased against the latest HEAD of the target branch.
Maybe "Rerun CI against HEAD"?
There was a problem hiding this comment.
My concern with just saying CI is that not all things that show up on CI will be rerun, g3 presubmits being an example.
There was a problem hiding this comment.
I'll merge this for now, since this label will be part of the config on each repo anyway you can debate the name of the label on the PR that @josephperrott will make to update the config file
josephperrott
force-pushed
the
rerun-circle
branch
from
fe8c1b9 to
b23f182
Compare
4 participants
No description provided.