Can GitHub Action Job continue from the state the previous job left (without artifact or complicated procedure)?

Viewed 190

I previously had a GitHub Action with a single Job that was doing 3 things:

  • Build the .net application
  • Run Unit Tests
  • Run Integration Tests

Now, I splitted this job in 3 different ones because:

  • I like to experiment
  • I like to see the GitHub PR updating the steps separately
  • I can/want run the Unit and Integration tests in parallel so the entire process can complete quickly

This is the current GitHub Action:

name: Pull Request Checks

on: 
  pull_request:
    types: [opened, synchronize, reopened, labeled]
  
jobs:

  build:
    name: Build
    runs-on: ubuntu-latest
    steps:
    - name: Checkout
      uses: actions/checkout@v2
    - name: Buid VS solution
      id: build
      run: dotnet build "FSharp project/MyProject.sln" -c RELEASE

  unit-tests:
    name: Unit Tests
    needs: [build]
    runs-on: ubuntu-latest
    steps:
    - name: Checkout
      uses: actions/checkout@v2
    - name: Unit Tests
      id: unit-tests
      run: dotnet test "FSharp project/UnitTests/UnitTests.fsproj" -c Release --no-build --filter "TestCategory!=SKIP_ON_DEPLOY"

  integration-tests:
    name: Integration Tests
    needs: [build]
    runs-on: ubuntu-latest
    steps:
    - name: Checkout
      uses: actions/checkout@v2
    - name: Integration Tests
      id: integration-tests
      if: github.event.action == 'labeled' && github.event.label.name == 'pr:ready'
      run: dotnet test "FSharp project/IntegrationTests/IntegrationTests.fsproj" -c Release --no-build --filter "TestCategory!=SKIP_ON_DEPLOY"

Ideally the Integration Tests job run only when the PR is labeled "pr:ready" (this point has still to be tuned/solved maybe).

This entire process works.
I had to duplicate the Checkout step in each job, this means they are completely different "machine".
If that is true, why the dotnet test with --no-build is still able to work?
MS changed the behaviour of that flag, so honestly I don't remember if the dotnet cli version is running here is able to reuse the possibly executed build or it runs a build if needed itself.

So I'm not entirely sure the Checkout results to have a completely fresh environment in "successive" jobs, and if this is the case... there is a way to reuse the previous "state" in a simple way (like a simple parameter, not using artifacts and similar stuff)?

0 Answers
Related