[releng] Issue #6545 `Atomic Host release process is not based on primary
Atomic Host technology`
by Dusty Mabe
dustymabe added a new comment to an issue you are following:
``
> How will versioning work for this? AFAIU right now the nightly compose just uses the auto-increment feature. Will the stable releases jump numbers (i.e. +14 on every upgrade)? Though it's probably too late for F25, it might be better to use timestamp based versions, e.g. 25.20170207.
Right. I believe the 14+ bump in version is fine for now. I do like the timestamp based versioning, maybe we can do that for F26.
> I had a chat about this yesterday with @dustymabe and @puiterwijk. One of the proposed plan of action was to just use ostree admin set-origin to make sure the nightlies always point to the stable repo.
> There's a tricky bit here though. We want the new 2wk commits to be children of the previous commits. But the commits from the nightlies will be on a different branch. When you e.g. do ostree commit -b $2wk_ref --tree=ref=$nightly_ref to promote content between branches, you will get a different SHA. So the commits on which the nightly images are built will never actually belong on the 2wk branch (and e.g. ostree log will be going up the wrong ancestry).
actually the proposal was just to update the "ref" file and not run `ostree commit`. I didn't really know about the "summary" file before yesterday so maybe with this approach we would need to re-run `ostree summary -u` again?
> It would be better to do to this in separate steps. I.e. promote content to the 2wk branch, and then create an image based on that ref. No set-origin needed. Alternatively, you can also make sure that the nightly composes always commit on top of the the latest 2wk commit, rather than the previous nightly commit.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6545
7 years, 3 months
[releng] Issue #6545 `Atomic Host release process is not based on primary
Atomic Host technology`
by Jonathan Lebon
jlebon added a new comment to an issue you are following:
``
> updating the two week release process to update the fedora-atomic/25/x86_64/docker-host ref
How will versioning work for this? AFAIU right now the nightly compose just uses the auto-increment feature. Will the stable releases jump numbers (i.e. +14 on every upgrade)? Though it's probably too late for F25, it might be better to use timestamp based versions, e.g. `25.20170207`.
> building the iso/cloud images from the "updates" ref but pointing them to the 2wk release ref
> > This will mean we can still get new images every night to test but when we release one of these images it tracks the 2wk ref by default.
I had a chat about this yesterday with @dustymabe and @puiterwijk. One of the proposed plan of action was to just use `ostree admin set-origin` to make sure the nightlies always point to the stable repo.
There's a tricky bit here though. We want the new 2wk commits to be children of the previous commits. But the commits from the nightlies will be on a different branch. When you e.g. do `ostree commit -b $2wk_ref --tree=ref=$nightly_ref` to promote content between branches, you will get a different SHA. So the commits on which the nightly images are built will never actually belong on the 2wk branch (and e.g. `ostree log` will be going up the wrong ancestry).
It would be better to do to this in separate steps. I.e. promote content to the 2wk branch, and *then* create an image based on that ref. No `set-origin` needed. Alternatively, you can also make sure that the nightly composes always commit on top of the the latest 2wk commit, rather than the previous nightly commit.
``
To reply, visit the link below or just reply to this email
https://pagure.io/releng/issue/6545
7 years, 3 months