gonuit / heroku-docker-deploy Goto Github PK

View Code? Open in Web Editor NEW

107.0 1.0 24.0 515 KB

Build, Push and Release a Docker container to Heroku.

License: MIT License

TypeScript 100.00%

heroku-docker-deploy's Introduction

Heroku Docker Deploy - GitHub Action

Build, Push and Release a Docker container to Heroku 🚀.

Getting started

Your GitHub action workflow file might look like this:

# Your workflow name.
name: Deploy to heroku.

# Run workflow on every push to master branch.
on:
  push:
    branches: [master]

# Your workflows jobs.
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      # Check-out your repository.
      - name: Checkout
        uses: actions/checkout@v2


### ⬇ IMPORTANT PART ⬇ ###

      - name: Build, Push and Release a Docker container to Heroku. # Your custom step name
        uses: gonuit/[email protected] # GitHub action name (leave it as it is).
        with:
          # Below you must provide variables for your Heroku app.

          # The email address associated with your Heroku account.
          # If you don't want to use repository secrets (which is recommended) you can do:
          # email: [email protected]
          email: ${{ secrets.HEROKU_EMAIL }}
          
          # Heroku API key associated with provided user's email.
          # Api Key is available under your Heroku account settings.
          heroku_api_key: ${{ secrets.HEROKU_API_KEY }}
          
          # Name of the heroku application to which the build is to be sent.
          heroku_app_name: ${{ secrets.HEROKU_APP_NAME }}

          # (Optional, default: "./")
          # Dockerfile directory.
          # For example, if you have a Dockerfile in the root of your project, leave it as follows:
          dockerfile_directory: ./

          # (Optional, default: "Dockerfile")
          # Dockerfile name.
          dockerfile_name: Dockerfile

          # (Optional, default: "")
          # Additional options of docker build command.
          docker_options: "--no-cache"

          # (Optional, default: "web")
          # Select the process type for which you want the docker container to be uploaded.
          # By default, this argument is set to "web".
          # For more information look at https://devcenter.heroku.com/articles/process-model
          process_type: web
          
   
          
### ⬆ IMPORTANT PART ⬆ ###

Logs

All build logs will be grouped:

And available to you.

heroku-docker-deploy's People

Contributors

Stargazers

Watchers

heroku-docker-deploy's Issues

Github build succeeds when heroku release tasks fail

Hi,

Thanks for the tool! I found that if the build fails in heroku you cause the GitHub action to fail as well, which is great. However, if the release tasks fail in heroku the GitHub action does not fail, as I would have expected.

Is it possible to cause the github action to fail if a release task fails?

For example, see this build: https://github.com/Riverside-Healthcare/extract_management/runs/2679015731?check_suite_focus=true

You can see there was an error in my release task:

And if you check the heroku log you can see the deploy failed because the release failed:

I'd expect that if a release fails, the GitHub action would fail.

Thanks for checking this out!

Dockerfile not found

Hi!

I just set up a workflow using this action, but it fails as it cannot find the Dockerfile. The error log is:

Error: File: "Dockerfile" does not exist.

but the Dockerfile is in the root of my project. This is how I set up the action:

name: Heroku container deploy

# Controls when the action will run. 
on:
  # Triggers the workflow on push but only for the master branch
  push:
    branches: [ master ]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Build, Push and Release a Docker container to Heroku.
        uses: gonuit/[email protected]
        with:
          email: ${{ secrets.HEROKU_EMAIL }}
          heroku_api_key: ${{ secrets.HEROKU_API_KEY }}
          heroku_app_name: ${{ secrets.HEROKU_APP_NAME }}
          dockerfile_directory: ./
          dockerfile_name: Dockerfile
          process_type: web

In case it's needed, the repo is public

Build fails on gha due to missing layer

Building a spring-boot + gradle application using the action version 1.3.3 fails, but the build succeeds using docker push action.

Dockerfile: https://github.com/three-consulting/epoc-backend/blob/60f980ce2d257970e8f0fba9d9d816ac5115e9a4/Dockerfile
Working build using a different action: https://github.com/three-consulting/epoc-backend/blob/60f980ce2d257970e8f0fba9d9d816ac5115e9a4/.github/workflows/pull-request.yaml#L37-L45
Failing build using heroku-docker-deploy: https://github.com/three-consulting/epoc-backend/blob/60f980ce2d257970e8f0fba9d9d816ac5115e9a4/.github/workflows/main.yaml#L32-L41
I also tried the heroku build without the --no-cache flag, which also fails.

Github actions logs on failure:

Run gonuit/[email protected]
  with:
    email: ***
    heroku_api_key: ***
    heroku_app_name: ***
    dockerfile_directory: ./
    dockerfile_name: Dockerfile
    docker_options: --no-cache
    process_type: web
  env:
    JAVA_HOME: /opt/hostedtoolcache/Java_Adopt_jdk/17.0.2-8/x64
Logging into the Heroku docker registry...
  Login Succeeded
  
Building docker container...
  Sending build context to Docker daemon  5.071MB
  
  Step 1/15 : FROM gradle:jdk17 as builder
  jdk17: Pulling from library/gradle
  8e5c1b329fe3: Pulling fs layer
  6eba7eb4b070: Pulling fs layer
  7f5190524da8: Pulling fs layer
  4b95bc0fbc88: Pulling fs layer
  001c63a4ae36: Pulling fs layer
  311a12340251: Pulling fs layer
  ad71688bca0d: Pulling fs layer
  001c63a4ae36: Waiting
  311a12340251: Waiting
  ad71688bca0d: Waiting
  4b95bc0fbc88: Waiting
  6eba7eb4b070: Verifying Checksum
  6eba7eb4b070: Download complete
  8e5c1b329fe3: Verifying Checksum
  8e5c1b329fe3: Download complete
  4b95bc0fbc88: Verifying Checksum
  4b95bc0fbc88: Download complete
  001c63a4ae36: Verifying Checksum
  001c63a4ae36: Download complete
  311a12340251: Verifying Checksum
  311a12340251: Download complete
  ad71688bca0d: Verifying Checksum
  ad71688bca0d: Download complete
  7f5190524da8: Verifying Checksum
  7f5190524da8: Download complete
  8e5c1b329fe3: Pull complete
  6eba7eb4b070: Pull complete
  7f5190524da8: Pull complete
  4b95bc0fbc88: Pull complete
  001c63a4ae36: Pull complete
  311a12340251: Pull complete
  ad71688bca0d: Pull complete
  Digest: sha256:5e94c8494940ef924a6f389f2f2f24b1841977f66aae01fa308156f03eb99f57
  Status: Downloaded newer image for gradle:jdk17
   ---> 9e7038d609f1
  Step 2/15 : WORKDIR /builder
   ---> Running in 6dc57dbd183c
  Removing intermediate container 6dc57dbd183c
   ---> 0af3555fe184
  Step 3/15 : COPY . .
   ---> 9db07687d857
  Step 4/15 : RUN gradle clean bootJar
   ---> Running in 89a873bb6d18
  
  Welcome to Gradle 7.4.2!
  
  Here are the highlights of this release:
   - Aggregated test and JaCoCo reports
   - Marking additional test source directories as tests in IntelliJ
   - Support for Adoptium JDKs in Java toolchains
  
  For more details see https://docs.gradle.org/7.4.2/release-notes.html
  
  Starting a Gradle Daemon (subsequent builds will be faster)
  > Task :clean
  > Task :processResources
  > Task :loadKtlintReporters
  > Task :runKtlintCheckOverKotlinScripts
  > Task :ktlintKotlinScriptCheck
  > Task :runKtlintCheckOverMainSourceSet
  > Task :ktlintMainSourceSetCheck
  > Task :runKtlintCheckOverTestSourceSet
  > Task :ktlintTestSourceSetCheck
  > Task :ktlintCheck
  > Task :compileKotlin
  > Task :compileJava NO-SOURCE
  > Task :classes
  > Task :bootJarMainClassName
  > Task :bootJar
  
  BUILD SUCCESSFUL in 1m 26s
  12 actionable tasks: 12 executed
  Removing intermediate container 89a873bb6d18
   ---> bf779a34f39c
  Step 5/15 : RUN java -Djarmode=layertools -jar build/libs/epoc.jar extract --destination layers
   ---> Running in 4289a2b4394a
  Removing intermediate container 4289a2b4394a
   ---> 01925369a118
  Step 6/15 : FROM azul/zulu-openjdk-alpine:17-jre
  17-jre: Pulling from azul/zulu-openjdk-alpine
  df9b9388f04a: Already exists
  1a2da678c736: Pulling fs layer
  1a2da678c736: Verifying Checksum
  1a2da678c736: Download complete
  1a2da678c736: Pull complete
  Digest: sha256:86d43e40a17f5a4d1fe7b8559968f56540bd8b03da46ea91450f035781fddfe2
  Status: Downloaded newer image for azul/zulu-openjdk-alpine:17-jre
   ---> b60b8273e2f0
  Step 7/15 : RUN adduser -u 1999 -D user
   ---> Running in 5f230d1cf5ec
  Removing intermediate container 5f230d1cf5ec
   ---> b6fb9dd0acc7
  Step 8/15 : WORKDIR /app
   ---> Running in 9f6add921f8a
  Removing intermediate container 9f6add921f8a
   ---> 8504e5b4be88
  Step 9/15 : COPY --from=builder /builder/layers/dependencies ./
   ---> df6d26cc28be
  Step 10/15 : COPY --from=builder /builder/layers/spring-boot-loader ./
   ---> 5a930035468e
  Step 11/15 : COPY --from=builder /builder/layers/snapshot-dependencies ./
   ---> 279aed585a67
  Step 12/15 : COPY --from=builder /builder/layers/application ./
  failed to export image: failed to create image: failed to get layer sha256:dcfbbfa372e9066a774d698fa26da47808d940a8f3cf2507e4ea1b925a855c39: layer does not exist
Error: Building container failed.
Error: undefined

edit: updated links

Push fail when using customized Dockerfile file name

Hi,
Please help to resolve the issue when I use a customized Dockerfile file name.

Update to use Node.js 16?

Getting this in my Github Actions

Node.js 12 actions are deprecated. For more information see: https://github.blog/changelog/2022-09-22-github-actions-all-actions-will-begin-running-on-node16-instead-of-node12/

which states

Node 12 has been out of support since April 2022, as a result we have started the deprecation process of Node 12 for GitHub Actions. We plan to migrate all actions to run on Node16 by Summer 2023.

Non root case for dockerfile_directory not working

Thanks for this simple and intuitive action!

It works perfectly when the Dockerfile is in the root of the repository (dockerfile_directory: ./).
However, I had no luck modifying this setting to a folder. It looks like the script runs cd <dockerfile_directory> before docker build ..., but none of my tries worked.

Do you have an example that works, or is this a bug?

Thanks!

-p and --port in docker_options emit error, unknown flag

Either docker_options: "--no-cache -p 3000" or docker_options: "--no-cache -p 3000" is not working. May I have some indication of how to bind port or pass more docker options?

Allow single build, multiple pushes

If we want to deploy the same image to multiple apps, currently it requires each one to run the whole build/push/release phase.
Even on a single app, one has to push the image to both the release and web workers, making it two build/push/release builds, wasting CPU time that way.

It would be great to be able to split those and build only once, and then push multiple times the already built image.

UPDATE: Just found out that 1.4.0 supports multiple process types. It at least allows for single build for web,release. The option for multiple apps however is still missing

Using the --no-cache tag?

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?

Build options such as --build-arg fails

Hi there,

Thanks for your Github Actions and work.
I tried to use it on our project and it seems it fails when we pass --build-arg VALUE="key" in options.

I didn't try but from having a look the source seems to be fine, will you be able to verify this?

Here is the failure we get:

Run gonuit/[email protected]
Logging into the Heroku docker registry...
Building docker container...
  "docker build" requires exactly 1 argument.
  See 'docker build --help'.
  
  Usage:  docker build [OPTIONS] PATH | URL | -
  
  Build an image from a Dockerfile
Error: Building container failed.
Error: undefined

here is a sample of what we're using and it fails:

  deploy-integration:
    runs-on: ubuntu-latest
    name: Deploy
    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Deploy (Build, Push & Release)
        uses: gonuit/[email protected]
        with:
          email: ${{ secrets.HEROKU_LOGIN }}
          heroku_api_key: ${{ secrets.HEROKU_API_KEY }}
          heroku_app_name: deno-fireplace
          dockerfile_directory: .
          docker_options: '--build-arg key="${{ secrets.SECRET_KEY }}" --build-arg commit_hash="${{ github.sha }}"'

Docker requires BuildKit

Hello , will it possible to enable BuildKit when building images ?

 Step 7/9 : COPY --chmod=0755 ["scripts", "/home/apps/"]
  the --chmod option requires BuildKit. Refer to https://docs.docker.com/go/buildkit/ to learn how to build images with BuildKit enabled
Error: Building container failed.

Needs an option to enable the Heroku release phase

Heroku requires the release process be specified in order to use the new container as the source of the release command:

https://devcenter.heroku.com/articles/container-registry-and-runtime#release-phase

Ex:

$ heroku container:release web release
Releasing images web,release to your-app-name... done
Running release command...
Migrating database.

Without this I was having trouble as the release script referenced the last Github-originated build and not the most recent build pushed to the Heroku container registry.