error parsing called workflow: Job referencing reusable action tag errors out

[shaneDubbs]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

ARC (Actions Runner Controller)

Discussion Details

The same workflow will work for other repo's in our org, this workflow was previously working in this repo. Tag 6.4.1 is off the same commit as tag 6, tag 6.4.1 succeeds, tag 6 fails.

Error is:

Invalid workflow file: .github/workflows/workflowName.yml#L48
error parsing called workflow
".github/workflows/workflowName.yml"
-> "actionsRepo/.github/workflows/reusableAction.yml@v6" (source tag with sha:1199a05a37bedf7322ed2c8d874f852c1f6f98ee)
--> "./.github/workflows/build_model_reusable_dispatch.yml"
: workflow was not found. See https://docs.github.com/actions/learn-github-actions/reusing-workflows#access-to-reusable-workflows for more information.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[rodri-oliveira-dev]

If both tags really resolve to the same commit, I don't think I would spend much time looking for a difference in the workflow contents. GitHub should be parsing the same tree in that case.

One thing I would test is the nested workflow reference:

uses: ./.github/workflows/build_model_reusable_dispatch.yml

Since this workflow is itself being called from another repository, I would try using the newer same-repository syntax instead:

uses: $/.github/workflows/build_model_reusable_dispatch.yml

$/ explicitly resolves against the repository and commit of the workflow containing the reference, which removes some ambiguity from nested reusable workflows.

I would also try calling the outer workflow directly by the SHA shown in the error:

actionsRepo/.github/workflows/reusableAction.yml@1199a05a37bedf7322ed2c8d874f852c1f6f98ee

If the SHA and v6.4.1 work but v6 fails, while both tags peel to exactly the same commit, that would strongly suggest a ref-resolution/parser issue on the Actions side rather than a problem with the workflow file itself.

I'd verify that with:

git rev-parse v6^{commit}
git rev-parse v6.4.1^{commit}

If those are identical, the different result for the two refs is definitely interesting.

[sgriffen-vermeer]

Could you compare the tag objects themselves?

Command:

git cat-file -t v6.4 && git rev-parse v6.4 && git rev-parse 'v6.4^{commit}'

Output:

tag
8a14f388c2125f9926f1de116635b14c7d98c39d
3ad6fb61bd8302503bc9cb50ecf60915a9b4cbd5

Command:

git cat-file -t v6.4.1 && git rev-parse v6.4.1 && git rev-parse 'v6.4.1^{commit}'

Output:

commit
3ad6fb61bd8302503bc9cb50ecf60915a9b4cbd5
3ad6fb61bd8302503bc9cb50ecf60915a9b4cbd5

As a non-destructive test, I'd create a temporary lightweight tag pointing at the exact same commit and call the reusable workflow through that tag.

I created a new lightweight tag v6.4-test (with the command git tag v6.4-test from the v6.4.1 commit, here's the details:

Command:

git cat-file -t v6.4-test && git rev-parse v6.4-test && git rev-parse 'v6.4-test^{commit}'

Output:

commit
3ad6fb61bd8302503bc9cb50ecf60915a9b4cbd5
3ad6fb61bd8302503bc9cb50ecf60915a9b4cbd5

Using that v6.4-test tag seems to work as expected. The nested workflow is pulled from the same commit that the v6.4.1 tag points to.

Also, are v6 / v6.4 created differently from the patch tags as part of your release process? For example, annotated or signed rolling tags vs lightweight patch tags?

The v6.4.1 tag was created through the creation of a GitHub Release on the website GUI. The v6 and v6.4 tags were created through the use of a community action in a workflow that ran with the v6.4.1 tag was pushed. It looks like that community action creates annotated tags (with the command git tag -fa ) which has worked for us up until we implemented the $/` new syntax in our workflows that reference other workflows or composite actions in the same repository as one another.

[rodri-oliveira-dev]

That result actually makes the annotated-tag angle more interesting.

One small thing first: if the command was literally:

git rev-parse 'v6^{commit}'

I would expect it to return a commit SHA, not tag. tag would normally be the output from:

git cat-file -t v6

So I think it would be useful to separate the tag-object SHA from the peeled commit SHA explicitly.

For example:

git cat-file -t v6
git cat-file -t v6.4
git cat-file -t v6.4.1

git rev-parse 'v6^{commit}'
git rev-parse 'v6.4^{commit}'
git rev-parse 'v6.4.1^{commit}'

git ls-remote origin \
  'refs/tags/v6' \
  'refs/tags/v6^{}' \
  'refs/tags/v6.4' \
  'refs/tags/v6.4^{}' \
  'refs/tags/v6.4.1' \
  'refs/tags/v6.4.1^{}'

Since v6 and v6.4 are annotated tags, seeing something like:

8a14f... refs/tags/v6.4
3ad6f... refs/tags/v6.4^{}

would be completely valid: the first SHA is the tag object itself and the second is the commit the tag points to.

If that peeled SHA is the same 3ad6fb61... used by v6.4.1, then I think we have a much stronger reproduction: the workflow tree is identical, but GitHub Actions behaves differently depending on whether the reusable workflow is reached through an annotated tag or a lightweight/direct commit ref.

At that point I'd also try one temporary lightweight tag pointing to 3ad6fb61.... If that succeeds while the annotated v6/v6.4 ref fails, it would isolate the issue very cleanly and would be a good minimal reproduction for the Actions team.

[sgriffen-vermeer]

So I think it would be useful to separate the tag-object SHA from the peeled commit SHA explicitly.

Command:

git cat-file -t v6.4 \
  && git cat-file -t v6.4.1

Output:

tag
commit

Command:

git rev-parse 'v6.4^{commit}' \
  && git rev-parse 'v6.4.1^{commit}'

Output:

3ad6fb61bd8302503bc9cb50ecf60915a9b4cbd5
3ad6fb61bd8302503bc9cb50ecf60915a9b4cbd5

Command:

git ls-remote origin \
  'refs/tags/v6.4' \
  'refs/tags/v6.4^{}' \
  'refs/tags/v6.4.1' \
  'refs/tags/v6.4.1^{}'

Output:

8a14f388c2125f9926f1de116635b14c7d98c39d        refs/tags/v6.4
3ad6fb61bd8302503bc9cb50ecf60915a9b4cbd5        refs/tags/v6.4^{}
3ad6fb61bd8302503bc9cb50ecf60915a9b4cbd5        refs/tags/v6.4.1

At that point I'd also try one temporary lightweight tag pointing to

Using a lightweight tag (v6.4-test, manually created locally and pushed named) pointed to 3ad6fb61bd8302503bc9cb50ecf60915a9b4cbd5 (the same commit the tag created on GitHub's release page v6.4.1) worked just fine. the annotated tag v6.4 did not work.

[rodri-oliveira-dev]

I think we're very close to isolating this, but I noticed two things in those results that I'd verify before drawing a conclusion.

git rev-parse 'v6^{commit}' should return a commit SHA. If v6 is an annotated tag, ^{commit} recursively peels the tag until it reaches the commit, so tag would not normally be the output of that command.

Also, the ls-remote command in the comment mentions v6 and v6.4.1, but the output shows v6.4 and v6.4.1.

Could you run these explicitly?

git cat-file -t refs/tags/v6
git rev-parse refs/tags/v6
git rev-parse 'refs/tags/v6^{commit}'

git cat-file -t refs/tags/v6.4
git rev-parse refs/tags/v6.4
git rev-parse 'refs/tags/v6.4^{commit}'

git cat-file -t refs/tags/v6.4.1
git rev-parse refs/tags/v6.4.1
git rev-parse 'refs/tags/v6.4.1^{commit}'

And remotely:

git ls-remote --tags origin \
  'refs/tags/v6' \
  'refs/tags/v6^{}' \
  'refs/tags/v6.4' \
  'refs/tags/v6.4^{}' \
  'refs/tags/v6.4.1' \
  'refs/tags/v6.4.1^{}'

What I'm particularly interested in is whether we end up with something like:

v6        -> tag object A -> commit 3ad6fb61...
v6.4      -> tag object B -> commit 3ad6fb61...
v6.4.1    ----------------> commit 3ad6fb61...

If that's the case, and @v6.4.1 works while @v6 / @v6.4 fail, then the annotated-vs-lightweight tag difference becomes a very strong suspect.

It would also explain why the SHA reported by Actions for @v6 may not look like the expected commit SHA: it could be reporting or resolving through the tag object rather than the peeled commit somewhere in the reusable-workflow resolution chain.

At that point, creating a temporary lightweight tag pointing to exactly 3ad6fb61bd8302503bc9cb50ecf60915a9b4cbd5 would be a useful final control test. If that works immediately, we'd have a pretty clean minimal reproduction for an Actions ref-resolution issue involving annotated tags.

[sgriffen-vermeer]

We should ignore the the output of the v6 tag for now and just care about v6.4 vs v6.4.1. shaneDubbs and I have temporarily pointed that tag to a different older commit so projects using the v6 tag reference in their workflows aren't broken while we do this v6.4.1 and v6.4 testing, sop that will point to a different commit than the one we care about that contains the $/ workflow references.

Could you run these explicitly?

Command:

git cat-file -t refs/tags/v6.4 \
	&& git rev-parse refs/tags/v6.4 \
	&& git rev-parse 'refs/tags/v6.4^{commit}'

Output:

tag
8a14f388c2125f9926f1de116635b14c7d98c39d
3ad6fb61bd8302503bc9cb50ecf60915a9b4cbd5

Command:

git cat-file -t refs/tags/v6.4.1 \
	&& git rev-parse refs/tags/v6.4.1 \
	&& git rev-parse 'refs/tags/v6.4.1^{commit}'

Output:

commit
3ad6fb61bd8302503bc9cb50ecf60915a9b4cbd5
3ad6fb61bd8302503bc9cb50ecf60915a9b4cbd5

Command:

git ls-remote --tags origin \
  'refs/tags/v6.4' \
  'refs/tags/v6.4^{}' \
  'refs/tags/v6.4.1' \
  'refs/tags/v6.4.1^{}'

Output:

8a14f388c2125f9926f1de116635b14c7d98c39d        refs/tags/v6.4
3ad6fb61bd8302503bc9cb50ecf60915a9b4cbd5        refs/tags/v6.4^{}
3ad6fb61bd8302503bc9cb50ecf60915a9b4cbd5        refs/tags/v6.4.1