Sbt-github-packages: JVM-Eigenschaftsalternative für Anmeldeinformationen

Ich nehme gerne einen PR für TokenSource an, der dies tut!

Ich stimme zu, dass dies hilfreich wäre, aber ich mache dies als schnelle/schmutzige Lösung, wenn Sie es brauchen.

• Erstellen Sie ein persönliches Zugriffstoken mit allen erforderlichen Paketumfängen (Lesen, Schreiben, Löschen).
• in ~/.gitconfig... setzen Sie das Token-Attribut wie in der Repo-README-Datei beschrieben.
• In Ihrer build.sbt-Datei... githubTokenSource := TokenSource.GitConfig("github.token") || TokenSource.Environment("GITHUB_TOKEN")
• IntelliJ + sbt Shell sollte erfolgreich sein, ohne sich über die fehlende Umgebungsvariable zu beschweren.

Dieser Workaround funktioniert bei mir nicht.

Dieser Workaround funktioniert bei mir nicht.

Sind für das von Ihnen verwendete persönliche Zugriffstoken die Paketbereiche festgelegt? Die Datei ~/.gitconfig sollte eine Zeile wie diese haben.

[github]
    token = <github_token_value>

Ja, und das habe ich in der .gitconfig-Datei.

Dieser Workaround funktioniert bei mir nicht.

Sind für das von Ihnen verwendete persönliche Zugriffstoken die Paketbereiche festgelegt? Die Datei ~/.gitconfig sollte eine Zeile wie diese haben.

[github]
  token = <github_token_value>

Ich habe das ähnliche ~/.gitconfig ausprobiert, es hat auch nicht zu meinen Gunsten geklappt.

Damit die Umgebungsvariable in IntelliJ funktioniert, aktivieren Sie die sbt-Shell für das Neuladen des Projekts.

Build Tools > sbt > sbt-Projekte

Dies hat bei mir in der Community Edition Version 2020.3 funktioniert.

Damit die Umgebungsvariable in IntelliJ funktioniert, aktivieren Sie die sbt-Shell für das Neuladen des Projekts.

Build Tools > sbt > sbt-Projekte

Dies hat bei mir in der Community Edition Version 2020.3 funktioniert.

Dies hat bei mir nicht funktioniert. Ich hatte es über die Umgebungsvariable konfiguriert. Ich habe dies als Problemumgehung mit dem Plugin sbt-dotenv umgangen . Danach funktionierte alles ohne Änderungen in der IntelliJ-Konfiguration oder auf andere Weise.

Eine in diesem Problem vorgeschlagene Variante einer Problemumgehung funktionierte für mein IntelliJ-Setup.

githubTokenSource := TokenSource.Or(
  TokenSource.Environment("GITHUB_TOKEN"), // Injected during a github workflow for publishing
  TokenSource.GitConfig("github.token") // local token set in ~/.gitconfig
)

Ich teile mit, dass unser Team dachte, wir hätten dieses Problem mit Einzelprojekt- und Multiprojekt-Builds gelöst, indem der githubTokenSource-Wert als gemeinsame Einstellung in den Konfigurationsblock jedes Projekts in der build.sbt eingefügt wurde. Alles lief gut für Benutzer, IDEs und GitHub Action-Arbeitsbereiche, die entweder einen ~/.gitconfig github.token-Eintrag oder eine GITHUB_TOKEN-Umgebungsvariable hatten.

Bis sich einer von uns entschied, die Aufgabe runAll des Lagom-Plugins zu verwenden.

Dies stirbt sofort für das ursprüngliche Problem.

Dem Fork-Kontext, der vom Lagom-Plug-in zum Bereitstellen des Service-Schwarms verwendet wird, fehlen sowohl die Umgebungsvariable als auch eine ~/.gitconfig-Datei.

Wir suchen nach Möglichkeiten, die Umgebung für diese Fork-Ausführungsumgebung festzulegen.

Die allgemeine Annahme, dass ein GITHUB_TOKEN bereitgestellt werden muss, auch wenn die Plugin-Aufgaben des GitHub-Pakets nicht aufgerufen werden, erweist sich jedoch als frustrierend für unsere Benutzer und Bots, die dieses Token nicht bereits verfügbar haben.

SBT-Gurus.

Gibt es eine geeignete Möglichkeit, eine Einstellung (insbesondere githubTokenSource ) in einen globalen Namespace zu "injizieren", sodass ein Plugin wie sbt-github-packages diese Einstellung für alle explizit definierten Projekte sieht, für alle dynamisch definierten Projekte ( wie das Plugin von Lagom erstellt), für alle Build-Phasen und für alle Fork-Kontexte?

Es ist lästig, den Speicherort eines Berechtigungsnachweises, der über all diese Permutationen hinweg unveränderlich ist, immer wieder explizit beanspruchen zu müssen, und sich in die Details einarbeiten zu müssen, wie SBT Namespaces oder State-Caches verwaltet.

Vielleicht ist dies nicht die Schuld dieses speziellen Plugins, aber dieses Plugin wird dafür verantwortlich gemacht, all diese internen SBT-Operationen durchführen zu müssen, um zu versuchen, alle Fälle abzudecken.