test-infra 🚀 - Invert job config specification

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

fejta-bot on 20 Jan 2018

I don't think we are going to this route..

ref https://github.com/kubernetes/test-infra/issues/3338

krzyzacy on 21 Jan 2018

/assign @paulangton
ignore my previous comment, this is still something good to have

krzyzacy on 5 Jun 2018

@krzyzacy: GitHub didn't allow me to assign the following users: paulangton.

Note that only kubernetes members and repo collaborators can be assigned.

In response to this:

/assign @paulangton
ignore my previous comment, this is still something good to have

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

k8s-ci-robot on 5 Jun 2018

/assign @paulangton

krzyzacy on 5 Jun 2018

So instead of

jobs:
- name: ci-kubernetes-bazel-build
  spec:
    containers:
    - image: gcr.io/k8s-testimages/bazelbuild:0.8
  postsubmit:
    branches:
    - master
  periodic:
    interval: 1h

we probably should have

jobs:
- name: ci-kubernetes-bazel-build
  spec:
    containers:
    - image: gcr.io/k8s-testimages/bazelbuild:0.8
  trigger:
    branches:
    - master

or

jobs:
- name: ci-kubernetes-bazel-build
  spec:
    containers:
    - image: gcr.io/k8s-testimages/bazelbuild:0.8
  trigger:
    interval: 2h

and we can unify three different job types into one struct

cc @cjwagner @BenTheElder @stevekuznetsov

krzyzacy on 5 Jun 2018

👍2

/remove-lifecycle stale

paulangton on 5 Jun 2018

if we can invert this we might be able to design it in a way that is easier to extend the triggering agent without modifying the prowjob CRD.

Eg right now I'd love to add (but don't want to create a new job type etc)

jobs that are triggered on github release tagging events
jobs that are triggered in presubmit, postsubmit etc but not with some heuristics on the file changes (beyond just a regex, some kind of "docs only change" detection for example)
other forms of specifying scheduling for horlogium
...

BenTheElder on 5 Jun 2018

/meow

paulangton on 6 Jun 2018

Bad bot!

stevekuznetsov on 6 Jun 2018

😄1

/woof

BenTheElder on 6 Jun 2018

@BenTheElder:

In response to this:

/woof

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

k8s-ci-robot on 6 Jun 2018

😄1 👍1

Good bot.

paulangton on 6 Jun 2018

and we can unify three different job types into one struct

@krzyzacy This seems nice except that it will move us farther away from unique job names unless we provide some mechanism for giving the different job types different names.
We should also consider how we would name a job that is triggered on multiple different repos (if that is something we intend to support by specifying the repo in the trigger section).

Another option: We could completely separate the trigger config section from the job specs, keeping the triggering config similar to the current config (presubmits, postsubmits and periodics sections). Then we could just provide the triggering config and reference the job config defined elsewhere. This format would make it easy for us to specify different job names for different triggering scenarios, but it would make the config a little harder to read because triggering config would be separate from job config.

cjwagner on 7 Jun 2018

@cjwagner trigger is seperated from specs from my sample above? If not can you also give an example?

and we can still enforce unique job names on config loading (like force append branch names to a job, but use the same context value).

krzyzacy on 7 Jun 2018

trigger is seperated from specs from my sample above? If not can you also give an example?

I was thinking that multiple triggers could refer to the same job spec:

job-specs:
- name: bazel-build
  spec:
    containers:
    - image: gcr.io/k8s-testimages/bazelbuild:0.8

triggers:
  presubmits:
    "k/k":
    - name: pull-kubernetes-bazel-build
      job-spec: bazel-build
      branches:
      - master
    "k/t-i":
    - name: pull-test-infra-bazel-build
      job-spec: bazel-build
  postsubmits:
    "k/k":
    - name: pull-test-infra-bazel-build
      job-spec: bazel-build

If we allow the trigger entries to specify args or env we could pretty easily move the config.json information here and then just have different job-spec entries for each scenario.

and we can still enforce unique job names on config loading (like force append branch names to a job, but use the same context value).

I think we should have complete job names exist in the raw config if possible. If we append things like branch or repo names to the configured job name at load time it won't be easy to look up real jobs based on the config unless you know exactly how the config parsing logic mutates job names.

cjwagner on 7 Jun 2018

Multiple triggers on the same job specs in this way is an idea I like too,
but wouldnt really be any more useful than triggers inline to a job unless
different triggers could override things like the git checkout config.

On Wed, Jun 6, 2018, 9:24 PM Cole Wagner notifications@github.com wrote:

trigger is seperated from specs from my sample above? If not can you also
give an example?

I was thinking that multiple triggers could refer to the same job spec:

job-specs:

name: bazel-build
spec:
containers:

image: gcr.io/k8s-testimages/bazelbuild:0.8

triggers:

presubmits:

"k/k":

name: pull-kubernetes-bazel-build

job-spec: bazel-build

branches:

master

"k/t-i":

name: pull-test-infra-bazel-build

job-spec: bazel-build

postsubmits:

"k/k":

name: pull-test-infra-bazel-build

job-spec: bazel-build

If we allow the trigger entries to specify args or env we could pretty
easily move the config.json information here and then just have different
job-spec entries for each scenario.

and we can still enforce unique job names on config loading (like force
append branch names to a job, but use the same context value).

I think we should have complete job names exist in the raw config if
possible. If we append things like branch or repo names to the configured
job name at load time it won't be easy to look up real jobs based on the
config unless you know exactly how the config parsing logic mutates job
names.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/test-infra/issues/2547#issuecomment-395288742,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA4Bq8cmqLEp7JAAlDjC6IstVzKZ8wsBks5t6KsZgaJpZM4NDcIq
.

BenTheElder on 7 Jun 2018

hummm, I feel like it won't be that many jobs can share the same spec.

Different branch has different bazel/go versions, and k/k and test-infra can diverge as well?

krzyzacy on 7 Jun 2018

On the same branch CI / presubmit / postsubmit are nearly the same except
upload location, context, git checkout.

On Thu, Jun 7, 2018 at 12:12 PM Sen Lu notifications@github.com wrote:

hummm, I feel like it won't be that many jobs can share the same spec.

Different branch has different bazel/go versions, and k/k and test-infra
can diverge as well?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/test-infra/issues/2547#issuecomment-395532737,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA4Bq4r4YvEifZ5jbch94n0uLfVr1-JRks5t6XsEgaJpZM4NDcIq
.

BenTheElder on 7 Jun 2018

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

fejta-bot on 5 Sep 2018

/remove-lifecycle stale
/assign
will get to this one day... one day...

krzyzacy on 5 Sep 2018

👍2 😄1

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

fejta-bot on 28 Jan 2019

/pony shrug
/remove-lifecycle stale
/lifecycle frozen

krzyzacy on 21 Feb 2019

@krzyzacy:

In response to this:

/pony shrug
/remove-lifecycle stale
/lifecycle frozen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

k8s-ci-robot on 21 Feb 2019

/close
It's unlikely we're going to ever get to this

spiffxp on 10 Apr 2020

@spiffxp: Closing this issue.

In response to this:

/close
It's unlikely we're going to ever get to this

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

k8s-ci-robot on 10 Apr 2020

/remove-lifecycle frozen
/lifecycle rotten

spiffxp on 10 Apr 2020

Test-infra: Invert job config specification

Most helpful comment

All 27 comments

Related issues