Support '/' in Github Workflows name #4559
Comments
bagbyte
added
the
question
|
Can you share the actual badge routes (org and repo name) you are using so that we can debug and test? Also what's the badge you are currently seeing from Shields? Are you getting Not Found, something else? |
|
I've set up a testing repository with a single workflow named |
calebcartwright
changed the title
|
This is one of those tricky edge cases where the badge service route needs to accept an optional param (the branch) that may or may not contain a I've not tried battling the route definition, but I don't see a Hopefully I'm wrong though and there's an easy fix that can be made to the route def. cc @badges/shields-maintainers |
|
It seems this is due to the |
|
@bagbyte - the issue/cause is understood, it's about resolution. There's a few limitations in how the badge routes are matched, and this is one of those as detailed above. The issue will need to be fixed by updating the route for the GH Workflow Status badge to account for the fact that the workflow names may include one or more shields/services/github/github-workflow-status.service.js Lines 21 to 26 in 0dce98b |
calebcartwright
added
bug
|
I think @bagbyte has a point about the encoding. You're right if we want to accept https://img.shields.io/github/workflow/status/bagbyte/actions/Deploy%20@bagbyte/lib (with a literal |
|
I forget where, but feel like there's been some discussions in the past about how we currently cannot support badge route patterns that have consecutive route params which can both conditionally include a
If that's something that can be fixed holistically upstream either in All of the below scenarios are entirely valid and we need to be able to support them, IMO both with or without the user:
user:
user:
user:
|
|
Right, yeah. I see what you mean: everything just gets gobbled by I think you're right - the only way to allow both to contain a |
|
The only other thing I could think of would be to include a static route part inbetween the two params, something like: and |
|
Is there a reason why it doesn't work like this?
I feel like it should work, but it doesn't. 🤔 It should be decoded to: |
Would this break existing users badges though? |
Yes, but if we were to make that change or move one of the route params to a query param, we'd add a redirector to map from the old route to the new to prevent any actual breakage. |
I’m not sure we could distinguish between an old-style request for If the ID of the workflow can’t be changed to accommodate the badge, an alternative could be a second route that pulls everything from the query params (like |
Yup, was planning to also change part of the static portion of the route to account for this (probably something like |
|
Gotcha. Yea, true. I think I prefer the query param version. It seems more readable to a human: |
|
Yeah I do too. There's a handful of other cases where the branch had to be a query param for similar reasons. Only caveat on the leading portion of the route is that there are different constructs within GHA that could each have their own badges, for example a workflow status badge vs a job status badge, and potentially down the road additional CI related badges like test results (I've heard rumors Github are working on this) |
|
It's weird to me that we have github and workflow in the name, but not actions, which I think is the more identifiable and distinguishing name. I wonder if we should use Maybe |
Blame GitHub marketing 😆 Actions is the buzzy word that everyone sees and uses, but regardless of the branding and marketing, an Action is a small reusable component that is incorporated within a job, and workflows consist of one or more jobs. I already see a wide array of configurations, with some having a single workflow with multiple jobs (1 job for linux build, 1 job for mac, etc.) and others having multiple, single job workflows. The rough analogy would be if CircleCI had originally launched with Orb's and used Orb in all the branding and marketing. For that matter, GH may very well make metadata/statistics available on published actions that action authors might be interested in having a badge for as well https://github.com/marketplace?type=actions Not trying to speculate on potential future badges for the sake of speculation, more just trying to think through the route in the context of very real possible future asks to avoid locking us into a route that seems "wrong" down the road or end up with 5 different redirectors |
|
i just stumbled into this. is there any workaround? i am new to github workflows, but my understanding is they need to live in the .github/workflow/ directory, so we can't even have a workflow without slashes? with travis-ci no longer being available freely for open source, i imagine a lot of projects moving to github actions around now and running into this issue... |
|
@dbu - The name of a workflow and the directory path of the yaml file that contains the definition of a workflow are entirely separate things in this context.
We're obviously not GitHub so questions about the GitHub platform and it's features would be best addressed on their respective forums, but yes, GitHub requires the workflow yaml files to reside within a The workflow name is a metadata field that you as the user define within your respective yaml files, and this can largely contain whatever value you want (including apparently As discussed above in this thread and shown on the Shields.io website for the GitHub Workflow Status badge, this workflow name is one of the badge route parameters:
GitHub Actions has been widely used for quite some time now, and we get a lot of traffic on our Workflow Status Badges (~2,350 such unique badge requests in the last 15 minutes, and 206,000 over the last 24 hours), so I'd push back on the characterization of this as a widespread problem. The issue at hand here is for cases where a user has decided to specify a workflow name that includes a
The easiest workaround is simply: don't use a At some point I'm sure we'll get around to extending the Shields badge offering to support this use case, but like all open source projects the maintainer team has limited bandwidth with a massive backlog, and this one hasn't really been a priority so far. |
|
@calebcartwright thank you very much for this expansive explanation even though you are not github support ❤️ i did not realize that setting a name in the workflow allows me to do what i wanted. i did not have one and assumed the default name from the path is the only name i can have. thank you so much for taking the time to explain this to me. indeed, when one can set the name, then this is a very minor problem. |
We no longer use CircleCI to test/build the `keep-core` code. We need to replace the CircleCI build status badge in the projec'ts README with the similiar badges for GitHub Actions builds. Two badges have been introduced in place of the old one: * Contracts (showing status of the last `Solidity` workflow executed on `master` branch and triggered by the push event), * Go client (showing status of the last `Go` workflow executed on `master` branch and triggered by the push event). The badges are displayed using `shields.io` tool, which was already used for the Discord badge. Also a badge was added in the README of the Token Dashboard: * Token Dashboard / Testnet (showing status of the last `Token Dashboard / Testnet` workflow on `master` branch and triggered by the push event). This time standard GitHub badge was used, as `shields.io` tool currently does not support workflows with slash character in their name (see badges/shields#4559).
We no longer use CircleCI to test/build the `keep-core` code. We need to replace the CircleCI build status badge in the projec'ts README with the similiar badges for GitHub Actions builds. Two badges have been introduced in place of the old one: * Contracts (showing status of the last `Solidity` workflow executed on `master` branch and triggered by the push event), * Go client (showing status of the last `Go` workflow executed on `master` branch and triggered by the push event). The badges are displayed using `shields.io` tool, which was already used for the Discord badge. Also a badge was added in the README of the Token Dashboard: * Token Dashboard / Testnet (showing status of the last `Token Dashboard / Testnet` workflow on `master` branch and triggered by the push event). This time standard GitHub badge was used, as `shields.io` tool currently does not support workflows with slash character in their name (see badges/shields#4559).
We no longer use CircleCI to test/build the `keep-core` code. We need to replace the CircleCI build status badge in the projec'ts README with the similiar badges for GitHub Actions builds. Two badges have been introduced in place of the old one: * Solidity build (showing status of the last `Solidity` workflow executed on `master` branch and triggered by the push event), * Go build (showing status of the last `Go` workflow executed on `master` branch and triggered by the push event). The badges are displayed using `shields.io` tool, which was already used for the Discord badge. Also a badge was added in the README of the Token Dashboard: * Token Dashboard / Testnet (showing status of the last `Token Dashboard / Testnet` workflow on `master` branch and triggered by the push event). This time standard GitHub badge was used, as `shields.io` tool currently does not support workflows with slash character in their name (see badges/shields#4559).
According to https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#name:
That means: ---
# no name
on: # yamllint disable-line rule:truthy
...
jobs:
...will be treated as So, a name including |
We're adding the badges to the README file. We've: - added a chat badge to point to the Threshold Network Discord server - added a docs badge linking to the Threshold Network documentation - added a badge showing the status of the workflow building the dashboard. The displayed status is based on the status of the most recently executed `Token Dashboard / CI` workflow triggered by the push to `main`. Note that unike other badges this badge is created using native GH workflow status badge functionality - that's because `shields.io` doesn't support yet workflows using `/` character in their name (see badges/shields#4559).
|
See #8671 for the details of the fix for this |
Are you experiencing an issue with...
🪲 Description
I'm having an issue using the
/github/workflow/status/:user/:repo/:workflowAPI. My workflow is calledDeploy @myorg/lib, so the final URL looks like:/github/workflow/status/myorg/myrepo/Deploy%20%40myorg%2Flib, but this is interpreted by the service as:It seems the URL is decoded before evaluating the route pattern, causing a general issue that may impact any service path.
Note: This workflow name is supported by GitHub, the official documentation for the badge accepts the encoded workflow name.
The text was updated successfully, but these errors were encountered: