Select Topic Area

Question

Body

First and foremost, I am brand new to Github Actions and not totally sure if I'm posting this in the right place. Please feel free to point me in the right direction if need be! Thanks. Anyhoo...

I've been using GitHub Pages for years, but just recently started switching the deployments over to GitHub Actions. It's great! Learning a bunch and having fun. At first it was only the basic Jekyll GitHub Pages Deploy kinda workflows, but it got my foot in the door.

I'm tinkering on a new project right now that has two different workflows. The first one is the same classic Jekyll Deploy workflow which is automatically triggered on pushes to main. The second workflow is for running a small "import" ruby script on a cron schedule. It scrapes some data out there on the world wide web, creates a couple files, and then commits those changes directly to main. Pretty simple stuff, super easy to get going. I was pleasantly surprised.

Eventually I discovered the needs: option and also figured out how to reuse workflows. That way I could just call the Jekyll workflow from the end of the Ruby one. At this point the ruby.yml file was looking something like this:

jobs:
  import:
    steps:
    - name: Checkout (v4)
    - name: Set up Ruby (v1.161.0)
    - name: Import new episodes (bundle exec ruby import.rb)
    - name: Commit changes (stefanzweifel/[email protected])
  deploy:
    needs: import
    uses: ./.github/workflows/jekyll.yml

I'm not including all the details there, but you get the idea. And as I said before, the Jekyll workflow is extremely boiler plate stuff. I added the necessary workflow_call: so that I'm able to call it there at the end. And it does indeed successfully get called in the expected order and flow. It's got the two classic GitHub Pages Deploy jobs to build and then deploy. Those all go off without a hitch as you can see!

I can confirm that the "Commit Changes" step in the import job is committing new changes, and I can see the details as such...

0ebdf6f..d5f1d90  main -> main

But then in the immediately followed deploy / build job, which has its own checkout step (using v4 of course), I can see very clearly that the checkout process is grabbing the older commit 0ebdf6f instead of the new one d5f1d90.

Is this expected behavior? Am I missing some piece of the puzzle. Thanks!