I managed to get a very minimal example of the Github Actions social media auto-poster workflow working. It proves that in theory the necessary sequence is possible. The reason it’s tricky is because I am trying to run all the auto-poster jobs in a job matrix in order to parallelize them. I’ve almost run out of build minutes this month, so here’s a summary, so I can pick it up again next month. It’s not really intended for anyone in particular except me.
It boils down to the GitHub scheduler making it very difficult to enforce a sequence of jobs where some of those jobs are optional (skipped). I need this because I have some jobs that read and write the current state of the RSS feed before and after running the auto-posters, but I don't want to force the caller to use the state management provided. They should be able to manage their own state.
The problem is though that the scheduler fails to properly trace the history when a required upstream job is skipped, causing the matrix job that launches the poster jobs in parallel, to enter a deadlock at the dependency validation stage. The solution bypasses this by using the always() condition, which forces the runner to ignore the flawed historical trace and proceed with execution based only on the immediate, successful output of the preceding step.
Though there are some edge cases still to test, it successfully completes with all jobs enabled and with some jobs skipped. The devil is always in the detail. #