How to use it with organizations accounts ?

Question

How to use it with organizations accounts ?

LexABzH opened this issue 2 years ago · 33 comments

Hello,

I just came accross this project and I was wondering how you would use it with an organization account ?

As I understand, you can't create gists with organizations accounts, so do you need to create a gist with a user account ?
Does that mean that the token will also have access to all the other user's gists ?
What if this user leaves the organization ?
Any advice would be appreciated :)

Answer 1 · 2022-09-15T18:07:50.000Z

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!

Answer 2 · 2022-09-16T07:24:54.000Z

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 :)

Answer 3 · 2023-02-06T21:20:20.000Z

Hi @LexABzH, I need this as well for my private repository on my organization. Are there any updates regarding this feature?

Answer 4 · 2023-02-06T21:41:24.000Z

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.

Answer 5 · 2023-02-15T13:22:43.000Z

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/dynamic-badges-action@v1.6.0
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.

Answer 6 · 2023-05-25T13:04:34.000Z

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.

Answer 7 · 2023-09-04T13:54:10.000Z

@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/dynamic-badges-action@v1.6.0
  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/dynamic-badges-action@v1.6.0
  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.

Answer 8 · 2023-09-04T17:12:23.000Z

@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.

Answer 9 · 2023-09-04T19:19:37.000Z

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!

Answer 10 · 2023-09-05T15:57:15.000Z

@Schneegans Do you work on it?

Answer 11 · 2023-09-05T17:58:31.000Z

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 😉

Answer 12 · 2023-09-05T19:54:41.000Z

Since I need it at work, I'll do a PR on my work time.

Answer 13 · 2023-09-06T08:19:20.000Z

@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 (like updateGist)
Add host parameter
Add a function for getBadge and change behavior based on the filename extension => PR
Migrate to object oriented code => PR

Answer 14 · 2023-09-06T08:46:37.000Z

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 or logoSvg). 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!

Answer 15 · 2023-09-06T09:10:15.000Z

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

Answer 16 · 2023-09-18T11:50:02.000Z

@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?

Answer 17 · 2023-09-18T18:13:03.000Z

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.

Answer 18 · 2023-09-19T11:09:04.000Z

Are you saying we drop the json endpoint once for all ?
It will break backward compatibility for beforehand fields.

Answer 19 · 2023-09-19T14:25:54.000Z

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...

Answer 20 · 2023-09-27T19:42:41.000Z

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.

Answer 21 · 2023-10-05T11:54:23.000Z

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 😃

Answer 22 · 2023-10-05T12:13:32.000Z

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

Answer 23 · 2023-10-05T13:41:47.000Z

I actually did do a fair amount of refactoring in my fork, if you want I can send a PR

Answer 24 · 2023-10-05T13:42:51.000Z

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.

Answer 25 · 2023-10-05T15:34:25.000Z

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.

Answer 26 · 2023-10-07T18:33:00.000Z

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!

Answer 27 · 2023-10-08T09:11:59.000Z

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

Answer 28 · 2023-10-09T06:26:17.000Z

As it is in master, you can also do uses: schneegans/dynamic-badges-action@master at this point.

Answer 29 · 2023-10-14T20:05:31.000Z

@LucBerge any update on this one?

Answer 30 · 2023-10-15T12:53:40.000Z

@Schneegans My company must white list the action before I can use it. Long process.

Answer 31 · 2023-10-18T17:30:26.000Z

@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.

Answer 32 · 2023-10-18T20:12:13.000Z

Do you have a rough estimation how long this will take?

Absolutely no idea

Answer 33 · 2023-10-19T06:51:15.000Z

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!