Tagged releases / multiple releases

[cdrage]

We should have tagged releases every X amount of weeks.

We thought we hit a bug and wanted to roll back to a previous release of the image builder, but found that there are no tagged releases / releases on github.

[lmilbaum]

Related to the discussion #60

[cdrage]

@ondrejbudai @ochosi As we get closer to an initial 1.0.0 release for https://github.com/containers/podman-desktop-extension-bootc we'll need a release of bootc-image-builder as unfortunately it's difficult to keep track / make sure that quay.io versions of the image are reliably always there.

Are we able to do an initial tagged release of bootc-image-builder container as well as subsequent releases as new features are added?

[ondrejbudai]

Do I understand it correctly that the plugin will have a pinned version of bootc-image-builder when distributed to users? That means that such a version of bib needs to be available basically forever, right? (We currently keep only latest AFAIK)

[cdrage]

Do I understand it correctly that the plugin will have a pinned version of bootc-image-builder when distributed to users? That means that such a version of bib needs to be available basically forever, right? (We currently keep only latest AFAIK)

yes that's right, if we were to release a 1.0.0 release of the extension, it should be pulling from a released version of bootc-image-builder as well, or else it would always pull from latest / whatever image, and reliability could differ between versions.

[rhatdan]

Do we really need this or would this be more of keep backwards capabilities. I would figure podman desktop would want fixes that happen to BIB without putting the issue on BIB to continually back port fixes to older versions. Older versions also means supporting the OS that BIB is based on. So if the OS has a CVE then all older BIBs will need to be back ported. This is not a supported product and we should not be putting these kinds of constraints in place. Now if it becomes a supported product, then we would have some kind of time of support.

[deboer-tim]

I would really recommend against this. 'Every PR build is the latest stable release and we'll never have any regressions nor break any existing behaviour' is an extremely high bar that will likely make it hard to evolve, and creates an unnecessarily large number of releases in the field.

We're not asking for back porting, just something more stable than 'latest'. e.g. it's usually a good practise to tag releases and never change those tags, but many teams use another tag like '1.0' that's just moved to the latest 1.0-ifix, 1.1, etc.

[rhatdan]

That is fine, as long as this is understood that there are no back ports and that older images will get stinky IE Could fail image scans because of CVEs from older images.

[cgwalters]

So today, the Konflux pipeline (as you have discovered, as have I) apparently defaults to doing "tags" of a form (I think they're unix timestamps?). But yes, it clearly makes sense to me to make releases (and generate container images corresponding to those).

It seems like someone who is an admin on this repo could just create a first 0.1.0 release via GH, just to start a ball rolling of a form. We can figure out syncing containers from those releases after. And yes we are not committing to any security updates or even support for those images. Perhaps we could use quay's "expire after" to automatically have them go away after say a year; I think Konflux supports that, but it can be done directly too.

[lmilbaum]

I'm aware of github actions which can perform an auto-release. Maybe that could be of help.

[deboer-tim]

To be clear, we weren't asking for releases on GitHub - just to do the equivalent of podman tag on the released container images in quay so that it's clear which is the latest "1.x" release stream image vs other e.g. latest/PR/nightly/v2 images.

But FWIW, this is the action we use to mark releases in Github:

      - name: Create Release
        id: create_release
        uses: ncipollo/release-action@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag: ${{ steps.TAG_UTIL.outputs.githubTag }}
          name: ${{ steps.TAG_UTIL.outputs.githubTag }}
          draft: false
          prerelease: false

[lmilbaum]

Thank you for the clarification. The release process is handled by Konflux. Tagging is done by configuring a Release resource.