coreos/fedora-coreos-config

Work towards creating streams

Closed this issue · 11 comments

jlebon commented

So, we're now in a position where we can start implementing the stream work as described in https://github.com/coreos/fedora-coreos-tracker/blob/master/stream-tooling.md.

I'd like to suggest the following concrete steps to start:

  • rename master to testing-devel
  • add two new branches: testing and bodhi-updates, which are copies of testing-devel modulo the ref (we can manually keep bodhi-updates in sync to start, but need to work towards automating this)
  • set up pipeline for periodic bodhi-updates runs (basically what it does today, but targeting the new stream)
  • push output lockfile to the bodhi-updates branch (see coreos/coreos-assembler#553) (again, can start manually to get things going, but need to automate this very soon)
  • for now, just push lockfile to testing-devel as well; we can work towards making this a PR-based + CI workflow afterwards
  • hook up coreos-koji-tagger to watch testing-devel
  • set up pipelines for testing-devel and testing runs triggered on ref changes
  • try out testing releases by manually merging from the testing-devel branch using the mythical "theirs" strategy, and work on tooling to make this less manual & error-prone.

All open for discussions of course. The goal is to get a taste of the workflow across mechanical, devel, and prod streams even if in a semi-manual capacity and unblock tooling and automation work. Once we have this down, we can start filling in more of the blanks, such as working towards automation for doing a testing release, adding the remaining prod, devel, and mechanical streams, etc...

jlebon commented

add two new branches: testing and bodhi-updates, which are copies of testing-devel modulo the ref

Minor prep for this in: #101

dustymabe commented

seems reasonable to me

rename master to testing-devel

so we no longer have a master branch at all? let me know when we do this and we can change the settings in this repo to have everything act correctly.

jlebon commented

so we no longer have a master branch at all?

Right. All our development would happen on the testing-devel stream, but it'd be confusing to have just that one have a branch name that doesn't match the stream name.

dustymabe commented

but it'd be confusing to have just that one have a branch name that doesn't match the stream name.

agree

jlebon commented
  1. rename master to testing-devel

This has happened now (though it's more of a copy and delete since git doesn't actually have a "remote ref rename" concept).

  1. add two new branches: testing and bodhi-updates, which are copies of testing-devel modulo the ref (we can manually keep bodhi-updates in sync to start, but need to work towards automating this)

#103
#104

jlebon commented

If your git checkout is throwing weird errors looking for master, try git fetch upstream --prune then vim .git/refs/remotes/upstream/HEAD and do a s/master/testing-devel/.

jlebon commented
  • set up pipeline for periodic bodhi-updates runs (basically what it does today, but targeting the new stream)
  • set up pipelines for testing-devel and testing runs triggered on ref changes

These are done by coreos/fedora-coreos-pipeline#76 now.

I think now we should split out the various bits of automation required into separate tickets and swarm on those?

dustymabe commented

I think now we should split out the various bits of automation required into separate tickets and swarm on those?

SGTM

cgwalters commented

I think this is all done.