3.5 I was excited to see action composition until I realized that the composed action will still be showed as one step and that it can just compose actions instead of whole workflows.

I want to share whole jobs across my repos, including matrixes and all. I could wrap some common workflows into one action, but then the whole complexity will be hidden in a single step.

So I resorted to creating GHA Templates and manually synching them with a CLI tool[1], which isn't great, but at least I don't have to copy-paste changes across repos and I can keep a "main version" of the workflow

1: https://github.com/fregante/ghat

I have some good news. You'll be able to do this with reusable workflows and it's shipping soon. https://github.com/github/roadmap/issues/98

If you need to lock down reusable deployment workflows, these features will enable that. https://github.com/github/roadmap/issues/249 https://github.com/github/roadmap/issues/220

Related to 3.3 (You can’t restart a single job of a workflow), is there any reason why the numeric id of a specific job run isn't available anywhere? There's GITHUB_RUN_ID, but that only identifies the workflow run, not the individual jobs, and this isn't unique across run/job restarts. Services like https://coveralls.io/ need an actually unique job run id, and they could also use the numeric id to link to the specific job run in a build matrix.

To clarify this further, in https://github.com/xmonad/xmonad/actions/runs/1201348600, GITHUB_RUN_ID=1201348600, GITHUB_RUN_NUMBER=168, but there's no way to get the 3514203530 out of https://github.com/xmonad/xmonad/runs/3514203530 (that's one of the jobs of that run).

No, there's no reason why that isn't available. This is a very sensible request and we'll add this information to the context available to workflow runs.

Thanks!

I love GitHub Actions, so much so I’ve published lots of Actions on the Marketplace. I love that I can contribute to better pipelines for all.

That said, I have frustrations with the management of the GitHub Actions repositories: which is to say, there isn’t any. Most issues and Pull Requests languish, without acknowledgement or engagement.

I appreciate that managing issues and contributions is a full time job, and your team probably doesn’t have capacity right now: if you could magic up some capacity, that would be great, but… a more realistic request would be to evaluate capacity and follow Terraforms lead in being open about pausing contributions —- rather than READMEs that encourage contributions, which (despite the best of intentions) will never be reviewed.

e.g: https://www.hashicorp.com/blog/terraform-community-contribut...

Thanks :-)

We’ve archived a few repos in the last couple months because of this. A we’ll also look at the contributor changes you suggested.

Regarding 3.5 (actions calling other actions) – please continue investing in composite actions. They are a well-balanced abstraction for managing workflow complexity. I can see how they could become too powerful and encourage bad patterns (YAML programming), but that's a good problem to have.

I’m glad they’re working for you. Reusable workflows is our next feature to improve reuse. https://github.com/github/roadmap/issues/98

We have recently switched to GitHub actions and in addition to the above, there are two others which impact us:

Sometimes the checkout action fetches the wrong commit! The SHA in the GitHub environment variable says one commit, but the actual code is different(!). Because we don't know why this happens we basically need to do an unshallow fetch of the whole repo to be sure we have what we expect.

Using autoscaling self hosted runners, it is not currently possible to instruct the agent to finalise the current job but to accept none after it. This is essential to avoid broken workflows while scaling in. Gitlab supports this via a signal, but there is no equivalent.

> Sometimes the checkout action fetches the wrong commit!

I'm a product manager at GitHub, and I'm investigating this now. Feel free to drop me an email ([email protected]) if you can share more information about the workflow runs that were affected by this.

> Using autoscaling self hosted runners, it is not currently possible to instruct the agent to finalise the current job but to accept none after it.

We're building this functionality out right now, so that you can have self-hosted runners that will run a single job and we will let you subscribe to webhooks that will let you scale up/down your fleet of runners.

@jeremyepling I'd be interested to know if Github Actions will eventually replace Azure DevOps pipelines? Thanks

From an outside perspective it looks like neither of them is going away anytime soon and that they just want you to use the one that you feel more comfortable with.

It's pretty clear that Azure DevOps is going the way of the dodo. They haven't even finished migrating their "old" pipelines to the "new" pipelines, and I'm already seeing some things that are GitHub Actions only.

They never officially killed Silverlight so I doubt they'll kill Azure DevOps either. They most likely will at some point deemphasize Azure DevOps to favor GitHub Actions tho.

I wouldn't be surprised if Azure DevOps still pops up in random places for decades to come or if they decide to "unify" the two products without changing the underlying codebases (like OneDrive for business actually using Sharepoint under the hood).

Unlike Google, Microsoft seems to commit to legacy software to a fault. As long as there are enterprises paying good money for support, it'll probably not go away completely.

EDIT: Microsoft only stopped licensing OEM Windows for Workgroups 3.11 in 2008 (15 years after the first release of WfW 3.11). Apparently it was still being used by some embedded device manufacturers: https://docs.microsoft.com/en-us/archive/blogs/jcoyne/its-th...

That’s correct. You should use the one that best meets your needs.