Localstack is always v3.2.0

[mherger]

I'm using pretty much the example integration in my workflow:

      - name: Start LocalStack
        uses: LocalStack/setup-localstack@v0.2.0
        with:
          image-tag: latest
          install-awslocal: true
          use-pro: false

But no matter what I put as the image-tag, I'd always get v3.2.0, which doesn't work for us due to localstack/localstack#10621. So I must use v3.4.0 (or 2.2.0 - which we've used before).

FWIW: I'm seeing similar odd behaviour installing a specific version using pip3 install localstack==2.2.0. It would seemingly install that version, but I'd still get the above issue.

[lakkeger]

Hi @mherger,
Thanks for reaching out.
I looked into your issue and by getting 3.2.0 cli version that usually caused by an outdated pip version. To resolve it please run pip install --upgrade pip.
However please be aware that the reported CLI version is not the image version at start up!

Regarding the image tag issue, I was unable to reproduce it as the action seems to work perfectly in our pipelines and the digests are matching with the ones on docker hub for the latest image.
See pipelines run below:

• https://github.com/localstack/setup-localstack/actions/runs/9364958722/job/26019393505
• https://github.com/localstack-samples/sample-serverless-image-resizer-s3-lambda/actions/runs/9367194006/job/26020069020

To find which image is pulled exactly please find similar to the following line:
https://github.com/localstack/setup-localstack/actions/runs/9364958722/job/26019393505#step:3:489
And refer to the reported digest:
https://github.com/localstack/setup-localstack/actions/runs/9364958722/job/26019393505#step:3:621
which is the exact same as our latest version in this case:
https://hub.docker.com/layers/localstack/localstack-pro/latest/images/sha256-85e234e2fb56ca4897fffbbb1391f29d2e8b4a205fc63e1e1a238e5e8d1d5b20?context=explore

If the issue still persist, please share a link to a pipeline run or run logs and a minimal example of your setup.

[mherger]

Thanks for getting back to me! I must admit that I'm really confused. I now understand that the CLI doesn't have to be of the same version as the runtime. That would explain what I was seeing (CLI v2.2.0, but runtime is v3.2.0). But then I decide to dump the localstack log to the console so I would see what was going on. And in there I would even see reference to v3.4.1.dev (I believe?). Which means it actually should be running a version which had localstack/localstack#10621 fixed. Alas, I'm still seeing that issue.

So what am I really running? The version shown in the log file, or the one reported on the GH Action output?... And why would it still show the issue described in localstack/localstack#10621 anyway?

FWIW: I thought I'd use act to run the workflow locally for easier investigation. But what shall I say? It's working perfectly fine under act...

[mherger]

Another note: I then tried to define what runtime to use. But I'm not sure how exactly this would work. Eg. I tried to pull the Docker image before installing the CLI, hoping a localstack start would use that image. That didn't work. Or I used the services section in the GH workflow. Didn't work either. Is there any way to define in a GH action what Localstack version to use?

[lakkeger]

To address everything above:

To verify the version of the image itself you can check with docker itself by running docker ps | grep localstack.
Here the 2nd column would tell you what is the actual version you're running.

To fix the cli issue, perhaps I can add upgrade pip in the action itself so it would reflect the actual version you are referring in the image.

About pinning the image version explicitly by yourself, you can use the IMAGE_NAME env variable that takes precedence. For further config options you can find more in our documentation.

And last but not least I must confess, that I've found a bug in the action which results in that the action ignores the version parameter unless it's set to latest (seems like an old unnoticed bug), so your report regarding the version input being ignored/behaving strangely sometimes seems absolutely justified.

This is what actually happens behind the scene:

1. you set the version as an input
2. the action tries to install the right CLI version
3. CLI install falls back to 3.2.0 if pip is too old (with the default python on the runners)
4. the right version of LocalStack image is pulled
5. HOWEVER the cli start (since no image version set) ignores the downloaded version (not picking up automatically the existing version) so in the end you end up with the observed 3.4.1.dev version as latest is the one the cli starts up

Absolutely sorry for the confusion 🙏 I fix this in a PR today when it's merged you can use it with the main version of the action. There is a planned patch release this week anyways.

[mherger]

Thanks! This is now working as expected.

Now I have to figure out why localstack/localstack#10621 isn't fixed for me. I'll continue there.