github action to see problems in CI/CD, PRs

[samuelstroschein]

Question

Should we build a GitHub action like in the example PR #2065?

📹 LOOM

Proposal

Have a GitHub action that creates awareness when a PR needs updated translations. See this PR as an example #2065

Pros

• awareness of problems in PRs
• can directly jump to fink IN THE SAME PR to fix those problems
• awareness of other solutions in the ecosystem

Cons

• another mini app that needs to be build and maintained

[samuelstroschein]

Comment your repo link if you would use this github action.

The more people comment, the more likely we will build this

[samuelstroschein]

https://github.com/opral/monorepo

we would use it ofc :D

[NilsJacobsen]

Wow. Could be a breakthrough in terms of i18n maintenance convenience. Why should I check, fork, open vs-code, change, commit, push instead of just follow the fink link and change it. Seams super easy 👍

[NiklasBuchfink]

I support this as it is helpful for users and provides a use case where Fink shines. You could even set the correct filters for Fink to get right to the point where it can be fixed. It will increase the need for changeable lint rules, as e.g. the identical pattern will always trigger a warning in the CI.

[samuelstroschein]

Summary of a call with cal.com:

• would use the github action when "code related" lint rules plugin API where is a message used in source code for "unused message", "hardcoded text", etc. lint rules #2126 are available
• wouldn't use github actions now because translation process is not embedded into dev process (btw inlang thesis is to change this)

[NilsJacobsen]

Small addition:

It's just because I heard it several times. For growth, the GitHub actions can boost usage after it is merged. But it will not replace making PRs or making it easier to get something merged. I do not have experience opening PRs with actions, so merging it could be more challenging. I still like the initiative because when merged, it can multiply the usage 👍

[NilsJacobsen]

Additional thoughts:

Why are Github Actions a great opportunity?

• Growth: We can get in the Github Marketplace
• Growth: We can show the lint/fink working more easily in a PR (Maybe easier to merge)
• Usage: Through the GH action we can boost usage with each PR made in the project a user gets informed about new changes/reports

Challenges

• Actions that can be released in the marketplace are not designed to be in a monorepo. When we want to have it in our monorepo some complex synchronization needs to be done. https://docs.github.com/en/actions/creating-actions/publishing-actions-in-github-marketplace?learn=create_actions&learnProduct=actions#about-publishing-actions (we can learn from lychee for example thez have a cli lib and use the gh API to access the logic from a separate lychee-action repo)
• Is it possible to run the action in our own PRs?

Dump question

• Can we not just add the badge in a PR and let the badge handle the calculation (as MVP)? This way, we only have to maintain one lint report visual. We could also only show it when resource files are touched. This way you only get it when it is relevant?

[samuelstroschein]

Can we not just add the badge in a PR and let the badge handle the calculation (as MVP)? This way, we only have to maintain one lint report visual. We could also only show it when resource files are touched. This way you only get it when it is relevant?

I vote against it.

The MVP of the github action should include a diff between main and the opened PR's branch to only show lint reports that changed. Otherwise, the github action will be ignored or removed because every PR now includes a message that might be unrelated to the PR

[felixhaeberle]

Can we not just add the badge in a PR and let the badge handle the calculation (as MVP)? This way, we only have to maintain one lint report visual. We could also only show it when resource files are touched. This way you only get it when it is relevant?

I'm against this approach.

1. The badge is not really stable, we constantly have issues there (render.com, memory, downtime)
2. Image generation at this scale can get really costly
3. Linkability of various information is lost because of 1 image -> 1 link, should be X links
4. Image caching makes it hard to update information

[NilsJacobsen]

Well. I would have loved to see this MVP with the badge, because it's a MVP nothing for scale. That is not stable is a bad reason for building another app (if we can not even maintain the other one).

Aggree on the diffing. On my list in comes at the end because it is the last thing that needs to be achieved.

Soooo, at first my friends let's try to make the monorepo setup.

[felixhaeberle]

That is not stable is a bad reason for building another app

True, but this is not a stable ground to build anything upon.
The other reasons: 2, 3, 4 are each also alone show-stopping for the badge approach.

[samuelstroschein]

Aggree on the diffing. On my list in comes at the end because it is the last thing that needs to be achieved.

clarify: do we agree that the diffing should be included in the MVP?

[samuelstroschein]

Proposal for MVP

• use the SDK directly to circumvent parsing of CLI output and an extra dependency. project.query.messageLintReports.* is all it needs
• diff from main branch to increase importance of message by reducing noise github action to see problems in CI/CD, PRs #2090 (reply in thread)
• must be addable via workflow.yaml file for PR distribution

[NilsJacobsen]

Update:

• I built a prototype action, that can be used in a other repo and accesses the changes of the PR via the github API and shows that in a PR.
• Saw that there is a Localization category in the marketplace but no entries -> Opportunity

Next steps:

• Try to use the SDK to get the reports
• Try to have the logic in the monorepo

[felixhaeberle]

really cool! lets tsee how far we can get

[samuelstroschein]

@NilsJacobsen can the gh action be added via a PR? (in a workflow.yaml file)

[NilsJacobsen]

It created the action in a PR and opened a PR it worked. 👍 But for the action to create comments it needs rights for it.

This needs to be the top one. Default is the bottom one.

[samuelstroschein]

released with https://inlang.com/m/3gk8n4n4/app-inlang-ninjaI18nAction