32495aae-4b01-4a90-badf-1d53d394b8cd

You would need to either remove or rename them, or update your dockerfile accordingly

do you know why these docker files don't work on railway but they work on ECS?

because the cache mounts must be in the format --mount=type=cache,id=s/

yeah but why?

that's how railway expects them

is this documented somewhere

yes -

ok, if i set a railwy config, will that supersede wahtever is automatically selecting this Dockerfile?

there is no way to disable the auto detection of the Dockerfile

they would need to be moved elsewhere, renamed, or removed

yeah, don't really want to change our prod setup just to see if railway works for us :/

you could always create a branch that has the applicable changes on the Dockerfile for testing on Railway

yeah i just think the named Dockerfile would ideally be where our production build lives. Feels like there should be a way to turn this off

do you see anything wrong with this part of the dockerfile vs what railway is expecting?

RUN --mount=type=cache,id=s/39cf0fd8-0e6b-4bef-8f82-2e5865bddac1-/var/cache/apk,target=/var/cache/apk \
  ln -vsf /var/cache/apk /etc/apk/cache \
  && apk add --update curl git findutils python3 make gcc g++ musl-dev \
  jpeg-dev cairo-dev giflib-dev pango-dev

i am still getting the same error

is that your service id?

i think so, i copied it from the dashboard

you mean the URL?

no, i did the command + k instructions from the docs you sent

this

do you have other cache mounts in the dockerfile?

bind mounts

bind mounts are not supported

I don't think that's mentioned in the docs

guess i should just drop these

yep

Looks like I can set the railway dockerfile path successfully to something else, which also works for us but is annoying to have to maintain multiple dockerfiles e.g. these cache mounts make it faster to do installs, etc, especially for dev

yep but afaik you can't set it to something that doesn't exist and have it skip using a dockerfile

correct, but i needed to fork my dockerfile anyways to support railway's more limited functionality

so I just set it to Dockerfile.railway

perfect

i think i'm close but one of my docker images is giving me an error here that i'm not getting in prod - i'm not sure why this could happen - thought that was the whole point of docker 😂

have you seen anything like this? did some searching, but haven't found a solution

alternatively is there an easy way for me to ssh into the box / understand what's inside the built version of this container besides adding echo statements?

havent seen this error before, and theres no ssh.

are you using nixpacks or a dockerfile right now?

dockerfile

forgive me for asking, but how have you confirmed that?

also from the build logs

sounds good to me, but yeah unfortunately I haven't seen that issue before, are you able to build and run this locally with buildkit

hmm, yeah - tho our setup in prod is moreso what i'm trying to mirror

Here's our github action for pushing this image, incase anything looks like we're doing something incompatible with railway

  push_worker_image:
    environment: ${{ inputs.environment }}
    name: 'Push Job Queue Worker Image'
    runs-on: warp-ubuntu-latest-x64-4x
    env:
      NODE_ENV: ${{ secrets.NODE_ENV }}
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-east-2

      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v2

      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          build-args: |
            TURBO_TEAM=${{ env.TURBO_TEAM }}
            TURBO_TOKEN=${{ secrets.TURBO_TOKEN }}
          cache-from: type=gha
          cache-to: type=gha,mode=min
          file: ./apps/flux/worker/Dockerfile
          platforms: linux/amd64
          provenance: false
          target: prod
          push: true
          tags: ${{ steps.login-ecr.outputs.registry }}/${{ secrets.ECR_WORKER_REPOSITORY }}:${{ github.sha }}

it's worth noting that we're setting the target to prod - is that possible on railway? if not, I think it will default to this target anyways.

this is building and pushing an image, I'm not sure what it has to do with railway because you are not deploying your railway service from an image

What is your dockerfile builder doing?

fwiw, I don't work for railway.

their builder is building and publishing an image but I'm not sure the relevance of the action you showed

Got it- that clarifies a lot. The flair is a bit confusing (lol what is a conductor)
This is the action we’re using to build and push this image we’re deploying to prod where it works. Kinda why I’d expect railway to just work on this but ehh guess I should just find an alternative

a conductor is railway's term for moderator.

I'm sure this issue is just a simple misconfiguration somewhere that's being overlooked