I am trying to write a GitHub actions script to automatically build a docker image, and then push it into the GitHub Container Registry when new code is checked in to the main branch. This is the code that I'm using to try to log into the container registry:
name: Build and publish Docker image.
on: [push]
jobs:
publish-docker-image:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v2
- name: Login to GitHub Container Registry
uses: docker/login-action#v1
with:
registry: ghcr.io
username: ${{github.actor}}
password: ${{secrets.CONTAINER_REG_ACCESS}}
For more context, the CONTAINER_REG_ACCESS secret is a personal access token, though it was created by a different member of my organization.
This error shows up in GitHub after it runs its automated tests on my pull request.
Run docker/login-action#v1
Logging into ghcr.io...
Error: Error response from daemon: Get "https://ghcr.io/v2/": denied: denied
What is the best practice from logging into the GitHub container registry using a GitHub actions script? Is there a way to log in using an organizations credentials instead of my personal GitHub ID?
Related
EDIT: My repo resides in github enterprise
I have a very basic github workflow action as below:
All it does is to run a powershell script as mentioned in here.
name: First Github Action
on:
workflow_dispatch:
jobs:
first-job:
name: First Job
runs-on: ubuntu-latest
steps:
- name: Display the path
run: echo ${env:PATH}
shell: pwsh
Unfortunately, it just keeps waiting for the runner to pick up. Below is the message it is being displayed.
Requested labels: ubuntu-latest
Job defined at: {myUserName}/{repoName}/.github/workflows/{myFileName}.yml#refs/heads/main
Waiting for a runner to pick up this job...
EDIT: I created another public repo and ran the action. It is still waiting.
Unfortunately, I cannot share my public repo as it is an enterprise github repo owned by the company I work in.
Assuming you are running this on GitHub Cloud (or github.com):
GitHub Actions is only free for public repositories, otherwise you have to pay for a license
Switching the repo's visibility from from private to public may not cause the workflow that is stuck to be picked up. You will likely need to cancel it and queue a new one.
Make sure your workflows are located in .github/workflows folder.
Assuming you are running this on GitHub Enterprise Cloud (GHEC):
You need to make sure that your admin has Actions enabled
You need to make sure that your admin has Actions allowed for repositories not owned by an organization
Assuming you are running this on GitHub Enterprise Server (GHES):
You need to make sure that your admin has Actions enabled
You need to make sure that your admin has Actions allowed for repositories not owned by an organization
You will not be able to use GitHub hosted runners as you have in your YAML file
You will need to use a self-hosted runner and your GitHub admin can provide you the details of what you need to use.
The workflow you have in your question does in fact work:
https://github.com/tjc-actions-demo/simple-actions
The issue is going to be either permissions related or configuration related. Depending on your environment, you will need to troubleshoot based on my suggestions above.
I have an ECS Fargate cluster that is being deployed to through BitBucket Pipelines. I have my docker image being stored in ECR. Within BitBucket pipelines I am utilizing pipes in order to push my docker image to ECR and a second pipe to deploy to Fargate.
I'm facing a blocker when it comes to Fargate deploying the correct image on the deployment. The way I have the pipeline is setup is below. The docker image gets tagged with the BitBucket Build Number for each deployment. Below is the pipe for the Docker image that gets built and pushed to ECR:
name: Push Docker Image to ECR
script:
- ECR_PASSWORD=`aws ecr get-login-password --region $AWS_DEFAULT_REGION`
- AWS_REGISTRY=$ACCT.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com
- docker login --username AWS --password $ECR_PASSWORD $AWS_REGISTRY
- docker build -t $DOCKER_IMAGE .
- pipe: atlassian/aws-ecr-push-image:1.6.2
variables:
IMAGE_NAME: $DOCKER_IMAGE
TAGS: $BITBUCKET_BUILD_NUMBER
The next part of the pipeline is to deploy the image, that was pushed to ECR, to Fargate. The pipe associated with the push to Fargate is below:
name: Deploy to Fargate
script:
- pipe: atlassian/aws-ecs-deploy:1.6.2
variables:
CLUSTER_NAME: $CLUSTER_NAME
SERVICE_NAME: $SERVICE_NAME
TASK_DEFINITION: $TASK_DEFINITION
FORCE_NEW_DEPLOYMENT: 'true'
DEBUG: 'true'
Within this pipe, the attribute for TASK_DEFINITION specifies a file in the repo that ECS runs its tasks off. This file which is a JSON file, has a key pair for the image ECS is to use. Below is an example of the key pair:
"image": "XXXXXXXXXXXX.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$DOCKER_IMAGE:latest",
The problem with this line is that the tag of the image is changing with each deployment.
What I would like to do is have this entire deployment process be automated, but am having this step prevent me from doing that. I had came across this link that shows how to change the tag in the task definition in the build environment of the pipeline. The article utilizes envsubst. I've seen how envsubst works, but not sure how to use it for a JSON file.
Any recs on how I can change the tag in the task definition from latest to the Bitbucket Build Number using envsubst would be appreciated.
Thank you.
I would like to automatically start CockroachDB (as a container) with GitHub Actions for automated tests. These tests include testing all ssl modes. That's why I would like to add a user and certificates to CRDB. I searched for environment variables but the there is no documentation for it on the website. At least not for the container.
Currently I only add it insecurely:
test-backend:
runs-on: ubuntu-latest
services:
cockroachdb:
image: cockroachdb/cockroach
ports:
- 26257:26257
CockroachDB is currently not able to be used as a service in Github Actions which is explained in this issue https://github.com/cockroachdb/cockroach/issues/87043.
As an alternative, here is an example of how it can be run in Github Actions: https://github.com/cockroachdb/sequelize-cockroachdb/blob/188f092dda80a2b11aae1381e83b9581f7bdbfc8/.github/workflows/ci.yml#L37 (instead of --insecure pass --certs-dir).
I have a number of secrets, stored in Settings/Secrets/Action of my repo.
The various secrets are used by my application but none of them are used in the command.
name: BuildCheck
on:
push:
pull_request:
branches: [main]
# Allows you to run this workflow manually from the Actions tab
workflow_dispatch:
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout#v3
- uses: actions/setup-node#v3
with:
node-version: 14
- run: npm ci
- run: npm run build
Do I need to add all the variables under env top level map in the config file above in order for the action to use them?
This seems to break my automated flow of managing secrets with Doppler.
Is there a way to inject all secrets, without explicitly specifying them? (I did look at the docs but failed to find if this is possible)
Coming from Vercel, which does this it feels like a bit of a step back.
There's a bit to unpack here.
Do I need to add all the variables?
The short answer: yes.
However what's good to consider is that secrets often only configure connections between system in the form of secret keys or application access using a license or credentials.
It is not common to add other configuration options inside the secrets.
Under env: top level map in the workflow file?
I would discourage putting secrets in the top level env.
Reason is that env will be exposed to all subsequent jobs. In case someone adds a job that's not trusted with this information (say an external action) it could become a problem.
So what's good practice?
Firstly: Split configuration from secrets:
Using configuration files for configuration options.
Using secrets for secret keys or other credentials.
Secondly: Using security first.
Configure each workflow step with just the information it needs
Explicitly pass secret variables to action parameters
Lastly: store configuration as close to the app as possible, optionally having multiple - each for a different environment.
Comparison with Vercel
Vercel abstracts away the workflow entirely and as a result can only do very specific things. The nature of each system is different and gives you different levels of flexibility.
Firstly: Split configuration from secrets:
Using configuration files for configuration options.
Using secrets for secret keys or other credentials.
There is now another option:
GitHub Actions – Support for configuration variables in workflows (Jan. 2023)
Today, we are adding support for configuration variables in GitHub Actions
Previously, you needed to store this configuration data as encrypted secrets in order to reuse values in workflows.
While extremely secure, this method did not allow for easy storage and retrieval of non-sensitive configuration data such as compiler flags, usernames, server names etc.
Configuration variables allows you to store your non sensitive data as plain text variables that can be reused across your workflows in your repository or organization.
You can define variables at Organization, Repository or Environment level based on your requirement.
Configuration variables can be accessed across the workflow using a new vars context.
The following example shows how configuration variables can be used in a workflow.
jobs:
display-variables:
runs-on: ${{ vars.RUNNER }}
steps:
- name: Use variables
run: |
echo "Repository variable : ${{ vars.REPOSITORY_VAR }}"
echo "Organization variable : ${{ vars.ORGANIZATION_VAR }}"
Note: Variables feature is in public beta
Learn more about configuration variables
We have notifications on deployments, which are send to the corporate chat. When user run code locally, there is some amount of information to identify 'who run the code' ($USER, $HOSTNAME, etc).
When the same code is triggered from CI, I would like to have information on 'who is the cause' for this workflow. It may be a github account name for the user to click on `workflow_dispatch', or author for commit in git, or author or PR, etc.
Is there such info available to workflows in Github Actions?
You might be interested by the Github Context concept.
There, you'll see that on each workflow, you can access context variables, such as the github.actor variable to access the login of the user that initiated the workflow run.
TIP: You can print the workflow GitHub variables using the following step:
- name: Show GitHub context
env:
GITHUB_CONTEXT: ${{ toJson(github) }}
run: echo "$GITHUB_CONTEXT"
shell: bash
Otherwise, here is a payload sample to know what are the available variables.