Skip to content

Instantly share code, notes, and snippets.

@sagikazarmark
Last active August 28, 2019 02:28
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save sagikazarmark/9f06d8af9812931337fb316d729b8117 to your computer and use it in GitHub Desktop.
Save sagikazarmark/9f06d8af9812931337fb316d729b8117 to your computer and use it in GitHub Desktop.
GitHub Actions issues

GitHub Actions issues

Use Case: Publish Docker image to Docker registry

As a project owner I would like to publish Docker images in the GitHub Docker registry

When certain refs are pushed to the repository:

  • master branch
  • new tag

According to the following rules:

  • master branch should be available as IMAGE:master and IMAGE:latest
  • tags should be available as IMAGE:tag
  • every tagged image should also be available as IMAGE:short_commit_sha

Issues

  • GITHUB_REF environment variable value is kinda useless (eg. add some functions to format the ref or expose the branch/tag name without the long ref)
  • logging in with the GITHUB_TOKEN secret does not work (actions/starter-workflows#66)
  • when using the actions/docker action for logging in, subsequent image pushes (regardless if I simply use docker push or the action itself) fail with missing basic auth error
  • when pushing to the GitHub Docker Registry, it creates actual Git tags from the Docker tags (WTF?)
  • image naming is really cumbersome (eg. docker.pkg.github.com/${GITHUB_REPOSITORY}/${{ github.event.repository.name }})

Use Case: Warm up workspace for multiple jobs

In order to achieve fast builds I want to do certain, heavy tasks once (eg. download project dependencies) And then share that "warmed up" workspace across every job

Currently I can't do that which makes build times longer.

Use Case: Cache certain artifacts between builds

In order to achieve fast builds I want to cache certain artifacts between builds

For example: Go build cache, Docker cache, etc.

It's not possible at the moment.

Further issues

Ease of use

  • Examples are dumb and buggy (that last bit actually improved a lot in the past few weeks)
  • The documentation does not help much
  • At this point I think extensive examples would make sense, because based on the documentation it is almost impossible to write workflows that run successfully for the first time

Local execution

It would help a lot if I could execute github actions locally. In the previous version it was a major advantage over other CI solutions.

Added services rarely work

When not mapping services to an exact port, I can rarely make them work: https://github.com/banzaicloud/pipeline/pull/2215/checks?check_run_id=199105708

Also: is there a local mysql instance preinstalled? Because 3306 port seems to be already in use.

Does GITHUB_TOKEN work?

An application that we use for license checks talks to the GitHub API to determine dependency licenses, but it looks like it gets rate limited (or the token doesn't even work in the first place; see the Docker use case)

https://github.com/banzaicloud/pipeline/pull/2215/checks?check_run_id=199105706

@dakale
Copy link

dakale commented Aug 28, 2019

Hey @sagikazarmark, I worked on the services so sad to hear it didnt work better for you. A big pain point thats been tripping people up is that service containers, in particular databases often do not start fast enough to be ready to receive connections by the time the job runs, which is likely a big part of the problem you were having connecting. Theres not really a good way to generically know when a service will be ready (wait 5 seconds? 10? less or more?) It depends on the service. Docker provides a healthcheck mechanism that I expected users to rely on, but I think the docs and examples do not effectively communicate that yet. For future reference for you and others trying to set this up, you can use something like:

services:
  mysql:
    image: mysql:5.7
    options: --health-cmd="mysqladmin ping" --health-interval=10s --health-timeout=5s --health-retries=3

With that setup, docker will report the health of the container respective to the healthcheck defined, and the runner polls that status before finalizing the "initialize containers step" and beginning the job, ensuring the service is actually ready

Hope that helps

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment