actions
Support for pre-services setup steps
The services capability is an elegant way to automate the setup and tear down of a service, but there are use-cases where preparation tasks need to occur in a hook before services are started.
Possible examples include:
- Adjusting system parameters (e.g. file descriptor limits, socket buffer sizes, etc)
- Creating filesystem resources shared/used by containers
- Configuring ACLs
- Configuring network adapters and ip filters
- Installing packages
See https://github.com/actions/virtual-environments/issues/348 for an example use case of a workaround (although note, it will be solved by other means)
One form this could take would be something like:
runs-on: ubuntu-latest
setup-steps:
- name: Stop Mysql
shell: bash
run: |
sudo service mysql stop || true
services:
# services
steps:
# post-services steps
Here's another use case: I'd like to use containers to run my workflows, but I need to do some particular docker setup on the machine before I can. Example: setting up multiarch / QEMU support in Docker.
/cc @chrispat
I wouldn't call it setup-steps since folks would think they should put their setup-xxx actions in there. It would also cause oddities with checkout. If we did it, it would be something like init-steps? It would have to be clear it's before services starts.
In that line of thinking it could be before under the services node.
runs-on: ubuntu-latest
services:
before:
- shell: bash
run: |
sudo service mysql stop || true
mysql:
image: mysql
ports:
- xxx/tcp
steps:
# post-services steps
I would prefer to call it pre and just define that it runs pre on the machine. So no services would be configured etc. This would go along well with potentially adding a pre entrypoint into the actions model.
Of course then we have the question of if you can run actions there and if so what happens if they define a pre. In general I think yes you can use actions and if you happen to use them in the pre section the main will be run there and the pre defined in the actions will be run before the main.
@ethomson I think container might be a different challenge here as I can see a good reason to have pre but still have that run inside the container. We also need to consider future compliance scenarios where customers want to force everything runs in a container and nothing runs on the "host".
@bryanmacfarlane good point, that behavior seems likely
@chrispat that makes to me what would the order be between an action pre entrypoint and a user defined pre. IMO an ideal order would be
- user defined pre steps ordered as defined (including those which are actions which are inlined as pre, then main)
- actions defined in non-pre contexts (e.g. "steps:") that have registered a pre method (in the order they are defined)
Here's another use case: I'd like to use
containers to run my workflows, but I need to do some particular docker setup on the machine before I can. Example: setting up multiarch / QEMU support in Docker.
Another example might be configuring a docker credential helper or actually running docker login so that I can subsequently run a job / service using a container image from a private registry.
Hi, I have a use case where a docker container is built and uploaded as a Github Package to another private repository. This requires the use of docker login to pull the docker image to use in a job step. Allowing pre-steps to happen would give the workflow a chance to authenticate before the docker image is pulled
After thinking about this a bit more I think a better option would be to introduce a new init section in the YAML. This would be a set of steps that would be run as part of the overall job initialization for the runner. We would need to think about the ordering because there are somethings like setting up contexts that I think would still need to be done before any user defined steps could run.
There should be ability to have pre and post job scripts running on the runner machine. like a global runner configuration. Pre-Jobs: running a script inside runner as soon as it get's a job
Usecases: Check for some conditions before running the job (for example which repositories it comes from) or simply send a slack message as soon as my runner get a job running
Gitlab CI has this already long time ago: https://docs.gitlab.com/ee/ci/yaml/#pre-and-post
With the event of Docker hub will start rate limiting pulls we need to be able to specify config for docker, such as what registry to use and credentials for logging in. This would also simplify extending your workflow with custom containers that needs to be private.
Right now you need to create a public action or a public container image which does not work sometimes for enterprises.
Maybe just allowing setup of docker credentials helper in an init phase would massively increase the usability of Action for enterprises.
We have a feature coming soon that will let you specify credentials for job and service containers which should resolve a number of the issues. For actions implemented as containers we would recommend you start publishing those to the new GitHub container registry as the traffic between that and the actions runners is not throttled.
Docs for this feature here: https://github.blog/changelog/2020-09-24-github-actions-private-registry-support-for-job-and-service-containers/
This should still be on our radar.
We have a feature coming soon that will let you specify credentials for job and service containers which should resolve a number of the issues. For actions implemented as containers we would recommend you start publishing those to the new GitHub container registry as the traffic between that and the actions runners is not throttled.
Yes, this solves a number of issues, but we have e.g. following use-case: We use hashicorp/vault-action to get our credentials and tokens inside our GitHub Actions workflows. So we urgently need the option to so something like this:
job:
job1:
name: Job 1
runs-on: [self-hosted]
before:
- name: Import secrets
id: import-secrets
uses: hashicorp/vault-action@v2
with:
url: https://your-vault-url.com
method: kubernetes
path: your-path
role: your-role
secrets: |
path/to/token token | TOKEN_FOR_REGISTRY
services:
my_service:
image: ghcr.io/yourcompany/image-name:latest
ports:
- 80:80
credentials:
username: example
password: ${{ before.import-secrets.outputs.TOKEN_FOR_REGISTRY }}
steps:
- ...
FYI: I also tried reading the token from the vault in a previous job and then accessing it later in my other jobs like described in https://docs.github.com/en/actions/using-jobs/defining-outputs-for-jobs but this doesn't seem to work for tokens because of security reasons.
@ruben-hoenle-fnt urgently? Bro, this ticket is open since 2020. I recommend to move to Gitlab CI urgently
I was chatting to @TingluoHuang who suggested that this might be related to: https://github.com/actions/runner/issues/2603 - which has also been up for over a year without comment or triage.
Eyes on would be appreciated when the team has time to consider it.
Is there any update on this ticket? I'm encountering a similar issue accessing a private registry: failed to verify certificate x509: certificate signed by unknown authority
