WIP: config-bot: add bump-lockfiles functionality#48
WIP: config-bot: add bump-lockfiles functionality#48jlebon wants to merge 1 commit intocoreos:masterfrom
Conversation
This is meant to address a smarter way to bump lockfiles. See: coreos/fedora-coreos-tracker#293 Only supports `git push` for now. Working on making that smarter.
addc95c to
7abcd65
Compare
| @@ -1,4 +1,4 @@ | |||
| FROM registry.fedoraproject.org/fedora:30 | |||
| FROM quay.io/coreos-assembler/coreos-assembler:master | |||
There was a problem hiding this comment.
Hmm. Things just got a lot more heavyweight :) - Does this mean we also require /dev/kvm for config-bot now?
There was a problem hiding this comment.
I originally wanted to use cosa for this, and had a patch to drop the req. on /dev/kvm for our needs. :) But in the end, I think it's simpler to just invoke rpm-ostree ourselves directly.
|
Could we just make a separate pipeline that uses bodhi-updates as the source and just runs IOW we keep promote-lockfiles and run the |
That could work, though hmm... feels like overkill if we can just run that one |
As discussed in coreos#104, we don't actually want the bodhi-updates stream to pull in newer packages from the pool. That said, bodhi-updates also current acts as our lockfile updater in testing-devel, so it's crucial that it keeps working. We're working to decouple that, see: coreos/fedora-coreos-tracker#293 coreos/fedora-coreos-releng-automation#48 But for now, the updates must flow...
|
I think an MVP for this is just doing the PR workflow so we're still covered by CI. Do a dumb detection if a PR is already opened, and just update that one if so. We can then refine it later on to do the "branch push and silently merge if CI passes and it's trivial package bumps, otherwise open a PR". |
As discussed in #104, we don't actually want the bodhi-updates stream to pull in newer packages from the pool. That said, bodhi-updates also current acts as our lockfile updater in testing-devel, so it's crucial that it keeps working. We're working to decouple that, see: coreos/fedora-coreos-tracker#293 coreos/fedora-coreos-releng-automation#48 But for now, the updates must flow...
|
Sounds good |
|
Going to pick this up again soon! |
This job will implement lockfile bumping for testing-devel and next-devel: coreos/fedora-coreos-tracker#293. The original plan for this functionality was to have it in config-bot: coreos/fedora-coreos-releng-automation#48 But in the end, I think it's more natural to have it as a Jenkins job given that it does a lot of the same things as the pipeline/upstream CI jobs. So that way it looks and feels just like another job that runs cosa, and we get kola artifacts, we can re-use the shared library, it's easily inspectable, we can hook it to Slack, etc...
This job will implement lockfile bumping for testing-devel and next-devel: coreos/fedora-coreos-tracker#293. The original plan for this functionality was to have it in config-bot: coreos/fedora-coreos-releng-automation#48 But in the end, I think it's more natural to have it as a Jenkins job given that it does a lot of the same things as the pipeline/upstream CI jobs. So that way it looks and feels just like another job that runs cosa, and we get kola artifacts, we can re-use the shared library, it's easily inspectable, we can hook it to Slack, etc...
This job will implement lockfile bumping for testing-devel and next-devel: coreos/fedora-coreos-tracker#293. The original plan for this functionality was to have it in config-bot: coreos/fedora-coreos-releng-automation#48 But in the end, I think it's more natural to have it as a Jenkins job given that it does a lot of the same things as the pipeline/upstream CI jobs. So that way it looks and feels just like another job that runs cosa, and we get kola artifacts, we can re-use the shared library, it's easily inspectable, we can hook it to Slack, etc...
This job will implement lockfile bumping for testing-devel and next-devel: coreos/fedora-coreos-tracker#293. The original plan for this functionality was to have it in config-bot: coreos/fedora-coreos-releng-automation#48 But in the end, I think it's more natural to have it as a Jenkins job given that it does a lot of the same things as the pipeline/upstream CI jobs. So that way it looks and feels just like another job that runs cosa, and we get kola artifacts, we can re-use the shared library, it's easily inspectable, we can hook it to Slack, etc...
This job will implement lockfile bumping for testing-devel and next-devel: coreos/fedora-coreos-tracker#293. The original plan for this functionality was to have it in config-bot: coreos/fedora-coreos-releng-automation#48 But in the end, I think it's more natural to have it as a Jenkins job given that it does a lot of the same things as the pipeline/upstream CI jobs. So that way it looks and feels just like another job that runs cosa, and we get kola artifacts, we can re-use the shared library, it's easily inspectable, we can hook it to Slack, etc...
This job will implement lockfile bumping for testing-devel and next-devel: coreos/fedora-coreos-tracker#293. The original plan for this functionality was to have it in config-bot: coreos/fedora-coreos-releng-automation#48 But in the end, I think it's more natural to have it as a Jenkins job given that it does a lot of the same things as the pipeline/upstream CI jobs. So that way it looks and feels just like another job that runs cosa, and we get kola artifacts, we can re-use the shared library, it's easily inspectable, we can hook it to Slack, etc...
This job will implement lockfile bumping for testing-devel and next-devel: coreos/fedora-coreos-tracker#293. The original plan for this functionality was to have it in config-bot: coreos/fedora-coreos-releng-automation#48 But in the end, I think it's more natural to have it as a Jenkins job given that it does a lot of the same things as the pipeline/upstream CI jobs. So that way it looks and feels just like another job that runs cosa, and we get kola artifacts, we can re-use the shared library, it's easily inspectable, we can hook it to Slack, etc...
This job will implement lockfile bumping for testing-devel and next-devel: coreos/fedora-coreos-tracker#293. The original plan for this functionality was to have it in config-bot: coreos/fedora-coreos-releng-automation#48 But in the end, I think it's more natural to have it as a Jenkins job given that it does a lot of the same things as the pipeline/upstream CI jobs. So that way it looks and feels just like another job that runs cosa, and we get kola artifacts, we can re-use the shared library, it's easily inspectable, we can hook it to Slack, etc...
This job will implement lockfile bumping for testing-devel and next-devel: coreos/fedora-coreos-tracker#293. The original plan for this functionality was to have it in config-bot: coreos/fedora-coreos-releng-automation#48 But in the end, I think it's more natural to have it as a Jenkins job given that it does a lot of the same things as the pipeline/upstream CI jobs. So that way it looks and feels just like another job that runs cosa, and we get kola artifacts, we can re-use the shared library, it's easily inspectable, we can hook it to Slack, etc...
This job will implement lockfile bumping for testing-devel and next-devel: coreos/fedora-coreos-tracker#293. The original plan for this functionality was to have it in config-bot: coreos/fedora-coreos-releng-automation#48 But in the end, I think it's more natural to have it as a Jenkins job given that it does a lot of the same things as the pipeline/upstream CI jobs. So that way it looks and feels just like another job that runs cosa, and we get kola artifacts, we can re-use the shared library, it's easily inspectable, we can hook it to Slack, etc...
This job will implement lockfile bumping for testing-devel and next-devel: coreos/fedora-coreos-tracker#293. The original plan for this functionality was to have it in config-bot: coreos/fedora-coreos-releng-automation#48 But in the end, I think it's more natural to have it as a Jenkins job given that it does a lot of the same things as the pipeline/upstream CI jobs. So that way it looks and feels just like another job that runs cosa, and we get kola artifacts, we can re-use the shared library, it's easily inspectable, we can hook it to Slack, etc...
|
Replaced by coreos/fedora-coreos-pipeline#229. |
This is meant to address a smarter way to bump lockfiles.
See: coreos/fedora-coreos-tracker#293
Only supports
git pushfor now. Working on making that smarter.