you can see from this koji task that

• install tree: http://kojipkgs.fedoraproject.org/compose/twoweek/Fedora-Atomic-27-20171128.1/compose/Cloud/x86_64/os
• release = 20171128.0

The compose is ran with a label RC-20171128.0. That takes precedence when generating the release value. It is first generated from the label (if provided) and only when not provided falls back to date, type and respin.

2017-11-28 15:05:18 [INFO    ] Command line: /usr/bin/pungi-koji --notification-script=/usr/bin/pungi-fedmsg-notification --config=fedora-atomic.conf --old-composes=/mnt/koji/compose/twoweek --skip-phase=productimg --skip-phase=extra_files --label=RC-20171128.0 --target-dir=/mnt/koji/compose/twoweek

I see. Thanks for the explanation lubos.

So what some people have been doing when running a 'respin' is just editing the cron job to make it run in the next few minutes. I see from that RC-$(date "+\%Y\%m\%d").0, which is wrong if we are running a respin.

• Should we be providing a lable at all for these jobs in that crontab?

@mohanboddu - what exact command do you run when you do a respin for me? (I think you are the only one that doesn't edit the crontab and kick it off that way).

@dustymabe I will run the cron job from

https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/releng/files/twoweek-updates#n7

under a screen session on compose-x86-01 box.

But I will change the label value when I run it. For example, if I have to run a .1 compose I will run it as

TMPDIR=`mktemp -d /tmp/twoweekF27.XXXXXX` && pushd $TMPDIR && git clone -n https://pagure.io/pungi-fedora.git && cd pungi-fedora && git checkout f27 && sudo LANG=en_US.UTF-8 ./twoweek-nightly.sh RC-$(date "+%Y%m%d").1 && popd && rm -rf $TMPDIR

thanks @mohanboddu

i guess we can close this as 'user error'.