Comments (33)
@LexABzH @Schneegans @jvfresco @dtcMLOps
Hello everybody,
I also need to use it in a private owned organization I found how to do it.
The issue of using the current structure is that shield.io cannot access the organization gist. The firewall won't accept the request. Shield.io cannot access the orga but your orga can make a request to shield.io. So instead of saving a JSON based object, you save the SVG file in a gist. The README then display an image from gist.
Before:
- Action: Compute the result
- Action: Create a gist with a JSON object
- README: Get request to Shield.io with gist url
- Shield.io: Cannot access the orga gist => ERROR
After:
- Action: Compute the result
- Action: Get request to shield.io to create the badge
- Action: Save the SVG badge in gist
- README: Get request to gist
Customer usage:
The following code publish a JSON based object compatible with Shield.io
- name: Create Awesome Badge
uses: schneegans/[email protected]
with:
auth: ${{ secrets.GIST_SECRET }}
gistID: <gist-ID>
filename: test.json
label: Hello
message: World
color: orange
The following code publish an SVG image
- name: Create Awesome Badge
uses: schneegans/[email protected]
with:
auth: ${{ secrets.GIST_SECRET }}
host: github-enterprise-hostname/api/v3/gists
gistID: <gist-ID>
filename: test.svg
label: Hello
message: World
color: orange
In other word, if the filename extension is .svg
, the action makes a request to Shield.io to create the badge and the result is saved to gist. Regarding the API request from your action to gist enterprise, you just have to make the host parameter as a variable.
from dynamic-badges-action.
Hi. Unfortunately, I couldn't find a good solution and I haven't come back to this problem since.
An idea might be to create a "fake" user for your organization :
- Create a new gist with this user
- Create a token with the gist scope
- Add the token as a Secret of your repository
Hope it helps.
I don't think this works. Since my user is already in the organization and despite I have setup the token and the gist ID I keep getting the error:
Run schneegans/[email protected]
Failed to get gist, response status code: 401, status message: Unauthorized
/home/runner/work/_actions/schneegans/dynamic-badges-action/v1.6.0/index.js:209
if (oldGist.body.files[filename]) {
^
TypeError: Cannot read properties of undefined (reading 'version.json')
at /home/runner/work/_actions/schneegans/dynamic-badges-action/v1.6.0/index.js:209:31
at processTicksAndRejections (node:internal/process/task_queues:96:5)
I noticed that the gits_ID parameter is not taking into account the user account to which the ID belongs.
from dynamic-badges-action.
Yes. It will be a breaking change, but we will create a new major version (v2.0.0) for indicating this change. As I said before, I think that the number of people using this feature is very low (if any at all).
I also just realized that despite being not documented, logoWidth
seems to work. Also, it seems to be possible to pass base64 encoded images to the logo
parameter:
https://img.shields.io/badge/any_text-you_like-blue?logoWidth=200&logo=data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4NCjwhLS0gR2VuZXJhdG9yOiBB%0D%0AZG9iZSBJbGx1c3RyYXRvciAxNS4xLjAsIFNWRyBFeHBvcnQgUGx1Zy1JbiAuIFNWRyBWZXJzaW9u%0D%0AOiA2LjAwIEJ1aWxkIDApICAtLT4NCjwhRE9DVFlQRSBzdmcgUFVCTElDICItLy9XM0MvL0RURCBT%0D%0AVkcgMS4xLy9FTiIgImh0dHA6Ly93d3cudzMub3JnL0dyYXBoaWNzL1NWRy8xLjEvRFREL3N2ZzEx%0D%0ALmR0ZCI+DQo8c3ZnIHZlcnNpb249IjEuMSIgaWQ9ImNpcmNsZV9waWVjZXMiIHhtbG5zPSJodHRw%0D%0AOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5%0D%0AOTkveGxpbmsiIHg9IjBweCINCgkgeT0iMHB4IiB3aWR0aD0iNTExLjg3NXB4IiBoZWlnaHQ9IjUx%0D%0AMS44MjRweCIgdmlld0JveD0iMCAwIDUxMS44NzUgNTExLjgyNCIgZW5hYmxlLWJhY2tncm91bmQ9%0D%0AIm5ldyAwIDAgNTExLjg3NSA1MTEuODI0Ig0KCSB4bWw6c3BhY2U9InByZXNlcnZlIj4NCjxjaXJj%0D%0AbGUgaWQ9ImNpcmNsZSIgZmlsbD0iI0ZGRkZGRiIgY3g9IjI1Ni4yNTIiIGN5PSIyNTUuOTg2IiBy%0D%0APSIyNTMuMDkzIi8+DQo8cGF0aCBpZD0iYmx1ZS1waWVjZSIgZmlsbD0iIzNFNUJBOSIgZD0iTTQ1%0D%0ANS4zOTgsNDEyLjE5N2MzMy43OTItNDMuMDIxLDUzLjk0Ni05Ny4yNjIsNTMuOTQ2LTE1Ni4yMTEN%0D%0ACgljMC0xMzkuNzc5LTExMy4zMTMtMjUzLjA5My0yNTMuMDkzLTI1My4wOTNjLTMwLjQwNiwwLTU5%0D%0ALjU1OCw1LjM2Ny04Ni41NjYsMTUuMTk3QzI3Mi40MzUsNzEuOTg5LDQwOC4zNDksMjQ3LjgzOSw0%0D%0ANTUuMzk4LDQxMi4xOTd6DQoJIi8+DQo8cGF0aCBpZD0ibGVmdC1yZWQtcGllY2UiIGZpbGw9IiM5%0D%0ARjFEMjAiIGQ9Ik0yMjAuMDAzLDE2NC4zMzdjLTM5LjQ4MS00Mi41MzMtODMuNjk1LTc2LjMxMi0x%0D%0AMzAuNTIzLTk4LjcxNQ0KCUMzNi41NzMsMTEyLjAxMSwzLjE1OSwxODAuMDkyLDMuMTU5LDI1NS45%0D%0AODZjMCw2My44MTQsMjMuNjI2LDEyMi4xMDQsNjIuNTk3LDE2Ni42MjMNCglDMTAwLjExMSwzMTku%0D%0AMzkyLDE2NC42OTcsMjE5LjkwNywyMjAuMDAzLDE2NC4zMzd6Ii8+DQo8cGF0aCBpZD0iYm90dG9t%0D%0ALXJlZC1waWVjZSIgZmlsbD0iIzlGMUQyMCIgZD0iTTI2Ni42MzgsMjIxLjcyN2MtNTQuNzkyLDU5%0D%0ALjA1MS0xMDkuMzkyLDE2Mi40MjItMTI5LjE1MiwyNTcuNzk0DQoJYzM1LjQxOSwxOC44NTcsNzUu%0D%0AODQsMjkuNTU5LDExOC43NjYsMjkuNTU5YzQ0LjEzMiwwLDg1LjYxOC0xMS4zMDYsMTIxLjc0LTMx%0D%0ALjE2M0MzNTcuMTcxLDM4MS43MTIsMzE3Ljg2OCwyOTMuNjA0LDI2Ni42MzgsMjIxLjcyNw0KCXoi%0D%0ALz4NCjwvc3ZnPg0K
So after all, the change wouldn't be too breaking 😄. Maybe we could leave the logoWidth
parameter there, indicating that it is not officially supported...
from dynamic-badges-action.
I should have read this thread before posting #24
In my fork I simply drop an SVG image if the filename ends with .svg
. And then only use parameters supported to generate it, meaning it is completely backwards compatible.
from dynamic-badges-action.
I actually did do a fair amount of refactoring in my fork, if you want I can send a PR
from dynamic-badges-action.
I just exposed a host parameter in the latest master branch of the action. Can anybody with a GitHub enterprise instance test whether this works? Maybe even together with the new SVG option? If it works, I would tag a new release!
I'll test it next week.
Not sure I can call the action with last commit
uses: schneegans/dynamic-badges-action@<last_commit>
EDIT: I can uses: https://docs.github.com/en/actions/creating-actions/about-custom-actions#using-branches-for-release-management
from dynamic-badges-action.
As it is in master
, you can also do uses: schneegans/dynamic-badges-action@master
at this point.
from dynamic-badges-action.
@Schneegans My company must white list the action before I can use it. Long process.
from dynamic-badges-action.
That's an interesting question to which I do not have a good answer. A user once tried to use the project's wiki repository instead of a gist (#8), but this feels pretty hacky.
Maybe it could be a solution to create a custom user account just for this purpose?
Edit: TLDR; The discussion in this issue digressed a bit. After all, I think there's currently no better solution for organizations than to use the gist of a user account. Maybe even a user created specifically for this purpose.
Organization gists are a frequently requested feature so it's not unlikely that we will get this one day!
from dynamic-badges-action.
Thanks for your reply.
I was thinking the same, but it's far from perfect.
I will try to explore other approaches, and I let you know if I find something interesting :)
from dynamic-badges-action.
Hi @LexABzH, I need this as well for my private repository on my organization. Are there any updates regarding this feature?
from dynamic-badges-action.
Hi. Unfortunately, I couldn't find a good solution and I haven't come back to this problem since.
An idea might be to create a "fake" user for your organization :
- Create a new gist with this user
- Create a token with the gist scope
- Add the token as a Secret of your repository
Hope it helps.
from dynamic-badges-action.
Hello,
I have the same problem with enterprise accounts. This is what I found:
On enterprise accounts gists are created on https://gist.github-enterprise-hostname
Github standard api gists endpoint is api.github.com/gists
In Github enterprise the api endpoint is github-enterprise-hostname/api/v3/gists
Allowing a host as input parameter and change conditionally the url where the request to get the gist is performed could be a solution.
In my case even with that would be useless because the link to the raw gist is unnaccessible outside enterprise network.
from dynamic-badges-action.
@LucBerge That is indeed a great idea! Have you tried this already so that you could create a corresponding merge request? If not, I will try this. I think in order to stay backwards-compatible, we could check the filename and if it ends with ".svg" we could use the proposed approach and else use the old behavior.
from dynamic-badges-action.
Have you tried this already so that you could create a corresponding merge request?
Not really. The only thing I have tried is to display an svg file hosted on gist from a README.
I think in order to stay backwards-compatible, we could check the filename and if it ends with ".svg" we could use the proposed approach and else use the old behavior.
Yes
Keep us in touch!
from dynamic-badges-action.
@Schneegans Do you work on it?
from dynamic-badges-action.
Not yet. And given on how many other open-source projects I am currently working in my spare time I doubt that I will have the time to implement this in the coming days. It'll be rather a couple of weeks. Hence I would happily accept a pull request 😉
from dynamic-badges-action.
Since I need it at work, I'll do a PR on my work time.
from dynamic-badges-action.
@Schneegans I have questions:
- I know it is working as this but is it an error?
[filename]
is an array key of a dict. The doc says it should just be a string. - Why don't you update the gist, whether the content is different or not? Don't you care to update something if it does not change? Removing the
forceUpdate
parameter would simplify the code and remove this branch. - An object oriented code would be easier to maintain. Do you agree?
- In the README, for each optional parameter, we should add what happens if not defined.
- Do you have tests to verify the code works as expected? Would be nice to have some to make sure I don't break something while working on it. The tests must cover all the possibilities.
I'll work step by step:
- Add tests => PR
- Create a function for
getGist
(likeupdateGist
) - Add host parameter
- Add a function for
getBadge
and change behavior based on the filename extension => PR - Migrate to object oriented code => PR
from dynamic-badges-action.
Thank you for looking into this! Your overall plan looks very good. The code dates back to a time where I did not know much about Node / JavaScript / async programming / etc 😄 When looking at it today, I think that there is much room for improvement!
Regarding your points:
- Looks weird. I guess just check if it works if replaced by a simple string. I cannot remember any reason for the array.
- Gists are version-controlled and updating them creates a new revision even if the content did not change. If a workflow runs frequently, this can create a huge number of revisions quickly. The corresponding issue was #16.
- Definitely, yes!
- Yeah. When looking at the current docs of shields.io it seems that many of the parameters are actually not exposed for the badges which we could retrieve with a GET request (like
logoPosition
orlogoSvg
). This would make the documentation and the code even more complicated... I am wondering if we should drop support for the JSON-endpoint variant altogether? I do not see a disadvantage in pushing the SVG to the gist. Well, it's a bit larger in terms of file-size but this shouldn't mater much.... This would break backwards-compatibility but this would also be fine if we released a new major version. What do you think? - No. Well, there are some badges in the README which are generated by this workflow but I would not consider this a thorough test 😅
What do you think?
Thanks again!
from dynamic-badges-action.
- Ok
- Ok, keeping the
forceUpdate
parameter - Ok
- I agree, I don't see why you should keep the JSON endpoint, it is exactly the same as SVG.
- Ok
from dynamic-badges-action.
@Schneegans Static badges and Endpoint badges do have differencies.
Endpoint badges have the following fields static badges don't have
isError
logoSvg
logoWidth
logoPosition
Endpoint badges field nameLogo
= Static badges field logo
Do we still keep the json endpoint? At least for backward compatibility?
from dynamic-badges-action.
Well, I would say that supporting custom logos is not worth the added code complexity. I doubt that many people are actually using this. And it makes not only the code but also the documentation much more complex.
from dynamic-badges-action.
Are you saying we drop the json endpoint once for all ?
It will break backward compatibility for beforehand fields.
from dynamic-badges-action.
Sorry for the late reply, I am very busy these days 😅
Anyways, it's an even more awesome idea to use this library instead of the GET request to shields.io. @LucBerge how far is your refactoring? Do you want to incorporate the idea by @runarberg or how shall we proceed? I guess we could also simply use the approach by @runarberg, but maybe we would miss an opportunity for cleaning up the code 😃
from dynamic-badges-action.
Are you saying we drop the json endpoint once for all ?
It will break backward compatibility for beforehand fields.Yes. It will be a breaking change [...]
...
@LucBerge how far is your refactoring?
Not so far
Do you want to incorporate the idea by @runarberg or how shall we proceed?
Would love it.
maybe we would miss an opportunity for cleaning up the code 😃
We can do it later
from dynamic-badges-action.
Although most of my refactoring changes were for selfish reasons, e.g. I know the newer fetch
API better then the older http
API, so I swapped them.
from dynamic-badges-action.
I opened #25 It may contain more refactoring than hoped. For example node has been bumped to version 20, there is a lot of whitespace changes caused by prettier, etc. But I cleaned up my fork in a way that it can at least be merged if desired.
from dynamic-badges-action.
I just exposed a host
parameter in the latest master
branch of the action. Can anybody with a GitHub enterprise instance test whether this works? Maybe even together with the new SVG option? If it works, I would tag a new release!
I would also close this issue even if this is not really a solution to the original issue reported here by @LexABzH. However, I think there's no better solution for organizations than to use the gist of a user account. Maybe even a user created specifically for this purpose.
Organization gists are a frequently requested feature so maybe we will get this one day!
from dynamic-badges-action.
@LucBerge any update on this one?
from dynamic-badges-action.
@LucBerge I now such companies 😅 Do you have a rough estimation how long this will take? Else I would simply release the new version and fix any issues with the host parameter thereafter. Everything else seems to work decently.
from dynamic-badges-action.
Do you have a rough estimation how long this will take?
Absolutely no idea
from dynamic-badges-action.
Alright. I just published v1.7.0
. If you encounter any problems, please open a new issue. I guess we have digressed this issue here enough 😆
I added a TLDR; to the first comment above to prominently show the results of the discussion. Thank you all for your contributions!
from dynamic-badges-action.
Related Issues (15)
- Can this be used for code coverage? HOT 12
- Fetching gist through github API fetches gist history HOT 4
- When using selft-hosted runner which set proxy, it will throw erros HOT 2
- [BUG] Unauthorized HOT 8
- [FEATURE] Update gist only if changed HOT 1
- Gist by different user HOT 4
- upgrade for node 16 HOT 2
- Workflow triggered by Dependabot fails HOT 4
- How to use it with secret gists? HOT 4
- Write SVG files to gist
- "Bad credentials" bug HOT 3
- Action sometimes not outputting any results HOT 5
- Shield.io display domain is blocked HOT 3
- Storing json in wiki ? HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dynamic-badges-action.