Conditional build: do we need to rebuild the full ATH for all Renovabot / Dependabot PRs?

[dduportal]

As per jenkins-infra/helpdesk#3551 (comment), the Infra team would like to control the costs on ci.jenkins.io.

We saw a lot of builds (using a LOT of highmem VM agents) for PR changing Dockerfile dependencies such as #1164 or #1149.

At first sight, it seems a waste to execute the whole ATH for such small changes. Is there any means today to conditionnaly build?

Also, it does not look a good idea to run the ATH on ci.jenkins.io if a PR changes the file src/main/resources/ath-container/Dockerfile: it's built by infra.ci and pushed to the DockerHub.

[jtnord]

GitHub merge queue?

[dduportal]

GitHub merge queue?

I’m not sure it would solve the problem : « do we need to build all the time ? ».

IIUC merge queues are only optimizing the merge orders but still builds pr one time at least (but avoid building multiple times)

[uhafner]

I don't think that this libraries needs so many automatic builds. There are several possibilities:

• Since ATH simply is a test tool we can either skip builds for dependency updates or reduce the number of dependency updates (dependabot) to once a month. (Or even more aggressively: switch to a manual dependency management. ATH as library or tool does not need the latest updates for libraries, as long as everything works.)
• Use only the defined set of smoke tests for dependency updates.
• Remove the builds from ci.jenkins.io totally and switch to GitHub actions. E.g., I am running the ATH tests for my plugins using GitHub actions only.

[dduportal]

I like your 2nd point @uhafner : running only a minimal set of test (not heavy, quick) could be a great intermediate.

Also, the ATH image is prebuilt and pushed in the DockerHub since #905 and is "really" used since yesterday with #1168.

I believe that justifies NOT building ATH when the image is changed, and have a renovabot/dependanbot PR for updating the image tag in the Jenkinsfile:

• All builds related to the ath-container/Dockerfile would only be in infra.ci.jenkins.io with eventually their own test harness for the image (with goss or something)
• Updating the image tag, or "normal ATH" contribution would build the full ATH as expected.

[timja]

Some smart test selection based on paths changed would be good.

ideally if ath-container is changed it should use that and run tests.

If artifactory docker image is changed we only need to run artifactory tests etc