Weak cache key for Crystal cache in generated CI workflow

[wout]

The current cache key is often causing trouble when pushing changes to Github. It depends on any changes in the shard.lock file:

key: ${{ runner.os }}-crystal-${{ hashFiles('**/shard.lock') }}

If, for example, something is changed in a migration that has been committed before, the CI is going to fail. Unless a new dependency has been installed or the shard.lock file has been changed in some other way.

I'm not yet sure what a better approach would be; I'm just leaving this here as I've had issues with this across multiple projects.

UPDATE: Looking at the code, it's probably because lucky_tasks is in the cache.

[jwoertink]

I'm not using Crystal cache in that way on my projects.... Maybe it's not necessary? I'm also seeing several other things in that file that should be cleaned up like default to a higher version of postgres, bump action/cache to v3, and so on...

Here's one cache thing I'm doing in my CI that I kinda like:

 worker:
    runs-on: ubuntu-22.04
    steps:
      - uses: actions/checkout@v3

      - name: Install Crystal
        uses: crystal-lang/install-crystal@v1
        with:
          crystal: 1.9.2

      - name: Cache Worker Binary
        uses: actions/cache@v3
        with:
          path: ./bin/worker
          key: ${{ github.sha }}-worker

      - name: Build Worker
        run: |
          shards build worker --production --release  --skip-postinstall --skip-executables

deploy:
    runs-on: ubuntu-22.04
    needs: [joystick, worker]
    steps:
     - name: Cache Worker Binary
        uses: actions/cache@v3
        with:
          path: ./bin/worker
          key: ${{ github.sha }}-worker

So we build our mosquito and main app in separate parallel jobs, then when we need to deploy, the deploy worker just pulls the already built cache binaries. I doesn't quite help here since the generated CI doesn't include stuff for a deploy flow, but maybe we can set things up similarly so if you wanted to add a deploy flow like this, it would be easy?

[wout]

Yeah, this is stock Lucky, so I'm just using what I'm given 😬️.

I like that you're building your worker on GitHub. I'm going to give that a go too. I'm currently using a single docker file with a switch using an ENV var (webserver/jobworker) to build the appropriate app.

So yes, if the stock flow would include a basic setup for the app and even an example for Mosquito, that would be great!