Upcoming Features for Devicon

[Thomas-Boi]

Hi all,

I have plans for the next few weeks for some features that I want to do for Devicon. I want to:

• Upgrade the repo's GitHub page so it's in the master branch
• Create an action that would post the snapshot to Imgur and add it to the GitHub comment/PR

About Imgur:

They have an API that supports anonymous image uploading that would be deleted after 6 months. I'm thinking of using this option since it requires less work to register for. However, I am willing to make a Devicon account for Imgur that would save the screenshots forever on Imgur. Let me know what you guys think.

[amacado]

Upgrade the repo's GitHub page so it's in the master branch

Here is the issue regarding this topic: #165, nice that you are working on it! :)

Create an action that would post the snapshot to Imgur and add it to the GitHub comment/PR

Cool idea. You can use info@devicon.dev (see also CODE_OF_CONDUCT.md#enforcement) for registering an account of imgur. If you send me your e-mail adress (private message) I can add you to the group of e-mail recipients for this mail if you like.

[Thomas-Boi]

Nice, here's the Imgur API page if you are interested.

Also, I just want to confirm, would you like the public/anonymous upload or the account upload? The reason I ask is because Imgur API wants users to get an auth token for account upload.

Here's the policy for public/anonymous upload:

Here's the policy for account upload:

So for account upload, we will have to reapply for the auth token every month. We will also have permanent access to files uploaded this way.

For public upload, the image is saved for 6 months before it's auto deleted off the Imgur server. However, we don't have to refresh our auth token.

Both requires a client id so sign up is the same for both. They both have 50 uploads/hour limit as well.

Which one do you think we should pick? I'm leaning towards anonymous upload just because we don't have to maintain it as much. However, using it means that our images will disappear after 6 months. For me, this is not too bad since this is the same thing with GitHub Actions artifacts and we never recheck results from 6 months ago. Let me know what you think.

[amacado]

Yep, I'm following your opinion! :)

[Thomas-Boi]

This message is to provide documentation of what happened with this planned feature.

Summary: GitHub's secrets policy prevents us from using the action. Alternatives have not been found. We might not get a functionality like this for the foreseeable future.

So I did managed to create an action that can upload images to imgur. However, this action requires a IMGUR secret token. The only way we can pass secrets in GitHub is through GitHub secrets, which unfortunately doesn't get pass when the event is triggered by a forked repo (see here. Thus, we can't use this action until we can figure out a way to pass the IMGUR token securely to the action.

I was also looking into uploading images using the GitHub website. In fact, there's an NPM package that allows you to do this. However, to use it would require passing our credential into the script, which also runs into the problem above. We can also hard-code our credentials but obviously, this is a horrible choice.

Making our own Selenium script would still run into the issue. In order to upload using the GitHub website, we would need to be logged in using our credentials. This would then run into the problems as seen above.

Thus, we won't have this functionality for awhile, at least until we find an API that allows image upload with no credential.

[amacado]

Thanks for updating on this topic. Just in addition for any future reader: The mentioned imgur upload action can be found here: https://github.com/devicons/public-upload-to-imgur

[Thomas-Boi]

I think I found a way to make the image commenting works.

There's an Action event called workflow_run, which is triggered whenever a workflow is completed. I'm thinking that we can chain the Peek Icons action with a workflow_run action together to make use of the public-upload-to-imgur Action.

Here's what I think the flow looks like:
-Peek Icons would do the same job as it's doing and upload its artifact when done.
-workflow_run Action (I'll call it Post Peek Screenshot from now on) would gets triggered when Peek Icons is done.
-Post Peek Screenshot download the artifacts of Peek Icons using the GitHub REST API, unzip it, upload it to Imgur, then post a comment using the URL.

Since the workflow_run is a local event, GitHub should pass the secrets to this workflow with no issue.

Now, there are some potential hurdle to this:
-The workflow_run event is poorly documented. From my search online, there are attributes that aren't in the docs. I did some of my own investigation and found out about the artifact_url attribute.

This seems to refer to the artifact_url of the trigger workflow, since the event object itself has the following ids:

A log inside of the trigger event tell us what's the trigger id is:

So while this is not in any documentation, it's safe to say that this refers to the trigger's artifacts.

-The workflow_run event needs to be in master for it to work

This is a minor hurdle but it will make testing a bit difficult. I plan to test it using my forked repo first before we actually put it in production.

-We'll need to sign up for a GitHub personal access token

The API only allows like 5 or so requests without auth, so we'll need this token. During the workflow, we can pass it down using secrets (which should be ok since the event is not a pull_request event)

What do you guys think? I think this should work and save us the hassle of downloading the artifacts whenever we review a PR.

[amacado]

From the documentation:

This event occurs when a workflow run is requested or completed, and allows you to execute a workflow based on the finished result of another workflow. For example, if your pull_request workflow generates build artifacts, you can create a new workflow that uses workflow_run to analyze the results and add a comment to the original pull request.

This sounds exactly what we want!

The workflow started by the workflow_run event is able to access the secrets and write tokens used by the original workflow.

Ah, I think here is the problem, or not? If I understand this sentence right, even the workflow_run event is using the secrets by the triggering workflow. Therefore I fear we will run into the same problem. Have you tried that?

We'll need to sign up for a GitHub personal access token

I don't like this. What scopes are required? Maybe we can create a "fake" account which only job is to provide those credentials? Anyway: Not very nice for a public repo..

[amacado]

Mh, maybe it works.. In the blog entry which introduces the workflow_run event:

The new workflow_run event enables you to trigger a new workflow when one or more workflows are requested or completed. Runs triggered by the workflow_run event always use the default branch for the repository, and have access to a read/write token as well as secrets.

This COULD mean having access to the secrets from the main repository.. We need to try this to find out..

[Thomas-Boi]

Good news: we don't have to create an API token. There's already an action that we can use instead: https://github.com/marketplace/actions/download-workflow-artifact

As for the workflow_run having access to secrets, I'm going to test it out and see what happens.

[Thomas-Boi]

@amacado So I'm on the trail to find a way to bypass the issue of commenting on forked repo's PRs. Here area few promising leads:

For Uploading Images to Imgur
-I'm planning to create a workflow_run event workflow. Since this event belongs in the original repo, it has access to all the secrets:

For commenting on the PR
-Since GitHub limits the GITHUB_TOKEN to read only, it means that we can't use it to comment on PR from fork repos. There are two ways to circumvent this:

1. Creating a workflow_run event workflow for all workflow that requires commenting on PR. This will run after a specific workflow and comment on the pr from that. Essentially, the flow will be:

• Steps:

  • Original workflow runs and saves the pr number as an artifact
  • The workflow_run event gets trigger and run a script that will download the pr number artifact from said workflow. An action that does this is here
  • Use this action, which has the ability to comment on a specific PR, to comment on said PR.

• Pros:

  • Simple
  • I have tested and got a semi-working version. The link shows that it's possible to comment on a pr using JungWinter's comment action.

• Cons:

  • Still have to figure out a way to pass data from the PR workflow.
    • I'm planning to use the artifacts so do this. Just write the PR number in a file then save it as an artifact. The PR number is also not vital info so it should be fine.

2. Creating a personal access token (PAT) and create comments using GitHub's API that runs on workflow_dispatch or schedule (more details here.

• Steps:

  • The script would check for a PR workflow that was ran.
  • It will then find the PR number associated with said workflow, either through the API or an artifact
  • Upload the comments to said PR using the API

• Pros:

  • Professional
  • If using schedule, we don't have to worry about running things manually.

• Cons:

  • workflow_dispatch requires some manual work
  • Has to figure out how to use the GitHub REST API (from what I've seen, is under documented)

Personally, I'm going to work on option 1 since I got half the battle done. I just have to figure out how to save the pr number into a file.

[amacado]

Hello @Thomas-Boi, I appreciate all the effort you are putting in here. I did some research myself regarding commenting on forked pull requests and the workflow_run event and the results are very disappointing. I get the feeling that our intended behaviour is just not supported by GitHub (and there are valid security concerns for it). We can surely hack a solution which can work for us but will it be maintenable? I don't want to put you down and if you are able to get it running I'm pleased. I was just thinking about maybe a solution based on https://www.travis-ci.com/, https://circleci.com/ or some similar service would be easier to maintain? Most of those services even offering free accounts for open source projects. We don't have to do it this way, just wanted to throw in some new ideas.

[Thomas-Boi]

So I got an answer using workflow_run as you can see in #481. I think this should be fine and we don't have to migrate to other CI/CD tools.