Fix Workflow names instead of workflow file name

[kiatt210]

Fixes #31458 and maybe #25912

I added the name from the YAML file to the workflow object. If there is no name in the file, the name remains the filename.
I created an object to connect the run and workflow together, which was necessary to show workflow name in action run list.

(Easier to review with disabled whitespace changes, unfortunately there is a lot of them in runs_list.tmpl :( )

[wxiaoguang]

The variable shadowing is more complex now. And the name Run also seems ambiguous

I think it's better to do so:

{{range $run = .WorkflowActionRuns}}
    {{$actionRun := $run.ActionRun}}
    {{$workflow = $run.Workflow}}
    {{$actionRun.Title}}
    ...

[kiatt210]

Thanks for the idea, I did the changes.

[kemzeb]

LGTM!

[silverwind]

If there is no name in the file, the name remains the filename.

I tested in GitHub actions and they show the full path to the file when workflow name is absent, e.g. .github/workflows/ci2.yaml. Might be especially relevant to us because we look into both .github and .gitea folders so filename alone can be ambigous.

[yp05327]

IIRC, GitHub has some bugs of display workflow name. That’s why no one fix this issue for a long time I think.
I have no time the check the code, as this is approved too quickly, so I’m not sure whether this PR can handle some special cases which GitHub can not.

[kiatt210]

Do you have any idea which special cases I should check or where I should look for them?
Thank you!

[yp05327]

I still remember the details of one test I did. And I tested it in this PR. The result is as my thought.

For example, you have 2 branches, and the workflow files have same file name, but the workflow names are different.
Then the result is this:

In the list, the workflow name is Gitea Actions Demo which is defined in the main branch:

But in test branch, the workflow name is Gitea Actions Demo in test:

But they are all detected as the workflow Gitea Actions Demo.

So actually, the logic is still based on the file name, not the workflow name defined in the yml file.
That's why we are using file name but not workflow name here.

IIRC, this is caused by the original design of Gitea Action, if we want to use workflow names instead of file names,
we need to rewrite many places.

[delvh]

as per @yp05327, we should probably iron out edge cases first

stale

[wxiaoguang]

Stale for long time

[ghnp5]

Hey! Just wondering what's the state of this?
I'd love to get this in.

Also, it would be great if the name of the workflow could also be inside the workflow run page.
At the moment, what appears at the top in big font is the push message, and not the workflow name.

Many thanks!

[silverwind]

Seems like OP is unresponsive. Maybe someone should open another PR based on this one with the remarks from #31474 (comment) adressed.

[wxiaoguang]

Hey! Just wondering what's the state of this?

@ghnp5 I think there is a blocker for this change.

For example, you have 2 branches, and the workflow files have same file name, but the workflow names are different. Then the result is this
But in test branch, the workflow name is Gitea Actions Demo in test
But they are all detected as the workflow Gitea Actions Demo.

So actually, the logic is still based on the file name, not the workflow name defined in the yml file. That's why we are using file name but not workflow name here.

IIRC, this is caused by the original design of Gitea Action, if we want to use workflow names instead of file names, we need to rewrite many places.

Hmm, I think I could understand the problem more now. And yes, that's the key problem.

		commit, err := ctx.Repo.GitRepo.GetBranchCommit(ctx.Repo.Repository.DefaultBranch)
		entries, err := actions.ListWorkflows(commit)

The workflow information is only read from default branch.

Maybe we need to document the workflow behavior first (or are there already some documents we can refer?)

[yp05327]

IIRC, GitHub also has some issues when handling the workflow name from different branches. (by my test, about 1 year ago? maybe they have fixed it or not)

Maybe we need to document the workflow behavior first

So I strongly agree. Design the handling of workflow names in different branches with same name or maybe other special cases first.
For example, at least you should consider something like:

• same file name in different branches but different name defined in the file, which one should be the real name?
• different filename in different branches but same name defined in the file, which one should be the real name?

Then coding, and add tests to confirm whether it works well in this cases.

[ghnp5]

Some tests can be made in GitHub and see how it behaves, for those cases.

But, I was thinking something simple, like:

1. if the workflow exists in the default branch, then use its name (if it has a "name:")
2. otherwise, if the workflow is in another branch, just pick whatever first branch found

In most cases, this will be consistent across all branches, and if for some reason one branch is going to update the name of the workflow, it will eventually be merged to the default branch, and the name will be updated when that happens.

[yp05327]

How to define the first branch found? If some new branches are added, then the workflow name maybe changed, as the order maybe changed. So at least it should be something like the first created branch or the latest updated branch?

[ghnp5]

You're right to ask that. What I had in mind is that "it doesn't matter", so whatever order Gitea does now, for looping through the branches, could be kept :)

So in other words, "no order guaranteed", I was thinking. Just "random/whatever".

But if an order has to be defined, then I think "the latest updated branch" would make more sense.

[yp05327]

Yeah, from user side, some users may not even have this problem or they don't care about the order or something else, but the developers should do their best to cover all cases, IMO.
The solution is not clear in current and it is hard, as IIRC, GitHub also has some issues about this problem.
For example, if we decide to use your solution, then we should consider the first created branch or the latest updated branch which is best. Then the next. Unitil the solution is good enough, then we can fix it 😄
Anyway, this is a good first step to break the ice. Thanks a lot.