Additional function(s): lowercase|uppercase

[DazWilkin]

Noob GitHub Actions user here.

My GitHub username includes uppercase characters.

My first GitHub Actions workflow builds a container image to push to GitHub Container Registry.

Container registries require lowercase repo names.

I wanted to be able to:

tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

But this errors because github.repository_owner includes uppercase.

I was unable to find a function nor any other way to pipe this value into lowercase and think such a function (and perhaps its companion uppercase) would be useful.

tags: ghcr.io/${{ lowercase(github.repository) }}:${{ github.sha }}

Or, is there a better way to achieve this?

env:
  REPO: my-username/some-repo
...
steps:
   ...
   tags: ghcr.io/${{ env.REPO }}:${{ github.sha }}

[airtower-luna]

The env approach is what I’d do, except that I’d use Bash parameter expansion to convert the case instead of hardcoding it:

      - name: downcase REPO
        run: |
          echo "REPO=${GITHUB_REPOSITORY,,}" >>${GITHUB_ENV}

Or if you need the tag in a run step you could do the parameter expansion right there.

[bergus]

Imo it's slightly nicer to use the (new-ish) operator syntax of bash:

echo "REPO=${GITHUB_REPOSITORY@L}" >> "${GITHUB_ENV}"

U
The expansion is a string that is the value of parameter with lowercase alphabetic characters converted to uppercase.

u
The expansion is a string that is the value of parameter with the first character converted to uppercase, if it is alphabetic.

L
The expansion is a string that is the value of parameter with uppercase alphabetic characters converted to lowercase.

[Likqez]

When you write a variable definition to GITHUB_ENV, subsequent steps will have it as an environment variable. For example

See here.

[rzaitov]

I found the lack of simple string manipulation functions very inconvenient. If someone wants to use the upper/lower case parameter expansion feature of Bash, ensure that your target runner has Bash v4.0 or above. Upper case parameter expansion has been available in Bash since version 4 bash-faq-061. Unfortunately, macOS runners have Bash 3.2, so this workaround is not available on such systems. One possible solution that works on both Ubuntu and macOS runners is to use tr (see comments below).

[Simran-B]

While using built-in shell functionality is probably more succinct, you could also use a string manipulation action if you want something that works the same regardless of the shell type:

    steps:
      - id: string
        uses: ASzc/change-string-case-action@v1
        with:
          string: ${{ github.repository }}
      - run: |
          echo "${{ steps.string.outputs.lowercase }}"

[Entepotenz]

I wrote an alternative to the ASzc/change-string-case-action version.
https://github.com/Entepotenz/change-string-case-action-min-dependencies

It is using pure python for the string conversion.
It does not depend on any library and therefore does not require any maintenance from security perspective :-)
Additionally I have a couple of tests running automatically before publishing.

[Hu1buerger]

@Entepotenz sounds reasonable to me

[ArnoudAtBreenservices]

How would you use it inside the run step, then?

[airtower-luna]

When you write a variable definition to GITHUB_ENV, subsequent steps will have it as an environment variable. For example:

      - name: downcase REPO
        run: |
          echo "REPO=${GITHUB_REPOSITORY,,}" >>${GITHUB_ENV}
      - name: use REPO
        run: echo "The value of REPO is: ${REPO}"

[FrostyLeaf]

The following commands can do this trick:

ABC=$(echo 'console.log("abc".toUpperCase())' | node -);
echo $ABC

In you case, it could be:

repo=$(echo 'console.log("${{ github.repository }}".toLowerCase())' | node -)
tags: ghcr.io/${repo}:${{ github.sha }}

[ystxn]

the reply before you already provided the most succinct solution. your response is confusing in suggesting that it's possible to run script within a step and interpret the value within a field in the same step, which is not possible.

[FrostyLeaf]

Python also does the exactly same thing:

ABC=$(echo 'print("abc".upper())' | python3.9 -)
echo $ABC

[Entepotenz]

IMHO:
I would feel uncomfortable running those bash commands basically calling eval in python or nodejs.

I am talking about those examples:

ABC=$(echo 'print("abc".upper())' | python3.9 -)
echo $ABC

ABC=$(echo 'console.log("abc".toUpperCase())' | node -);
echo $ABC

I think those two links describe much more secure solutions:

• https://github.com/orgs/community/discussions/25768#discussioncomment-4557471
• https://github.com/orgs/community/discussions/25768#discussioncomment-3249184

You can also check out the security best practices for GitHub actions: https://res.cloudinary.com/da8kiytlc/image/upload/v1651737641/GitHub-Actions-Security-Best-Practices_cheatsheet.pdf

[d3vpasha]

I don't like any answer above, for me, Github actions must have some built-in functions to do usual things like uppercase, camelcase, lowercase, etc..

[shellscape]

See this answer https://stackoverflow.com/a/63315136/416845 on how to use ${var^^} to uppercase

[ALERTua]

These worked for me:

      - name: lowercase github.repository
        run: |
          echo "IMAGE_NAME=`echo ${{github.repository}} | tr '[:upper:]' '[:lower:]'`" >>${GITHUB_ENV}

      - name: lowercase github.repository
        run: |
          echo "IMAGE_NAME=${GITHUB_REPOSITORY@L}" >> ${GITHUB_ENV}

then ${{ env.IMAGE_NAME }} or "${{ env.IMAGE_NAME }}:latest"

[bergus]

See also https://github.com/orgs/community/discussions/10553

[lordfolken]

None of these answers solve the actual problem.
If you want to run steps inside an image, then you need to first to be able to specify the image path, in order to pull the image.
Without variable expansion, an additional job is necessary that first lowercases the variable and then using that in a subsequent container job.
What a waste of resources.

[esaporski]

GitHub Actions has a lot of potential, but right now it feels like a half-finished product.

[randomairborne]

If i were to want to set a top-level environment variable, I have to be able to process that with the template system. There is no other option. Right now, it seems like this is impossible.