Fancy github action output

[james-callahan]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

By using github workflow commands you can get richer feedback from github actions. The commands are simply a special format you write to stdout.

e.g. by turning a detected secret

{"SourceMetadata":{"Data":{"Git":{"commit":"fbc14303ffbf8fb1c2c1914e8dda7d0121633aca","file":"keys","email":"counter \[email protected]\u003e","repository":"https://github.com/trufflesecurity/test_keys","timestamp":"2022-06-16 10:17:40 -0700 PDT","line":4}}},"SourceID":0,"SourceType":16,"SourceName":"trufflehog - git","DetectorType":2,"DetectorName":"AWS","DecoderName":"PLAIN","Verified":true,"Raw":"AKIAYVP4CIPPERUVIFXG","Redacted":"AKIAYVP4CIPPERUVIFXG","ExtraData":{"account":"595918472158","arn":"arn:aws:iam::595918472158:user/canarytokens.com@@mirux23ppyky6hx3l6vclmhnj","user_id":"AIDAYVP4CIPPJ5M54LRCY"},"StructuredData":null}

into

::error file=keys,line=4::AWS secret leaked!

then github will show them in the pull request diff

Problem to be Addressed

Reading details of what was leaked isn't easy/obvious for pull request authors/security staff

Description of the Preferred Solution

Add a new output format --github-workflow (possibly automatically selected if the GITHUB_WORKFLOW env var is set) that outputs workflow commands.

Additional Context

As an alternative solution, you could instead upload SARIF files so that they appear as comments from the github code scanning bot. https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions This action has a good example of SARIF upload. This alternative appears to be https://github.com/trufflesecurity/trufflehog/issues/578

References

• https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions

[kaiceyd]

Hi @matthew-carroll, thanks for pulling this draft together!

We've discussed the benefits of using super_editor internally and have struggled to justify a nontrivial refactor at this moment in time.

That said, we may be missing some perspective and would like to ask you what benefits, specifically for the news industry, does this package offer when it comes to displaying text to readers. Can you shed some light on how super_editor can improve a reader's experience over the current implementation (flutter_html) + vanilla Flutter?

Thanks!

[matthew-carroll]

Hi @kaiceyd can you please elaborate on what you mean by "non-trivial refactor"? The introduction of Super Editor took less than a day, the code is very well quarantined from the rest of the app, which minimizes cascading issues, and we have Flutter Bounty Hunters who can take over any such workload to complete the integration. It seems simple and low risk to me.

As to your question about benefits, can you please check the PR description and let me know why the currently listed benefits wouldn't be relevant for news organizations?

[kaiceyd]

Hey @matthew-carroll, I understand the benefits for the package itself, but wanted to make sure we weren’t missing industry-specific use cases for news readers beyond what vanilla Flutter already provides.

Given that this project is meant to be a template, we’ve been collectively cautious when selecting packages to include in this codebase. By default, we’ve only included packages that are necessary to meet the requirements of publishers. Of the packages we used, we relied upon “Flutter Favorites” or packages that have excellent test coverage, popularity, and pub points that have been vetted by the Google product team.

We were able to add text selection support using the SelectionArea widget and it seems to work quite well. We were also able to add hyperlink support to the HtmlBlock by implementing the onLinkTap callback and using package:url_launcher to launch the url in an external browser.

The caveat is that hyperlink support (and other inline styling such as bold, italics, underline, etc.) for non-HTML blocks will be more difficult to adopt because we don’t have nested support for inline styles. This is where super_editor could provide additional value over the current solution in our opinion. If a large portion of publishers want to support nested inline styling without the HtmlBlock, then super_editor would be beneficial; however, given our current feedback from customer interviews and implementations, we suspect most publishers with inline styles will likely prefer to use the HtmlBlock since their content will likely already be HTML.

It’s possible this PR can be revisited after we obtain real market data from the industry after GA launch. If we receive feedback that inline style support for non-HTML blocks is needed, we can revisit the potential to support super_editor here.

[justinmc]

+1 to everything that @kaiceyd said, but @matthew-carroll I wanted to jump in and say that we should all probably keep an eye on this repo, super_editor, and the framework itself to make sure we're not diverging in terms of how we all go about representing documents etc. Currently with a quick glance at the code in this repo I'm not worried and it doesn't seem too opinionated or entrenched about that kind of stuff, but it might be relevant for future work.

In the framework as you know we don't have much/any support for multiple "paragraphs" or large documents either. Nor do we have any specific plans for it. If we do start moving in that direction though, I hope it can align with super_editor and news_toolkit and be useful all around.

[matthew-carroll]

@justinmc don't forget about attributed_text and super_text_layout as well. Those are the somewhat hidden workhorses in super_editor. super_text_layout is mostly useful from an editor perspective, but attributed_text is a great tool for defining any text with styles and metadata. Way easier to use than TextSpans.

[justinmc]

Thanks, I wasn't very aware of those, will check them out.

[zoeyfan]

Based on the previous discussion, we do not plan to merge this request in the near future. Hence I am closing this PR now. But we will be more than happy to revisit when we hear customer feedback. Thank you.