Support GitHub App authentication about git-sync HOT 7 OPEN

In this area, git-sync is not very complex. Something like you describe sounds fine. Ideally we would start with an e2e case, but it's not clear to me if there's an easy way to e2e reproduce the experience locally. Is there a trivial github app that we can use to at least manually run tests? Hard to support something I can't test at all :)

from git-sync.

Yeah, testing this doesn't seem straightforward :(
I'm not sure of being able to use an existing public app for testing.
When creating a new app, GitHub gives you a private key which running applications can use along with the app ID and installation ID (tied to a repo or organization) to authenticate as that particular app installation. So whoever is running the test would probably have to create a dummy app that's installed to the repo being synced and provide those three values to the test, which isn't great.

from git-sync.

Can we automate or at least document clearly how I (an arbitrary person) could create my own "just for testing" app? Or that we could set up thru GH actions to run, but maybe an arbitrary person cant?

from git-sync.

I could create documentation for creating a testing app. Automation might be tricky since there's no GitHub API endpoints or the like for creating apps but it's worth looking into further

from git-sync.

Update from me on this, I've got the change working now and there's a couple things I'm unsure about before opening a PR (should have that done by the weekend)

• Where should documentation for creating a github app for testing go? The docs directory seemed more user-facing
• I've been testing my change by running a git-sync container in a similar way to the current github https e2e test, but with the addition of the new github app args which need to be supplied. Any ideas on how this can be integrated cleanly alongside the existing tests?

Thanks :)

from git-sync.

Doc could go in "docs/dev/testing_github_app_auth.md" or something like that?

Tests: I am not sure I follow the question. I don't have a way to write an e2e test that doesn't always run, but that seems plausibly useful. If you write a PR which treats it like a normal e2e function, I will find a way to let you designate it as "skipped by default" or something

from git-sync.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

from git-sync.