Bug #17573

Broken test suite in devel: version numbers

Added by CyrilBrulebois 2020-03-29 20:18:42 . Updated 2020-04-02 07:55:05 .

Status:
Needs Validation
Priority:
Normal
Assignee:
anonym
Category:
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Contributors documentation
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

I need to send a more detailed bug report / patch series for all comments from the 4.5~rc1 release process, but it seems at least one point needs to be addressed: custom.mdwn has this:

### Else, if you just released a RC

[…]

* increment the version number in `devel`'s `debian/changelog` to
  match the second next major release, so that images built from there
  have the right version number:

        cd "${RELEASE_CHECKOUT}" && \
        git checkout devel && \
        dch --newversion "${SECOND_NEXT_PLANNED_MAJOR_VERSION:?}" \
           "Dummy entry for next release." && \
        git commit debian/changelog \
           -m "Add dummy changelog entry for ${SECOND_NEXT_PLANNED_MAJOR_VERSION:?}."

meaning devel points at 4.11 now, but we don’t have any UDF files for 4.11 at the moment, meaning the test suite fails due to the upgrader’s being unable to determine whether an upgrade is available.

intrigeri, anonym, what do you think?

I imagine we could easily paper over the issue by pretending devel is about 4.5, but I’m not sure we want to be hiding issues instead of fixing them. OTOH, we might be wasting huge amounts of resources:

218 scenarios (73 failed, 145 passed)
1630 steps (73 failed, 415 skipped, 1142 passed)
688m30.952s

Subtasks


History

#1 Updated by intrigeri 2020-03-30 11:12:42

Hi,

> intrigeri, anonym, what do you think?

Ouch!

My recommendations would be:

  • short-term fix: publish UDFs for 4.11
  • long-term fix: fix the release process doc so that we pass --next_version $SECOND_NEXT_PLANNED_MAJOR_VERSION to tails-iuk-generate-upgrade-description-files, when we’re preparing a RC

#2 Updated by anonym 2020-03-30 14:23:04

  • Status changed from Confirmed to In Progress

Applied in changeset commit:tails|f26951ff3c015551882f65ffb49ca9fa9f735d78.

#3 Updated by anonym 2020-03-30 14:25:07

intrigeri wrote:
> * short-term fix: publish UDFs for 4.11

Fixed in commit:57cf99593d9a5bedf597e60156351375358ef740!

@kibi requested me to describe what I did:

Normally I would just write the required UDFs by hand, since we only need to fill in trivial fields so I’m not so worried to screw up. However, I wanted to see how I could use tails-iuk-generate-upgrade-description-files. This is what I ended up with, adapted from the the invocation in the release docs (release_process.mdwn:1008):

        ${RELEASE_CHECKOUT:?}/config/chroot_local-includes/usr/src/iuk/bin/tails-iuk-generate-upgrade-description-files \
            --version "${VERSION:?}" \
            --next_version "${SECOND_NEXT_PLANNED_MAJOR_VERSION:?}" \
            --previous_version 42 \
            --iso "${ISO_PATH:?}" \
            --iuks "${IUKS_DIR:?}" \
            --release_checkout "${RELEASE_CHECKOUT:?}" \
            --major_release "${MAJOR_RELEASE:?}" \
            --channel "${DIST:?}"
  • I plugged in my own --next_version just as intrigeri suggested for the long-term fix
  • and I was forced to add some --previous_version because otherwise the tools complains. So I just picked an absurd version (42) but just deleted the nonsensical wiki/src/upgrade/v2/Tails/42/.

Now I have unsigned UDFs in wiki/src/upgrade/v2/Tails/4.11/, so I just copy-paste the usual blurb to sign them (release_process.mdwn:1035), and voilà! :)

> * long-term fix: fix the release process doc so that we pass --next_version $SECOND_NEXT_PLANNED_MAJOR_VERSION to tails-iuk-generate-upgrade-description-files, when we’re preparing a RC

Fixed in commit:f26951ff3c015551882f65ffb49ca9fa9f735d78!

#4 Updated by CyrilBrulebois 2020-03-30 14:54:42

OK, thanks for your work. I was a little afraid of what you encountered (having to specify some other parameters).

For the sake of simplicity and readability, what do you think of changing this:

                        --next_version $(echo ${VERSION:?} | sed -e 's,~.*$,,') \
                        --next_version "${SECOND_NEXT_PLANNED_MAJOR_VERSION:?}"

into that:

                        --next_version "${NEXT_PLANNED_MAJOR_VERSION:?}" \
                        --next_version "${SECOND_NEXT_PLANNED_MAJOR_VERSION:?}"

This would be slightly less convoluted as we know that this else case is taken only when we’re on $DIST = alpha, which only holds for release candidates, and $NEXT_PLANNED_MAJOR_VERSION is what we’re after? This would also mimick explicit names/variables we have in the $DIST = stable case.

#5 Updated by CyrilBrulebois 2020-03-31 15:22:36

FWIW, the test suite looks better again now:

218 scenarios (3 failed, 215 passed)
1630 steps (3 failed, 41 skipped, 1586 passed)
355m14.425s

#6 Updated by intrigeri 2020-04-02 07:55:05

  • Status changed from In Progress to Needs Validation
  • Assignee set to anonym

(For kibi’s follow-up proposal, which I understand is the only thing left here before we can close this issue :)