Prise en main

Ce guide vous mène de l’inscription à un pipeline CI opérationnel. Il suppose que vous avez un terminal ouvert et git installé.

Vous achetez ou administrez fremforge plutôt que de coder dessus ? Votre première heure avec fremforge décrit l’inscription, le SSO, le paiement et la préparation du compte de secours (break-glass) en termes simples, avec un schéma du parcours. Lisez-la d’abord si vous êtes propriétaire de l’organisation, puis revenez ici quand vous êtes prêt à pousser du code.

Étape 1 : inscrivez-vous

Rendez-vous sur www.frem.sh et cliquez sur Sign up dans la barre de navigation (ou allez directement sur frem.sh/_app/signup). Indiquez votre e-mail professionnel, le slug de l’organisation (par exemple acme, de 3 à 30 caractères) et un nom d’affichage.
Un e-mail de vérification envoyé par noreply@frem.sh arrive dans votre boîte de réception. Cliquez sur le lien Confirmer l’inscription. Il est valable 24 heures.
Sur la page de confirmation, choisissez votre mot de passe et cliquez sur Créer l’organisation.

Votre organisation est immédiatement disponible à l’adresse https://frem.sh/<your-org>.

Étape 2 : configurez Git Credential Manager (HTTPS + MFA)

fremforge recommande de se connecter en HTTPS avec Git Credential Manager (GCM) : une connexion interactive via le fournisseur d’identité (IdP) de votre organisation, avec une MFA à chaque renouvellement du jeton. Les nouvelles organisations ont SSH désactivé par défaut ; HTTPS+GCM est la voie à suivre.

Installez GCM :

# macOS
brew install --cask git-credential-manager

# Linux
curl -sL https://aka.ms/gcm/linux-install-source.sh | sh && git-credential-manager configure

# Windows: bundled with Git for Windows 2.28+

Configurez GCM pour fremforge (une fois par poste de travail) :

git config --global credential.https://frem.sh.gitProvider gitea
git config --global credential.https://frem.sh.oauthClientId e90ee53c-94e2-48ac-9358-a874fb9e0662

Cet identifiant client est celui de l’application git-credential-manager intégrée à Forgejo : aucune configuration par organisation n’est nécessaire.

Pour la configuration complète, avec le déroulement de la MFA, les solutions de repli (jeton d’accès personnel pour la CI, SSH pour les organisations qui l’ont réactivé) et les remarques propres à chaque système, consultez le guide de connexion sécurisée.

Étape 3 : créez votre premier dépôt

Depuis l’interface : allez sur frem.sh/<your-org> → + New repository. Saisissez le nom du dépôt, choisissez sa visibilité (public ou privé), initialisez-le éventuellement avec un README, puis cliquez sur Create repository.

Pousser un dépôt local existant (HTTPS, recommandé) :

git remote add origin https://frem.sh/<your-org>/<your-repo>.git
git push -u origin main
# First push: GCM opens a browser tab → IdP sign-in + MFA → token cached.
# Subsequent pushes within the token's lifetime are silent.

Si l’administrateur de votre organisation a réactivé SSH et que vous le préférez, l’équivalent SSH fonctionne aussi : voir Connexion.

Si le dépôt n’existe pas encore, fremforge le crée automatiquement au premier push, à condition que vous ayez l’autorisation Create repositories (accordée par défaut à tous les propriétaires de l’organisation).

Étape 4 : invitez les membres de votre équipe

L’appartenance aux équipes se gère dans l’interface native des équipes d’organisation de Forgejo. fremforge ne duplique pas l’éditeur de rôles.

Allez sur https://frem.sh/org/<your-org>/teams et choisissez l’équipe dans laquelle inviter la personne (ou New team pour en créer une).
Saisissez l’adresse e-mail de la personne invitée (ou son nom d’utilisateur fremforge si elle a déjà un compte).
Choisissez un rôle :

Rôle	Accès
Propriétaire	Administration complète de l’organisation : facturation, SSO, politique de sécurité, gestion des membres, tous les dépôts
Membre	Accès aux dépôts uniquement, restreint davantage par les autorisations de chaque dépôt

La personne invitée reçoit un e-mail contenant un lien d’acceptation. Tant qu’elle n’a pas accepté, elle apparaît comme En attente dans la liste des membres et ne compte pas comme utilisateur facturé.

Étape 5 : votre premier workflow CI

Créez un fichier .forgejo/workflows/ci.yaml dans votre dépôt. Forgejo Actions utilise le même schéma YAML que GitHub Actions :

on: [push, pull_request]

jobs:
  test:
    runs-on: fremforge
    steps:
      - uses: actions/checkout@v4
      - run: echo "Hello from fremforge CI"

Faites un commit et poussez. Le workflow se déclenche immédiatement. Suivez l’exécution à l’adresse :

frem.sh/<your-org>/<your-repo>/actions

Cliquez sur l’exécution pour voir les journaux de chaque étape. Le runner hébergé fremforge est provisionné sur T Cloud Public ECS (une VM éphémère par commit) dans la région eu-de. Votre code ne quitte pas l’UE.

Un exemple de workflow réel

Remplacez le echo par vos véritables commandes de build et de test :

on: [push, pull_request]

jobs:
  test:
    runs-on: fremforge
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: "20"

      - run: npm ci
      - run: npm test

Consultez Runners CI pour les labels de runner disponibles, les outils inclus et les limites de concurrence.

Étape 6 : ajoutez un secret

Les secrets sont chiffrés au repos avec T Cloud Public DEW KMS et injectés dans les jobs des workflows sous forme de variables d’environnement. Leurs valeurs sont masquées dans les journaux des jobs.

Secret d’organisation (disponible pour tous les dépôts de l’organisation) :

Allez dans Administration de l’organisation → Secrets (frem.sh/<your-org>/_admin/secrets) et ajoutez un secret.
Saisissez un nom (majuscules et tirets bas uniquement, par exemple DEPLOY_API_KEY) et la valeur.
Enregistrez.

Secret de dépôt (disponible pour un seul dépôt) :

Allez dans Dépôt → Paramètres → Secrets → Ajouter un secret.
Saisissez le nom et la valeur. Enregistrez.

Utilisez-le dans votre workflow :

steps:
  - name: Deploy
    env:
      API_KEY: ${{ secrets.DEPLOY_API_KEY }}
    run: ./deploy.sh

Pour les identifiants de fournisseurs cloud (AWS, T Cloud Public, GCP, Azure), préférez la fédération de jetons OIDC aux secrets de longue durée. Il n’y a alors aucun secret à stocker ni à renouveler.

Consultez Secrets pour la référence complète, y compris les secrets d’environnement et l’héritage des secrets.

Étape 7 : connectez votre IdP (facultatif mais recommandé)

Si votre équipe utilise Okta, Entra ID, Google Workspace ou Authentik, configurez le SSO pour que les membres se connectent avec leur identité d’entreprise. Le SSO est facultatif, mais vivement recommandé pour les équipes de plus de deux personnes.

SSO OIDC (recommandé) :

Allez dans Administration de l’organisation → SSO → Sources d’authentification → Ajouter une source SSO.
Choisissez OIDC.
Saisissez l’URL de découverte, l’identifiant client et le secret client de votre IdP.
Enregistrez et testez.

Une fois le SSO configuré, les membres accèdent à la page de connexion propre à l’organisation, frem.sh/user/login?redirect_to=/<your-org>, et s’authentifient via votre IdP ; plus simple encore, la connexion par découverte à l’adresse frem.sh/_app/login les dirige vers votre organisation d’après le domaine de leur adresse e-mail. Consultez Comment fonctionne la connexion pour le modèle complet.

IdP	Guide
Okta	SSO OIDC
Microsoft Entra ID	SSO OIDC
Google Workspace	SSO OIDC
ADFS	SSO OIDC

Une fois le SSO fonctionnel, mettez en place le provisionnement SCIM pour automatiser le cycle de vie des utilisateurs. Les nouvelles recrues obtiennent leur accès automatiquement, et les personnes qui partent sont déprovisionnées dès que leur compte IdP est désactivé.

Étape 8 : migrez depuis GitHub, GitLab ou Azure DevOps

Les outils de migration sont disponibles dès aujourd’hui : consultez Migration pour les guides GitHub, GitLab et Azure DevOps, l’importateur natif et le vérificateur préalable à la migration.

Pour adapter vos workflows existants et consulter une référence de compatibilité, voir les guides de migration.

Et ensuite ?

Une fois votre premier pipeline au vert :

Renforcez la chaîne d’approvisionnement : activez les dérogations à l’analyse des secrets, le SAST, l’analyse des dépendances et les commits signés. Voir Sécurité et chaîne d’approvisionnement.
Configurez la protection des branches : exigez des relectures de pull request et une CI réussie avant la fusion. À régler dans Dépôt → Paramètres → Branches → <branch>.
Mettez en place des environnements : utilisez des environnements de déploiement pour soumettre les déploiements en production à une approbation manuelle. À configurer dans Administration de l’organisation → Environnements (https://frem.sh/<org>/_admin/environments).
Découvrez le registre de paquets : poussez des images Docker, des paquets npm ou des artefacts Maven. Consultez la documentation du registre de paquets pour le point de terminaison de push et l’authentification.

Références croisées

Guides de migration : import pas à pas depuis GitHub, GitLab et Azure DevOps
Runners CI : labels de runner, outils inclus, runners auto-hébergés (BYO)
SSO OIDC : configurer la connexion avec Okta, Entra ou Google Workspace
Secrets : secrets d’organisation, de dépôt et d’environnement
Administration de l’organisation : la référence complète de l’interface d’administration