Cirrus-CI: test_building_snap and upload_snap produce podman 0.11.1.1

[cevich]

/kind bug

Description

In .cirrus.yml these two tasks build, then build + upload podman to snapcraft. For some reason both believe the podman version is 0.11.1.1

Steps to reproduce the issue:

1. Open PR

2. Merge PR

Describe the results you received:

(from cirrus output)

...cut...
'grade' property not specified: defaulting to 'stable'
Snapping 'podman' ...
Snapped podman_0.11.1.1_amd64.snap
Downloading 'v0.11.1.1.tar.gz'                                                 
Downloading 'v0.11.1.1.tar.gz'                                                 
Preparing to push 'podman_0.11.1.1_amd64.snap'.
After pushing, an attempt will be made to release to 'edge'
...cut...

Describe the results you expected:

The proper version should be built and uploaded

[cevich]

@abitrolly would you mind looking into this?

[cevich]

if it helps, this script will spit out the proper version number on stdout:

./hack/get_release_info.sh VERSION

[abitrolly]

Oh, right.. The version is hardcoded here https://github.com/containers/libpod/blob/e87012de126a701a5afce73bea3811a540059f65/contrib/snapcraft/snap/snapcraft.yaml#L2

I am checking how people maintain it properly for CI.

[abitrolly]

This line also doesn't seem right. It was ok when snapcraft.yml was in a separate repository.

https://github.com/containers/libpod/blob/e87012de126a701a5afce73bea3811a540059f65/contrib/snapcraft/snap/snapcraft.yaml#L17

[abitrolly]

It should be possible to build latest master by using https://github.com/containers/libpod/archive/master.tar.gz The snap build will still fail because of drifted dependencies from https://github.com/containers/libpod/blob/master/install.md#build-and-run-dependencies

The proper solution is still to use code from current checkout.

[cevich]

Interesting, so we already have a mechanism that builds a zip file for the current checkout (on master and PRs). Could that be re-used?

ref: contrib/cirrus/build_release.sh

Inside the zip is a release.txt containing the build/platform information. We upload this file for both podman and podman-remote, for PRs and master, to a public google storage bucket.

ref: contrib/cirrus/upload_release_archive.sh

If that's not enough, there is a caching mechanism provided by Cirrus-CI, we could use that to provide files from one task to another.

[cevich]

ref: https://cirrus-ci.org/guide/writing-tasks/#cache-instruction

[github-actions]

This issue had no activity for 30 days. In the absence of activity or the "do-not-close" label, the issue will be automatically closed within 7 days.

[abitrolly]

/label do-no-close

[openshift-ci-robot]

@abitrolly: The label(s) /label do-no-close cannot be applied. These labels are supported: platform/aws, platform/azure, platform/baremetal, platform/google, platform/libvirt, platform/openstack, ga

In response to this:

/label do-no-close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[abitrolly]

@github-actions

this is not fixed yet, because podman build is not a simple go build

[rhatdan]

@abitrolly @cevich @afbjorklund Any movement on this one?

[afbjorklund]

@rhatdan : have no idea about snap, I wondered about a regular Linux binary (for podman-remote)

[rhatdan]

@afbjorklund You just want podman to execute podman-remote when it connects to a remote IP correct? Or to embed the code within itself.

[abitrolly]

The easiest way to tackle this is to compile podman binary and all assets in a separate step and pass them as .tar.gz to snap and make use of "dump" plugin to deliver it.

I run out of for money and I need to unsubscribe from all activities to deal with this particular problem. Sorry.

[afbjorklund]

@rhatdan : I think there was a request from the user, to not have to use different commands depending on if the containers were running locally or remotely - it was described more in #4390 (comment)

For minikube, we want the user (who could be on linux) to be able to run podman-remote to the VM. So it would be nice to have podman-remote available on all platforms, including linux (without snapd).

[rhatdan]

@baude @jwhonce, @mheon and I have been discussing this for the rewrite of podman-remote to support APIV2.

[afbjorklund]

I made my own binaries meanwhile, basically just ran make - before the CI process is up again...

make podman-remote-linux podman-remote-windows podman-remote-darwin

https://github.com/boot2podman/libpod/releases/tag/v1.6.5

Apparently nobody is using tarballs or checksums anymore.

[rhatdan]

@cevich Is this still needed or can we close it?

[mheon]

@cevich Poke - anything going on here?

[cevich]

Not a single thing, safe to close.