How to reuse scripts - Yaml import/require

[Vadorequest]

I looked at the documentation and couldn't find any way to reuse code with GitHub Actions.

Let's say I have two different .yml files in my .github/workflows/ folder, one per environment (staging, prod), how can I reuse parts of the common logic without duplicating the configuration?

Yaml/yml doesn't handle imports natively, but maybe there is an alternative?

[foxundermoon]

+1 need feature
same as azure pipelines template

[ghost]

+1 need feature
same as azure pipelines template

[umarcor]

IMHO, supporting YAML anchors alone would already be a significant improvement. Anchors should be expanded by the parsers, so that no additional fixes are required.

• https://docs.travis-ci.com/user/build-stages/using-yaml-aliases/
• https://confluence.atlassian.com/bitbucket/yaml-anchors-960154027.html

[uladkasach]

Are there any plans to support this feature?

[ethomson]

Yes, this is something we intend to support. However, I do not have an ETA.

Unfortunately, this is functionality in the core of the GitHub Actions product, it's not part of our starter workflows. So I'm going to close this issue, since this repository is for tracking issues in the starter workflows themselves.

When we have more information on this functionality, we'll announce it on the GitHub Blog. And if you have questions or comments about GitHub Actions overall (including template or anchor support), then the Product and Support teams are happy to help at the GitHub Community Forum.

[jaredhill4]

Hmm. Why is this closed? Is there now documentation for this somewhere? I have been unable to find it.

[maximivanov]

While code reuse in Github Actions is (still) not available, you may want to consider this workaround to deploy to multiple targets from a single workflow file.

# List branches that should trigger the deploy, e.g. dev branch deploys to staging, master to prod
on:
  push:
    branches:
      - dev
      - master

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      # Add conditional steps to configure environment-specific settings, depending on current branch
      # Note secrets are stored in Github Repository Secrets, here we only reference variable names
      - name: Set env vars (dev)
        if: endsWith(github.ref, '/dev')
        run: |
          echo "TARGET_URL=staging.mysite.com" >> $GITHUB_ENV
          echo "DEPLOYMENT_KEY_GH_SECRET=SECRET_NAME_FOR_DEV" >> $GITHUB_ENV
      - name: Set env vars (prod)
        if: endsWith(github.ref, '/master')
        run: |
          echo "TARGET_URL=prod.mysite.com" >> $GITHUB_ENV
          echo "DEPLOYMENT_KEY_GH_SECRET=SECRET_NAME_FOR_PROD" >> $GITHUB_ENV

      # Some environment-independent steps: download code, build, cache, etc
      ...

      # Use environment variable defined above to deploy to the correct environment
      - name: Run deployment action
        uses: whatever-you-deploy-with@1
        with:
          target: ${{ env.TARGET_URL }}
          deployment-key: ${{ secrets[env.DEPLOYMENT_KEY_GH_SECRET] }}

Github Actions: deploy to multiple environments from single workflow.

[johnnybenson]

Alright folks, who's gonna bite the bullet and go work at @github so we can have this feature

[AverageComet250]

I would but I'm not even 14 Thanks, Shravan Mandava

…

________________________________ From: Johnny Benson ***@***.***> Sent: Friday, March 26, 2021 1:17:55 AM To: actions/starter-workflows ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [actions/starter-workflows] How to reuse scripts - Yaml import/require (#245) Alright folks, who's gonna bite the bullet and go work at @github<https://github.com/github> so we can have this feature — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#245 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AL5SCZOGFQDNWISZ7ZIM3DTTFPOEHANCNFSM4JWOAOHQ>.

[Namstel]

I would very much like this feature. We're looking to deploy a serverless SAAS application, and having to copy and paste the steps is asking for issues down the line.

[Yehonal]

Every continuous integration service out of there supported at least YAML merge operator/anchors from the day 0, except github...this single limitation is forcing us to use external tools to workaround this otherwise you can easily end up with lot of duplicated code just to run simple operations. Have you ever heard about DRY?

[umarcor]

@Yehonal my understanding is that implementing anchors is fundamentally incompatible with the usage of matrix. Therefore, a huge breaking change would be required in order to fix that. I recommend putting the complex logic in your own scripts and using the workflow YAMLs for the bare minimal plumbing. For instance, you can have the matrix of a job defined through your own script, which allows to dynamically generate jobs.

[Yehonal]

@umarcor I moved all the possible tasks to a github action script, but in my case I have to run 5 different parallel jobs which have a preparation part composed by other externap actions (cache restore, aws configurarios etc) and which is the same for every job. It takes more or less 20 lines per each job which means 80 lines of repeated code that you have to maintain. And it's very prone to errors.

Maybe github can provide a custom implementation of the anchors by using context/expressions

[Vadorequest]

It's a bit hard to believe this (huge) DX issue hasn't been addressed in the past 18 months.

It's probably a priority issue at that point. I haven't seen anything getting done on that topic, and I don't believe it's being worked on either.

[gianpo86]

Ok, let's keep this post alive cause this feature would be incredibly useful!

[Eddyuop]

ส่งจาก iPhone ของฉัน เมื่อ 16 ก.ค. 2564 เวลา 15:34 เขียนโดย Gianluca ***@***.***>:  Ok, let's keep this post alive cause this feature would be incredibly useful! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[mike-potter]

I've been looking into something like https://github.com/mithro/actions-includes where there would be a "compile process" for creating the actual Github actions from src files to allow better reusable include structures. Whether in a commit hook or just a manual operation needed whenever the actions were updated.

Edited: although after playing with actions-includes, it's definitely a bit rough. Still looking for a better alternative.

[ThomasWillumsen]

I think this might have been solved with the Composite Actions https://docs.github.com/en/actions/creating-actions/creating-a-composite-action
https://github.blog/changelog/2021-08-25-github-actions-reduce-duplication-with-action-composition/

[mike-potter]

While the improved Composite Actions help, there is still a need for "include" functionality for other common elements, such as common environment variables across jobs, or small code snippets.

I'm using a bash/awk script that "compiles" my actions from "src" and "include" folders into the main workflows folder (inspired from the actions-includes idea above). This also allows me to support some other local complexity with local project overrides. We have a standard project build framework, but projects can override the "include" files in their local folder.

[alxsbn]

@mike-potter we almost develop the same system (with org secrets to share variables ... but it's not convenient to be honest)

[umarcor]

Ref: actions/runner#1182

[MichaelVoelkel]

This is still not resolved, right? Reopen again please?

I'm not really getting composite actions from the example. You create a bash script and call it. What we need is more yml files.

[johnnybenson]

Tossing this onto the thread because it's somewhat of a solution to the problem and it has been working for me:

name: "Test: Client"

on:
  workflow_dispatch:
  pull_request:
    branches:
      - main
    paths:
      - client/**

concurrency:
  group: ${{ github.name }}-${{ github.workflow }}-${{ github.head_ref }}
  cancel-in-progress: true

jobs:
    test:
      uses: ./.github/workflows/test-typescript.yml
      with:
        app: client

I am able to reuse workflows at the job level with uses: path/to/some.yml.

A generic workflow can accept parameters and each application can instrument it from a "parent" workflow like the one above—where test-typescript.yml uses the passed parameters, runs on ubuntu, sets up node, caches dependencies, etc for the parent application.

So far, this has satisfied my concerns around divergence of behavior across workflows, allows me to organize and maintain the workflows with much less duplication. Getting a lot of use out of it in a very basic monorepo setup.

I'm sure there are pitfalls or drawbacks and reasons this won't work for everyone. I'm not interested in being a Github Workflow expert, I'm trying to make shit lol.

shoutout to @AverageComet250 you're almost old enough to work at Github! 😎

[aristotaloss]

You guys might find that this solves your problem (or partially), as it's pretty flexible and got me what I wanted from this issue:

https://docs.github.com/en/actions/using-workflows/reusing-workflows