do we need to explicitly state no checks with empty list in .aicoe.yaml?

[pacospace]

When removing key checks from .aicoe.yaml all checks are started by default in the check runs list.
In order to avoid that the parameter needs to be set with an empty list []. Is this behaviour expected or if the user remove the key the pipeline should assume no checks are reuqested instead of users requiring to put empty list?

/user-experience
/question

[pacospace]

Actually it is not deactivated, how can we do that @harshad16: thoth-station/report-processing#112

[harshad16]

Yes this is correct, user has to specify the checks as empyt list to state no checks are needed, by default build-check runs.
The way it is done in thoth-station/report-processing#112 is the right way.

Thanks for asking the question

[tumido]

@harshad16 how does that work together with the on-repo configs for prow jobs and so on? Does it mean that even if the on-repo config is enabled, the default checks are still being executed?

[harshad16]

There is no direct linkage between aicoe-ci and prow as of now.
If users are using the prow on-repo-config then the checks on the .aicoe-ci.yaml have to be disabled, as both ci's would try to do their tasks.
if the aicoe-ci is only being used for checks and users migrate to prow checks, then it would be recommended to disable aicoe-ci from the repository if the build and deploy is not needed.

[tumido]

@harshad16 is this true (that both CIs are checking on PRs) even if the .aicoe-ci.yaml file is completely missing? Or is this a problem only if the user uses any other section of .aicoe-ci.yaml and omits the checks section.

[harshad16]

if the aicoe-ci is installed on the github repository, it would look on each pr and stop if there is no information on the .aicoe-ci.yaml on performing the what action .

[tumido]

@harshad16 sorry, I can't read properly today. Does that mean: deleting the .aiops-ci.yaml means no CI checks from AICoE-CI. Correct?

[harshad16]

@tumido that is in-correct.
if the aicoe-ci.yaml is deleted and aicoe-ci is still installed
then it goes to the default checks like running build-check and pre-commit check if there is a .pre-commit-check.yaml

[goern]

/sig pipelines
/sig docs

are we good with closing this? do we need a piece of doc derived from this issue?

[tumido]

I think we need at least some docs around this. My impression is that we're missing a README section which describes the default behavior when AICoE-CI github app is installed. I also think this is part of a broader problem as well.

To me it appears the confusion comes from a fact that to an end user it's not very apparent that AICoE-CI, Prow, Kebechet, Sesheta and what else are different applications that can be selectively enabled or disabled (and how) and what is the default configuration for each, what config file changes they react to, etc.

For me for example, since Sesheta is responding on release issues, doing dependency upgrades, commenting on PRs with prow status, etc. it's not obvious that I'm interfacing 3 different "apps"/bots. So.. for me it would be nice to understand that dependency checks are handled by this bot, build are handled by that other bot and I can mix and match them selectively in somewhat consistent manner.

For example:

1. What should l do if I want this project to handle s2i builds on a NodeJS application and running Prow checks. Can Thoth help me watch dependencies?
2. What should I do with a Python application when I want the dependencies to be handled by dependabot and I want Thoth to execute pre-commit I don't expect any s2i build to happen since I'm developing a Python package.
3. What should I do for a Go project if I want Thoth to handle s2i builds and releases and versioning?
4. What should I do if I only want Prow to sync my labels?

Most of these scenarios are somewhat supported by the project but user has to precisely know which config to touch and how to change it...

I know I'm maybe getting away from the original topic but I think this is part of a more general problem that it is hard to understand what is actually going on and what should I enable in what exact case... And what changes do I have to make to the default setup if I want to single out one feature of this CI and use that one only.

[sesheta]

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.

/lifecycle stale

[harshad16]

/remove-lifecycle stale

[sesheta]

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.

/lifecycle stale

[sesheta]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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

/lifecycle rotten

[harshad16]

/lifecycle frozen