Help
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Copilot Lvl 2
Message 1 of 2

Job requiring another job that is created on the fly?

Hello, I'm trying to setup a workflow that has two jobs, a lint job and a build job, with the build job requiring the lint to complete successfully before proceeding.

 

What I've run into is that if I use samuelmeuli's lint-action it is spawning off a seperate job for each linter, with the lint job being marked as complete/successful as soon as it's finished spawning them. This is causing the build job to start as soon as the lint job has spawned off the linters, but ESLint and Stylelint are still running and build will continue even as the linters fail.

 

How can I set my build job to require the two on-the-fly jobs? If I add the ESLint and Stylelint to the build `needs` it will not even process the workflow marking it as an error to referene non existant jobs.

 

This is an example of what I am using:

name: STAGING - Lint and Build

on:
  push:
    branches-ignore:
      - master
jobs:
  Lint:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: "Setup Node.js"
        uses: actions/setup-node@v1
        with:
          node-version: 12.x
      
      - name: "Install Node Packages"
        run: npm ci

      - name: "Lint - Sass & Javascript"
        uses: samuelmeuli/lint-action@v1.3.0
        with:
          github_token: ${{ secrets.github_token }}
          eslint: true
          stylelint: true

  Build:
    runs-on: ubuntu-latest
    needs: Lint # Only run the build if linting suceeded.

    steps:
      - name: Test
        run: ls -la

This is what happens:

firefox_8CXddMBi8n.png

1 Reply
Highlighted
GitHub Staff
Message 2 of 2

Re: Job requiring another job that is created on the fly?

There is no such thing as a dynaimc job in GitHub Actions.  I think what that action is doing is using the API to create additional check_runs which is the underlying data store for how jobs outcome is stored.  The action is setting those check_runs as failed they are not failing the actual action which in turn is not failing your job.  I think you need to post an issue on the repo for that action ask why the don't fail the action when one of the linters fails.