Using the --no-cache tag?

[christopherpickering]

Hi,

Thanks again for the tool! I'm noticing that when I change my release_tasks.sh file (here's my yaml:

build:
  docker:
    web: nodb.Dockerfile

release:
  image: web
  command:
  - ./release_tasks.sh

setup:
  addons:
  - plan: heroku-postgresql
    as: DATABASE
  - plan: heroku-redis
    as: REDIS

)

Then change are not reflected in the next few builds by the action. Now if I go to heroku and manually run a build after linking to my GitHub repo, it will use the lates release_tasks.sh.

Do you think it is because I didn't add the --no-cache option to the docker build? I'm trying it w/ that tag now.

If that is the case, do you think the --no-cache tag should be a default option so that we are always building the latest repo version?

[gonuit]

Hi @christopherpickering!

Did the --no-cache flag help? Yeah, it probably should be set as the default one. I will take a look at it.

[christopherpickering]

@gonuit thanks, it seems to have! I'm surprised it is needed though. I guess GitHub is caching the action? How else would the old code survive in a docker build in an action? They must be reusing containers.

[christopherpickering]

So adding the --no-cache makes the build nice, however release tasks are not run using the current build lol.

If I run a build > then change a database table name > run a new build, the latest release tasks will run using the OLD table names.

If I login to heroku cli and run the same command it uses the new table names.

Do you have any ideas where I might look next? thanks!

[christopherpickering]

I wonder if we can try with the "-v" flag in the release command? https://github.com/gonuit/heroku-docker-deploy/blob/master/src/heroku/release_docker_container.ts

Is the release command running in the same session as the build/push? I wonder if heroku is loosing context of what "container" is?

[christopherpickering]

I'm thinking its a heroku problem, not understand what to release when building docker locally and pushing it. They don't have any good docs saying exactly what will be "released" when you push a docker.

I'm trying this out, which is building @ heroku, using the heroku.yml:

name: demo

on:
  schedule:
    - cron: '0 0 * * *'

  workflow_dispatch:

jobs:
  heroku-deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Check out repository
        uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: Heroku login credentials
        run: |
          cat > ~/.netrc <<EOF
            machine api.heroku.com
              login $HEROKU_EMAIL
              password $HEROKU_API_KEY
            machine git.heroku.com
              login $HEROKU_EMAIL
              password $HEROKU_API_KEY
          EOF
        env:
          HEROKU_API_KEY: ${{ secrets.HEROKU_API_KEY }}
          HEROKU_EMAIL: ${{ secrets.HEROKU_EMAIL }}
      - name: Add Heroku remote
        run: |
          heroku stack:set container --app $HEROKU_APP_NAME
          heroku git:remote --app $HEROKU_APP_NAME
        env:
          HEROKU_APP_NAME: ${{ secrets.HEROKU_APP_NAME }}
      - name: Push to Heroku
        run: git push heroku master -f

[gonuit]

So... First of all, thanks for this huge feedback. I will add the --no-cache flag as a default one, as this can save other peoples time 💪🏻

[danthedaniel]

@gonuit hmm... this is the exact behavior I saw that prompted me to add support for simultaneous release and web images. I don't think we need --no-cache as a default.