Aller au contenu principal

Dépannage

Les problèmes courants et leurs solutions. Chaque section renvoie à la page de référence concernée pour plus de contexte.

Authentification et connexion

L’e-mail de réinitialisation du mot de passe n’arrive pas

Vérifiez votre dossier de courrier indésirable. Les e-mails de réinitialisation du mot de passe proviennent de hello@frem.sh. Si votre organisation utilise le SSO, la réinitialisation du mot de passe n’est pas la bonne voie. Utilisez plutôt le bouton Se connecter avec <IdP> de la page de connexion. Les comptes SSO n’ont pas forcément de mot de passe local.

La connexion SSO échoue avec une erreur redirect_uri mismatch

L’IdP a refusé le rappel parce que l’URI de redirection qui y est enregistrée ne correspond pas exactement à celle qu’envoie fremforge. L’URI de redirection est https://frem.sh/user/oauth2/<auth-source-name>/callback, où <auth-source-name> est le nom exact de la source d’authentification tel qu’il apparaît sur sa carte dans Administration de l’organisation → SSO ; copiez ce nom au lieu de le saisir à la main. Une simple barre oblique finale en trop ou en moins provoque cette erreur. Voir Authentification unique OIDC.

SSH : Permission denied (publickey)

Trois causes courantes :

  • La clé n’a pas été ajoutée à votre compte fremforge (Paramètres utilisateur → Clés SSH / GPG → Ajouter une clé).
  • Le fichier de clé utilisé par votre client SSH appartient à un autre compte utilisateur.
  • Le format de la clé n’est pas pris en charge (Ed25519, RSA 3072+ et ECDSA sont pris en charge ; les clés DSA sont refusées).

Testez votre clé : ssh -T -p 443 git@ssh.frem.sh. fremforge expose SSH sur le port 443 via ssh.frem.sh (le port 22 n’est pas ouvert). Une authentification réussie renvoie Hi <username>! You've successfully authenticated.... Voir Prise en main pour la configuration des clés et Se connecter à fremforge pour l’alias Host de ~/.ssh/config qui vous permet de continuer à écrire git@frem.sh dans vos remotes.

PAT expiré / 401 sur les appels d’API

Les PAT expirent au bout de 90 jours, qui est aussi le maximum (ttl_days accepte de 1 à 90). Vérifiez :

  1. Que le jeton figure toujours sous Paramètres utilisateur → Jetons d’accès Git.
  2. Que le jeton a le scope requis. Les appels REST du plan de contrôle utilisent le vocabulaire de scopes de fremforge (orgs:read, findings:read, …) : voir Jetons d’API. Les registres de paquets n’acceptent aucun PAT ; voir Paquets / Registre ci-dessous.
  3. Que la valeur du jeton a été copiée correctement (elle n’est affichée qu’une seule fois, à la création).

En cas de doute, générez un nouveau jeton.

CI / Runners

Job bloqué dans la file d’attente

L’organisation dispose de 2 jobs simultanés garantis par utilisateur (au moins 10, au plus 60), et peut en utiliser jusqu’à 60 lorsque la plateforme a de la capacité disponible. Une organisation en essai en exécute 2 à la fois. Consultez le nombre de jobs en cours sur frem.sh/<org>/_admin/billing. Si tous les créneaux de l’organisation sont occupés, les jobs attendent dans la file jusqu’à ce qu’un créneau se libère. Ils ne sont pas annulés.

Si la file est vide mais que des jobs restent bloqués, l’agent du runner est peut-être hors ligne. Vérifiez l’état des runners dans les paramètres Forgejo de l’organisation, sous Paramètres → Actions → Exécuteurs (frem.sh/org/<org>/settings/actions/runners).

actions/checkout échoue : repository not found

Le FORGEJO_TOKEN intégré a besoin de la permission contents: read. Ajoutez un bloc permissions: au job ou au workflow :

permissions:
  contents: read

Si le dépôt est privé et que le jeton est un PAT plutôt que le jeton intégré, vérifiez que le PAT a le scope repo.

Le secret est défini mais apparaît vide dans le job

Le secret est défini au mauvais niveau. Les secrets suivent cet ordre de priorité : secret d’environnement → secret de dépôt → secret d’organisation. Si votre job déclare environment: production, seuls les secrets définis sur cet environnement (et les secrets de dépôt ou d’organisation qu’il ne masque pas) sont injectés. Vérifiez que le secret est défini au niveau qui correspond à la déclaration environment: du job.

Docker : Cannot connect to the Docker daemon

Les runners fremforge sont des VM éphémères, une par commit (debian 13), avec un démon Docker natif préinstallé. docker build, docker run et docker/build-push-action@v5 fonctionnent tous sans configuration supplémentaire. Si vous voyez cette erreur, vérifiez que le job déclare runs-on: fremforge (pour qu’il s’exécute sur un runner fremforge et non sur un label auto-hébergé sans Docker) :

jobs:
  build-image:
    runs-on: fremforge
    steps:
      - uses: actions/checkout@v4
      - uses: docker/setup-buildx-action@v3
      - uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: registry.example.com/${{ github.repository }}:${{ github.sha }}

Pour une simple copie, un re-étiquetage ou un push d’image entre registres, skopeo est préinstallé. Voir Runners CI pour les labels de runner disponibles et docs.frem.sh/build/actions/runner-image/ pour la liste complète des outils préinstallés.

upload-artifact réessaie sur une erreur 413, puis échoue avec Status Code: 413

Le quota d’artefacts Actions de l’organisation (5 Gio par utilisateur) est plein. Le journal de l’étape affiche plusieurs fois A 413 status code has been received, will attempt to retry the upload, puis Status Code: 413 et Status Message: Request Entity Too Large. Relancer le job ne sert à rien tant que de l’espace n’a pas été libéré. Voir Artefacts et pièces jointes Actions.

Action introuvable : uses: some/action@v1

La plupart des actions du GitHub Marketplace fonctionnent sur fremforge. Les actions qui appellent directement github.com/api/v3 échouent, car elles visent l’API GitHub et non l’API fremforge. Consultez la compatibilité Marketplace pour la matrice de compatibilité action par action.

Git et dépôts

Push refusé : secret détecté

Gitleaks (hook pre-receive) a bloqué le push parce qu’un motif de secret a été détecté dans le commit. Le push n’a pas été accepté. Le secret n’a jamais atteint le dépôt.

Pour résoudre le problème :

  1. Renouvelez immédiatement le secret dans le système qui l’a émis, même si le push a été refusé. Considérez la valeur comme compromise dès l’instant où elle est apparue dans votre arbre de travail.
  2. Retirez le secret de votre arbre de travail et de l’historique des commits avec git filter-repo.
  3. Poussez à nouveau l’historique nettoyé.

Voir Sécurité et chaîne d’approvisionnement pour savoir quels motifs sont détectés.

Push refusé : protection de branche

Une règle de protection de branche bloque le push. Vérifiez les règles sous Dépôt → Paramètres → Branches → <branch name>. Causes courantes : une vérification de statut requise n’est pas passée, le force-push est désactivé, ou le push exige un commit signé.

LFS : batch request failed

Git LFS est disponible dans chaque dépôt ; il n’y a pas d’option par dépôt à activer. Dépôt → Paramètres → LFS liste les fichiers LFS que le dépôt stocke déjà. Si l’erreur persiste, vérifiez le quota de stockage de l’organisation. Le stockage LFS est décompté sur l’enveloppe LFS de 5 Go par utilisateur, distincte de l’enveloppe de 5 Go par utilisateur du registre de paquets.

Webhooks

Le webhook ne se déclenche pas

Consultez les tentatives de livraison récentes sous Dépôt → Paramètres → Webhooks → <webhook> → Livraisons récentes. La cause la plus courante est une URL de charge utile injoignable depuis les IP de sortie T Cloud Public de fremforge. Si les livraisons apparaissent en échec, le corps de la réponse contient généralement le statut HTTP renvoyé par votre endpoint. Voir Webhooks pour les plages d’IP de sortie.

Le webhook se déclenche mais la charge utile n’est pas la bonne

Vérifiez à quels types d’événements le webhook est abonné. Un push sur un tag envoie un événement push, et non un événement create. Vérifiez la configuration Events du webhook. Voir Webhooks pour le vocabulaire complet des événements.

SSO / SCIM

Utilisateur SCIM provisionné mais incapable de se connecter

La vérification du domaine est requise avant que les utilisateurs provisionnés par SCIM puissent s’authentifier. Vérifiez le domaine e-mail sous Administration de l’organisation → SSO → Domaines vérifiés. Le domaine de l’adresse e-mail de l’utilisateur doit y figurer.

Paquets / Registre

Les registres n’acceptent que deux identifiants : le jeton automatique d’un job Forgejo Actions, et le jeton de courte durée que la CLI fremforge fournit à vos outils. Les jetons d’API (ffp_…) sont refusés. Voir Registre de paquets → Authentification.

Job Actions : 403 this job's token can only write packages linked to its own repository

Le job a tenté de publier un paquet qui appartient à un autre dépôt de l’organisation, ou un paquet lié à aucun dépôt. Le jeton d’un job n’écrit que les paquets liés à son propre dépôt, ainsi que les nouveaux paquets qu’il crée. Publiez depuis le dépôt auquel le paquet appartient, ou liez un paquet non lié à ce dépôt sur la page Paramètres du paquet.

Job Actions : 401 ou 403 lors d’une publication depuis une pull request

Les exécutions pour les pull requests issues de forks n’obtiennent qu’un accès en lecture. Publiez depuis un workflow de push ou de tag dans le dépôt lui-même.

docker pull ou push : unauthorized

Sur votre machine, vérifiez la connexion de la CLI et le helper :

fremforge auth status
printf 'frem.sh\n' | docker-credential-fremforge get    # prints JSON when the helper works
  • not logged in → lancez fremforge auth login.
  • docker-credential-fremforge: command not found → le répertoire du helper (~/.local/bin) n’est pas dans votre PATH, ou fremforge auth configure docker n’a jamais été lancé.
  • fremforge manages frem.sh registry credentials après docker login frem.sh → c’est normal ; le helper refuse les mots de passe enregistrés. Utilisez fremforge auth login.

npm, Maven ou Gradle : 401 au bout d’un moment

Ces outils lisent une copie du jeton dans leur fichier de configuration, et cette copie expire au bout d’une heure au plus. Lancez n’importe quelle commande fremforge, ou fremforge auth refresh, pour la réécrire. Ajoutez "preinstall": "fremforge auth refresh --quiet" à package.json, ou une étape de pré-build dans votre IDE, pour que les builds démarrent toujours avec un jeton frais.

pip ou uv : 401 ou demande de mot de passe

pip et uv n’interrogent keyring que si on le leur demande : pip config set global.keyring-provider subprocess, ou UV_KEYRING_PROVIDER=subprocess pour uv. L’URL de l’index doit contenir votre nom d’utilisateur (https://<username>@frem.sh/api/packages/<org>/pypi/simple/). Vérifiez que le keyring de ~/.local/bin arrive en premier dans votre PATH : command -v keyring.

Disponibilité des slugs et des noms d’organisation

Les slugs d’organisation doivent comporter de 3 à 30 caractères, en minuscules, uniquement des lettres, chiffres et tirets, sans tiret au début ni à la fin.

Si un slug apparaît comme indisponible lors de l’inscription, c’est qu’il est déjà enregistré par une autre organisation ou qu’il figure sur la liste des noms réservés. La liste réservée couvre les noms de rôle courants (admin, api, billing, support, status, security, abuse, root, system, fremforge et similaires), pour éviter l’hameçonnage et les collisions avec des chemins du service.

Les noms proches de marques déposées (par exemple des slugs qui ressemblent fortement à des noms de marques connues) passent par une file de revue souple au lieu d’être bloqués immédiatement. Si votre inscription est dans cette file, vous recevez un e-mail de support@frem.sh sous un jour ouvré. Dans la plupart des cas, les entreprises légitimes qui utilisent leur propre nom de marque sont approuvées sans difficulté.

Si le slug que vous souhaitez est pris par une organisation inactive ou qui le squatte, contactez support@frem.sh. Indiquez le slug souhaité et le domaine de votre organisation ou toute autre preuve de propriété. Les transferts de slug sont traités au cas par cas.

Pour changer le slug de votre organisation après sa création : Administration de l’organisation → Paramètres → Renommer l’organisation. Toutes les URL de dépôt, URL de clonage et appels d’API qui utilisent l’ancien slug continuent d’être redirigés pendant 90 jours. Passé ce délai, l’ancien slug redevient disponible à l’enregistrement.

Voir aussi