Sbt-github-packages: Alternative de propriété JVM pour les informations d'identification

Heureux d'accepter un PR pour un TokenSource qui fait ça !

Je suis d'accord que ce serait utile, mais je le fais comme une solution rapide/sale si vous en avez besoin.

• Créez un jeton d'accès personnel avec toutes les portées de package dont vous pourriez avoir besoin (lecture, écriture, suppression).
• dans ~/.gitconfig... définissez l'attribut de jeton comme décrit dans le fichier README du référentiel.
• Dans votre fichier build.sbt... githubTokenSource := TokenSource.GitConfig("github.token") || TokenSource.Environment("GITHUB_TOKEN")
• IntelliJ + sbt shell devrait réussir sans se plaindre de la variable d'environnement manquante.

Cette solution de contournement ne fonctionne pas pour moi.

Cette solution de contournement ne fonctionne pas pour moi.

Le jeton d'accès personnel que vous avez utilisé a-t-il défini les étendues des packages ? Le fichier ~/.gitconfig devrait avoir une ligne comme celle-ci.

[github]
    token = <github_token_value>

Oui, et c'est ce que j'ai dans le fichier .gitconfig.

Cette solution de contournement ne fonctionne pas pour moi.

Le jeton d'accès personnel que vous avez utilisé a-t-il défini les étendues des packages ? Le fichier ~/.gitconfig devrait avoir une ligne comme celle-ci.

[github]
  token = <github_token_value>

J'ai essayé le même ~/.gitconfig , cela n'a pas fonctionné en ma faveur non plus.

Pour que la variable d'environnement fonctionne dans IntelliJ, activez sbt shell pour le rechargement du projet.

Outils de construction > sbt > projets sbt

Cela a fonctionné pour moi dans la version Community Edition 2020.3.

Pour que la variable d'environnement fonctionne dans IntelliJ, activez sbt shell pour le rechargement du projet.

Outils de construction > sbt > projets sbt

Cela a fonctionné pour moi dans la version Community Edition 2020.3.

Cela n'a pas fonctionné pour moi. Je l'ai fait configurer via la variable d'environnement. J'ai contourné cela, comme solution de contournement, en utilisant le plugin sbt-dotenv . Après cela, tout a fonctionné sans aucune modification de la configuration IntelliJ ou autre.

Une variante d'une solution de contournement suggérée dans ce problème a fonctionné pour ma configuration IntelliJ.

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

Je partage le fait que notre équipe pensait que nous avions réglé ce problème avec les builds à projet unique et à projets multiples en injectant la valeur githubTokenSource comme paramètre commun dans le bloc de configuration de chaque projet dans le build.sbt. Tout s'est bien passé pour les utilisateurs, les IDE et les espaces de travail GitHub Action qui avaient soit une entrée ~/.gitconfig github.token, soit une variable d'environnement GITHUB_TOKEN.

Jusqu'à ce que l'un de nous décide d'utiliser la tâche runAll du plugin Lagom.

Cela meurt immédiatement pour le problème d'origine.

Le contexte fourchu utilisé par le plugin Lagom pour déployer l'essaim de services manque à la fois de la variable d'environnement et d'un fichier ~/.gitconfig.

Nous recherchons des moyens de définir l'environnement pour cet environnement d'exécution forké.

Cependant, l'hypothèse générale selon laquelle un GITHUB_TOKEN doit être fourni même si les tâches du plug-in GitHub Package ne sont pas appelées s'avère frustrante pour nos utilisateurs et nos robots qui n'ont pas déjà ce jeton facilement disponible.

Les gourous du SBT.

Existe-t-il un moyen approprié "d'injecter" un paramètre (en particulier githubTokenSource ) dans un espace de noms global afin qu'un plugin comme sbt-github-packages voie ce paramètre pour tous les projets définis explicitement, pour tous les projets définis dynamiquement ( comme le plugin de Lagom crée), pour toutes les phases de construction, et pour tous les contextes fourchus ?

Il est onéreux d'avoir à revendiquer explicitement l'emplacement d'un identifiant qui est invariant à travers toutes ces permutations encore et encore, d'avoir à approfondir les détails de la façon dont SBT gère les espaces de noms ou les caches d'état.

Ce n'est peut-être pas la faute de ce plugin en particulier, mais ce plugin est celui qui est blâmé pour avoir dû faire toute cette opération SBT interne pour essayer de couvrir tous les cas.