Passing Parameters to GH Actions (From a Variable)

Hi!

I’m looking for a way to pass parameters to GitHub Actions without hard coding it into the yaml file. This is because I’d like to reuse the yaml across projects. Is this possible?

For Context

my yaml file builds a docker image and publishes it to the GitHub Container Registry and it works fine. However, currently I’m using the repository name for the name of the docker image.

I’d like to arbitrarily set this value without writing it in the yaml file.

With Travis CI, you have the ability to set environment variables per repository in the dashboard, then use that variable.

Is this possible with GitHub Actions? I have an alternative solution regardless; I’m just wondering if this is possible before trying something else.

Help is appreciated, thanks!

1 Like

In principle you could use secrets to store your variables.

However, as long as you need only the repository name you can get that from the github context, specifically github.repository (you might want to remove the owner prefix, depending on the desired output).

Hi! Thanks for the reply!

Yeah, I tried this previous but unfortunately it didn’t work unfortunately for some reason.

It does not appear to let you use secrets arbitrarily like that.

the docker image format is ghcr.io/:organisation/:image-name::version, where : denotes a wildcard (except for version tag).

e.g.:

ghcr.io/${{ steps.get_owner.outputs.VALUE }}/${{ steps.release_name.outputs.VALUE }}:${{ steps.get_version.outputs.VALUE }}

This will comfortably release a docker image who’s name matches the repository.

the release_name step is:

 echo ::set-output name=VALUE::$(if [ "${{ secrets.RELEASE_NAME }}" ]; then echo ${{ secrets.RELASE_NAME }}; else echo "$GITHUB_REPOSITORY" | awk -F / '{print $2}'; fi)

Which executes fine, but cannot be used in the build step because it won’t output secrets like that, I think.

Give us a shout if you come up with anything else. Thanks again!

Not sure if it helps, but I want to add that if you manually invoke runs (workflow_dispatch), then you can define input fields and pass arguments as desired.

You can set an environment variable using set-env at the beginning of the steps:

- run: echo ::set-env name=RELEASE_NAME::$(if [ "${{ secrets.RELEASE_NAME }}" ]; then echo ${{ secrets.RELASE_NAME }}; else echo "$GITHUB_REPOSITORY" | awk -F / '{print $2}'; fi)

Then use it in the next steps:

ghcr.io/${{ github.repository_owner }}/${{ env.RELEASE_NAME }}

Hope that helps. :v:t4:

@eiymba ,

In the workflow, you can use the default environment variableGITHUB_REPOSITORY’ to get the owner and repository name (owner-name/repo-name).
If you want only get the repository name, you use the following method to extract it from ‘GITHUB_REPOSITORY’.

- name: get repository name
  run: |
    echo $GITHUB_REPOSITORY
    repo_name=${GITHUB_REPOSITORY##*/}
    echo $repo_name

If you want to only get the owner name, you can use the expression ‘${{ github.repository_owner }}’ to get it from the github context.

- name: get owner name
  run: |
    owner_name=${{ github.repository_owner }}
    echo $owner_name

The following is an example as reference: https://github.com/TestWorkflowsRML/GHA-Syntax/actions/runs/264370292/workflow#L21

Hi @nathane ! Thanks a lot of taking a look at this. <3

I’ve tried this solution before but the build process does not appear to echo secrets when used in this manner. It’s entirely omitted for me.

Give us a shout if you have any more ideas! Thanks again!

Hey @brightran thanks a lot for taking a look at this! <3

This is currently the solution I’m already using. I’m looking to use an arbitrary name at build time instead of the repository name, without writing it in the yaml file, and setting this as a secret does not appear to work. For example, if my repository is called my-app-docker, I’d want to name my docker image my-app instead of my-app-docker.

Give us a shout if you have any more ideas! Thanks again!

This might be the best approach thus far! It works but the only down side is, it’s not automatically triggered.

Thanks for taking a look at this! <3

I’ve found a solution.

I create a separate workflow which generates an artefact, and then I can check to see if it’s available for my release workflow. to consume.

I’ll make a write up when I have time.

Thanks for your help, everyone!

1 Like