pipeline.yaml: New file which configures the pipeline #1175
Conversation
The idea is to keep the pipeline as more the mechanics/implementation, and the config git repo is the declarative state. One goal here is that e.g. `cosa upload-oscontainer` defaults to this value. I also added `s3_bucket`. Right now the pipeline writes this as an annotation, but I think it will be easier to deal with if e.g. `cosa buildupload` defaults to this.
This is a bit hacky but should work. My initial goal here is just automated uploads of our builds, so that we can start getting a better feel for managing "ostree-in-container" releases. We should sync to `quay.io/coreos` but that needs someone to set that up. Also, I'd like to make the destination configurable in the same way as the S3 bucket, proposal PR in coreos/fedora-coreos-config#1175 Closes: coreos#359
This is a bit hacky but should work. My initial goal here is just automated uploads of our builds, so that we can start getting a better feel for managing "ostree-in-container" releases. We should sync to `quay.io/coreos` but that needs someone to set that up. Also, I'd like to make the destination configurable in the same way as the S3 bucket, proposal PR in coreos/fedora-coreos-config#1175 Closes: coreos#359
|
This would help coreos/fedora-coreos-pipeline#383 because then I could avoid the pipeline annotation bits. |
|
We're definitely looking to move away from the annotation hack. Was chatting about this recently with @dustymabe and we were saying it should just be in the Jenkins configmap (which translates into: more JCASC drop-ins in https://github.com/coreos/fedora-coreos-pipeline/tree/main/jenkins/config). Not opposed to having some knobs here, though leaving this repo scoped to generating artifacts and having releng-related configs centralized in https://github.com/coreos/fedora-coreos-pipeline/tree/main/jenkins/config feels cleaner. We just need to make it easier to configure. On that topic, I definitely like the idea of having cosa directly pick up config values. One easy way to do this is to have JCASC dropins which define global env vars and have those read directly by cosa. E.g. |
|
I think this workflow implies pushing to your FCOS fork and pointing the pipeline to it, which is not necessarily required today if you're hacking on purely pipeline stuff (and if you're hacking on the pipeline, you're likely already operating on a branch of your fork of the pipeline repo with your modifications anyway). |
👍 |
This is a bit hacky but should work. My initial goal here is just automated uploads of our builds, so that we can start getting a better feel for managing "ostree-in-container" releases. We should sync to `quay.io/coreos` but that needs someone to set that up. Also, I'd like to make the destination configurable in the same way as the S3 bucket, proposal PR in coreos/fedora-coreos-config#1175 Closes: coreos#359
This is a bit hacky but should work. My initial goal here is just automated uploads of our builds, so that we can start getting a better feel for managing "ostree-in-container" releases. We should sync to `quay.io/coreos` but that needs someone to set that up. Also, I'd like to make the destination configurable in the same way as the S3 bucket, proposal PR in coreos/fedora-coreos-config#1175 Closes: coreos#359
This is a bit hacky but should work. My initial goal here is just automated uploads of our builds, so that we can start getting a better feel for managing "ostree-in-container" releases. We should sync to `quay.io/coreos` but that needs someone to set that up. Also, I'd like to make the destination configurable in the same way as the S3 bucket, proposal PR in coreos/fedora-coreos-config#1175 Closes: #359
The idea is to keep the pipeline as more the mechanics/implementation,
and the config git repo is the declarative state.
One goal here is that e.g.
cosa upload-oscontainerdefaults to this value.I also added
s3_bucket. Right now the pipeline writes thisas an annotation, but I think it will be easier to deal with if
e.g.
cosa builduploaddefaults to this.