workflow: Only skip build on PRs

[cgwalters]

We do want to push on schedules.

[lmilbaum]

What should happen if the event name is workflow_dispatch?

[cgwalters]

What should happen if the event name is workflow_dispatch?

Then we should push I'd say; a workflow_dispatch is like a manually triggered schedule.

[lmilbaum]

What should happen if the event name is workflow_dispatch?

Then we should push I'd say; a workflow_dispatch is like a manually triggered schedule.

Potentially the workflow_dispatch is used when CI is flaky. It seems that this PR comes to address the schedule triggering which personally I don't think it is sustainable.

[cgwalters]

It seems that this PR comes to address the schedule triggering which personally I don't think it is sustainable.

Yes, debate on this clearly continues. Are you arguing for renovate here?

[lmilbaum]

It seems that this PR comes to address the schedule triggering which personally I don't think it is sustainable.

Yes, debate on this clearly continues. Are you arguing for renovate here?

I'm persistent :-) Take a look at how it was addressed in the automotive-osbuild repo. Renovate produces a PR every time a new commit sha is pushed to osbuild repo and auto merges it if all is well.
https://gitlab.com/CentOS/automotive/container-images/automotive-osbuild/-/merge_requests/75

[cgwalters]

The images here will potentially change multiple times a day. The intention is to track git main of multiple projects.

Some repositories I want to track git main of are fairly active, so we could easily end up with at least 5-10 builds per day, and the idea of requiring every build to be triggered by a git commit to this repository seems to me to be basically ridiculous over time.

[lmilbaum]

The images here will potentially change multiple times a day. The intention is to track git main of multiple projects.

Some repositories I want to track git main of are fairly active, so we could easily end up with at least 5-10 builds per day, and the idea of requiring every build to be triggered by a git commit to this repository seems to me to be basically ridiculous over time.

I feel like I'm pushing Renovate too much. I have a good technical feedback to your concern but I don't want to make it an issue.

[cgwalters]

I feel like I'm pushing Renovate too much.

I wouldn't say that. There is a reasonable debate to be had here IMO.

The thing is...to me, "git log" is an absolutely crucial resource for git repositories that I care about. And dependabot/renovate like bots can (if not tuned/controlled) basically end up as spam. Of course one can filter out changes but still...

I think the dependabot/renovate like approaches often really want to be split into "things likely to break" versus something more like an at-most-weekly "big group of safe dependency updates".

The role of this repository is very much to just churn out builds as quickly as possible to use as an integration testing base so that the real base images are more likely to be stable.

If say this image starts failing tests because podman or bootc broke, I think what we'd end up doing is reverting to an earlier build.

I have a good technical feedback to your concern but I don't want to make it an issue.

Please do add it.

[cgwalters]

Also xref CentOS/centos-bootc-layered#16 where we have the same problem (stacked because those images currently depend on the ones from here).

[lmilbaum]

I feel like I'm pushing Renovate too much.

I wouldn't say that. There is a reasonable debate to be had here IMO.

Thank you for debating this issue. I do want to understand better your approach and align mine with yours.

The thing is...to me, "git log" is an absolutely crucial resource for git repositories that I care about. And dependabot/renovate like bots can (if not tuned/controlled) basically end up as spam. Of course one can filter out changes but still...

Understood and agreed. Although, To MHO the heavy lifting is gradually but consistently transitioning to PRs, issues and discussions (where enabled)

I think the dependabot/renovate like approaches often really want to be split into "things likely to break" versus something more like an at-most-weekly "big group of safe dependency updates".

Not sure I fully understand this statement but I can say that there are values in bumping dependencies versions. Just to name a few:

• Security and Stability
• Code quality and maintainability
• Minimizing technical debt
• Adoption of new features

I will be happy to expand on each item in case you find it valuable

The role of this repository is very much to just churn out builds as quickly as possible to use as an integration testing base so that the real base images are more likely to be stable.

In my opinion, every project whatever its purpose is supposed to follow the same engineering practices

If say this image starts failing tests because podman or bootc broke, I think what we'd end up doing is reverting to an earlier build.

I have a good technical feedback to your concern but I don't want to make it an issue.

Please do add it.

Thanks again for letting me share my opinion.
Eventually, it is a matter of tweaking the bot to produce what we want when we want it. That sometimes takes a little more time.
Yet another benefit of adopting the renovate approach is having a collaboration area to identify errors, mitigating them and tracking the history

[cgwalters]

While this debate is valuable, in the meantime can you (or someone else) add an approval to this PR so we can get our development images flowing again?