Contributor Setup: From Login to First Pull Request

Contributing to the STACKIT Cloud Framework means writing content, not running an application. The whole docs app ships as a prebuilt dev container image, and your clone of the content repository is mounted into it. This guide takes you from having nothing installed to an open pull request.

---

What You Need Before You Start

Three things, and only the first two touch your machine:

1. A STACKIT account. It is the identity you log in with, and it onboards you automatically.

2. A container runtime and an editor. Docker Desktop or podman, plus Visual Studio Code with the Dev Containers extension.

3. An access token from the Git instance, which you create in a later step and use as your password for both cloning and pulling the image.

You never need access to the application repository. Everything the site needs to build, Node, the docs app, the diagram toolchain and the test browser, is already inside the image.

---

Creating a STACKIT Account

If you do not have a STACKIT login yet, create one first at accounts.stackit.cloud , then come back to the next step.

Use a personal work address for it, in the form firstname.lastname@company.com. The Git instance builds your username from the part before the @. You cannot change that username later.

Addresses that make a bad username

Shared addresses like info@ or admin@ become a username like info. Such a name says nothing about who you are. If your company only gives you team addresses, pick one that names the team and the company, like cloud-team.acme@acme.com.

If the login works but the Git instance rejects you afterwards, your account is probably not in the STACKIT organization that hosts the instance. Contact Framework Core and we will sort it out.

---

Sign In Once to Get Onboarded

Log in once via the STACKIT IDP at scf-content.git.onstackit.cloud . That single login does two things:

• It creates your STACKIT Git user. Your username is the part of your mail address before the @, so with a personal address it reads firstname.lastname.
• It queues you for the contributors team. A pipeline adds every IDP-authenticated user to the team every 15 minutes, so onboarding is self-service and nobody has to invite you.

Check which account you are signed in with

The STACKIT IDP has no account picker. It signs you in with the STACKIT account that is already active in your browser. The Git user is created from that account right away. If you also use a technical or shared STACKIT account, open the instance in a private browser window and sign in there with your personal account.

Signed in with the wrong account? Do not work with it. Write to Framework Core at framework@stackit.cloud before you try to delete it. The pipeline adds accounts back to the team every 15 minutes, so we take it out of that first.

Nothing after 15 minutes?

Log out and back in once, and if you still cannot see the content repository, ping Framework Core. That case is rare and usually means your account sits outside the expected organization.

---

How Your Name Appears

Contributing here is public. The site credits people by name in two places: the history timeline on every asset and trail, and the Maintainers block on the pages you are listed for. That is the point of the credit, and you decide which name it is.

Three separate sources feed it:

Swipe sideways to see the whole table

Where	Comes from	You change it in
History timeline	the author of your commits, shown as who and when	git config user.name in your clone
Maintainers credit	the Full name of your STACKIT Git profile, mirrored daily once you have declared it	your Git profile
The profile panel that opens on hover	your biography, website, address and contribution record	your Git profile, once you have declared them

Your commit messages never appear on the site. The timeline names the author and the date and nothing else, because a commit message is written for the repository rather than for a reader.

Nothing is shown until you release it yourself, your name included. You do that once, in a declaration: open an issue in the content repository with the Contributor declaration template and tick the details you want shown. Framework Core or your framework owner records the result in settings/contributor-members.json, which is the only place the site reads it from. You cannot edit that file yourself. That is deliberate.

Until your declaration is recorded there, the daily pipeline publishes nothing about you, so a maintainer credit without one reads as an anonymous contributor with no hover panel at all. Your commits still carry your name inside the repository, as they do in any repository, but the website does not repeat it. A detail you did not release is not merely hidden: it is never fetched from your profile and never written down anywhere. Writing role: true next to your name in an asset does nothing either. Only the person a field describes can release it. A content file is not that person.

Two details are worth knowing before you tick the boxes. Your address only appears if you also made it public in your Git profile, because the API hands out a no-reply placeholder otherwise, and that is not a contact. Your contribution record is matched through the address on your commits, so it counts the commits you author under your own account. To change or withdraw any of it later, comment on your own declaration issue.

A pseudonym, a short form or just your initials are all fine in either place. Emptying the Full name works too: after the next mirroring run the maintainers credit shows “Anonymous contributor”, it never falls back to your username. If you would rather not have your private address in the commit history, set a no-reply identity in the same breath:

git config user.name  "Your display name"
git config user.email "your-username@noreply.scf-content.git.onstackit.cloud"

Changing it later works forwards, not backwards

A new Full name is picked up by the next mirroring run, and a new user.name applies to your next commits. Neither rewrites the names already recorded in past commits. If you need one of those removed from the public display, ask Framework Core, which is a display change, not a rewrite of the history.

Your address is never shown unless you ask for it: it appears only when a page lists it explicitly, or when you both made it public in your Git profile and the page opts in.

---

Prepare Your Machine

Install these two, in any order:

• Docker Desktop or podman. Either works. With podman, do the two settings in the next section.
• Visual Studio Code with the Dev Containers extension. The extension is what turns the prebuilt image into your working environment.

Nothing else gets installed. No Node, no pnpm, no build tools on your host.

---

Podman: Two Settings to Get Right

With Docker Desktop you skip this section.

Point VS Code at podman. Open the settings (Ctrl + ,, on the Mac ⌘ + ,), search for dev containers path, change Dev > Containers: Docker Path from docker to podman, then restart VS Code. Without it the extension looks for a docker binary that is not there and the container never starts.

Give the machine memory and disk. The build and the test suite run inside the podman machine and the default one is too small for them. Set it up with room from the start:

podman machine init --memory 8192 --cpus 4 --disk-size 60
podman machine start

If your machine already exists, adjust it afterwards:

podman machine stop
podman machine set --memory 8192 --cpus 4
podman machine start

---

Windows: Clone Into WSL2

On Windows, do all of this inside WSL2 and clone into the Linux file system, for example ~/projects/scf-content.

A clone under /mnt/c/... looks like it works: the container starts, the site builds, the page loads. But file change events do not cross the Windows to Linux boundary reliably, so hot reload never fires and your edits appear to have no effect until you restart the server.

---

Create an Access Token

On the Git instance, open Settings, then Applications, then Generate new token. Grant exactly these permissions:

Swipe sideways to see the whole table

Permission	Level	Needed for
repository	Read and Write	cloning the content repo, pushing branches
package	Read	pulling the prebuilt dev container image

Above the permission list sits a dropdown called Repository and Organization Access. Leave it on All (public, private and limited). On “Public only” the token cannot see the private content repository at all, and cloning as well as the registry login fail with a 403 even though every permission above is set correctly.

The token is shown exactly once

Copy it into your password manager immediately. If you lose it, the token cannot be displayed again, you can only revoke it and generate a new one. You will need it twice: as the password when cloning, and as the password for the registry login.

---

Log In to the Registry

Log in with your Git username and the token as the password, then pull the image:

docker login scf-content.git.onstackit.cloud
docker image pull scf-content.git.onstackit.cloud/scf-core/scf-system:latest

podman is a drop-in replacement here: podman login and podman image pull take exactly the same arguments.

Run this on your own computer

The login belongs in a terminal on your machine, not in the terminal inside the dev container. There is no docker or podman in there, and the command will simply report that it does not exist.

Pulling the image up front is optional, VS Code pulls it for you on the first container start. Doing it manually just makes the first start faster and shows you early whether the login worked.

The image is multi-arch: the same pull gives Intel and Windows machines the amd64 variant and Apple Silicon Macs the native arm64 variant, automatically. When you pull a newer image later, follow it with Rebuild Container in VS Code, because a plain reopen keeps the cached old container running. Superseded image versions pile up as untagged leftovers, so run docker image prune (or podman image prune) on your machine now and then to clear them out.

---

Fork, Clone and Reopen in the Container

The content repository grants read access only, so your fork is the place you push to. Everybody works this way, Framework Core included. Open scf-core/scf-content and press Fork, then clone your copy with your Git username and the token as credentials:

git clone https://scf-content.git.onstackit.cloud/<your-username>/scf-content.git
cd scf-content
git remote add upstream https://scf-content.git.onstackit.cloud/scf-core/scf-content.git

The upstream remote is how you pull later changes from the shared repository into your fork.

One thing to know before you branch: your fork copies every branch this repository has on the day you fork it, half-finished ones included. Start new work from upstream/main and from nothing else, which is also why a fork that has fallen behind cannot get in your way. When you do want it up to date, your fork’s page shows a green banner with a button that does it in one click. On our instance that button still carries its untranslated label repo.sync_fork.button, so go by the green banner rather than by the wording. A branch you have kept for weeks wants main merged into it before you open the next pull request.

Where the password prompt appears in VS Code

When you run this from the terminal inside VS Code, the username and password prompt does not appear in the terminal itself. VS Code intercepts it and shows a small input box at the top of the window, where the command palette opens. It is easy to miss — if a clone or push seems to hang, look up there.

Open the folder in VS Code. It detects the dev container configuration and offers Reopen in Container, which is also available from the command palette. The first start pulls the image and takes a few minutes; every later start is quick.

Your clone is mounted into the prebuilt app as its content, which is why you can preview the complete site without ever touching the application repository.

---

Where Your Logins Are Stored

You enter the token twice because two different tools remember it in two different places, and knowing where saves you a confusing afternoon later:

• Git asks once per Git host and then stores the login in your operating system’s credential store: the Keychain on macOS, the Credential Manager on Windows. Every later git fetch and git push against that host replays it silently.
• Docker and podman keep their own store (for example ~/.config/containers/auth.json). The two do not share anything, which is why the registry login is its own step.

There is no git logout. When you rotate a token, or signed in with the wrong account, git keeps replaying the stored login and never asks again — the fix is to clear the stored entry so the next fetch or push prompts fresh (in the VS Code terminal that prompt appears as an input box at the top of the window, not in the terminal):

printf "protocol=https\nhost=scf-content.git.onstackit.cloud\n\n" | git credential reject

On Windows you can alternatively open the Credential Manager and remove the git:https://scf-content.git.onstackit.cloud entry there. To see which account macOS currently has stored for the host:

security find-internet-password -s scf-content.git.onstackit.cloud | grep acct

Your commit identity is a separate thing entirely: git config user.name and user.email decide how your commits are labelled, the stored login only decides who you authenticate as when pushing.

---

Run hike and Open the Site

In the container terminal, run:

hike

The same thing is available as the VS Code task 🥾 Hike, Start Dev Docs. The site is forwarded to http://localhost:4321 with hot reload, so every save shows up in the browser within a second.

Type help to see the full tool belt:

Swipe sideways to see the whole table

Command	What it does
hike	dev server with hot reload on http://localhost:4321
summit	full production build
panorama	serve the built site
patrol	build plus the complete UI test suite, the same gate as your PR
scout	how to update the dev container image

---

Three Traps Worth Knowing

Almost every failed setup comes down to one of these:

1. The access token is shown exactly once. Save it before you close the dialog.
2. The registry login belongs on your own machine. Inside the container there is no container runtime to log in with.
3. On Windows, a clone under /mnt/c silently breaks hot reload. Work inside WSL2 and clone into the Linux file system.
4. A token created with “Public only” access fails with 403, even though every permission looks right. Set the access dropdown to All when generating it.
5. After rotating a token, git still replays the old one from your credential store and never prompts again. Clear the stored entry as shown in “Where Your Logins Are Stored”.

---

Author With the Studios

Branch off upstream/main rather than off your own main, then write:

git fetch upstream
git switch -c content/short-description upstream/main

Your fork’s main falls behind the moment somebody else contributes, and a branch started on top of it drags that gap into your pull request. Fetching first costs a second and takes the question away entirely. When you do want the fork itself tidy, CONTRIBUTING has the commands for that.

For new pages, use the studios instead of copying frontmatter by hand:

• SCF Studio, at http://localhost:4321/studio, writes a contributor profile, an asset, a trail or a framework page. It also loads an existing file and changes only what you edit, so everything you leave alone stays exactly as it was.
• Diagram Studio, at http://localhost:4321/diagrambuilder, draws a diagram in the SCF design and saves it next to your page.

Both run on your local dev server, and the SCF Studio runs on the dev site as well. It writes frontmatter that already satisfies the pipeline’s rules: a real description in the rewarded 120 to 160 character window, a category from the allowed list and at most 10 tags.

For the authoring rules behind the generated files, see the asset integration guide and the trail setup guide.

---

Run patrol Before the Pull Request

patrol

patrol reproduces what the pipeline runs: the production build, the UI test suite, and a walkthrough of every asset, trail and profile your branch touched. It takes a few minutes and saves you a review round, because a green patrol almost always means a green pull request.

---

Open Your Pull Request

Push your branch to your fork and open a pull request against main of the shared repository. The description arrives prefilled with three confirmations you have to tick: that you hold the rights to what you contribute, that it carries nobody’s personal data and nothing confidential, and that every link points at an official source. A separate check reads them and stays red until all three are ticked, so keep the prefilled text in place rather than replacing it with your own.

On the files your pull request touches, the pipeline checks:

• frontmatter, description present and a real summary (120 to 160 characters is rewarded, not enforced), valid category, at most 10 tags
• reference links, a link standing on its own line must be a <LinkCard> or <LinkChip>, and their on-site targets must exist — see the asset integration guide
• internal links, including anchors, relative links and locale mixing
• wording, no obscene or derogatory language
• file size, nothing above 1 MB
• secrets, accidentally committed credentials are rejected
• markup safety, no scripts, inline styles, event handlers or remote-loading resources in content pages
• trail integrity, every trail step reference must still resolve

It then builds the full site, runs the UI tests and posts a report on your pull request. A temporary, password-protected preview site is optional: tick the preview box in the description and your pages go up within fifteen minutes of the checks turning green, follow every push, then disappear when the pull request closes. Nothing depends on it, patrol shows you the same result locally.

A Framework Core reviewer approves and merges. You can also tick the automatic-merge box, then the merge happens on its own within ten minutes of an approval landing on a green pull request. Either way your content goes live with the next site deployment.

---

Where to Go Next

Cloud Framework Contributor Profile Registration Guide Register your organization with a contributor profile so your assets and trails resolve to you, or use the shared open-contributors entry if no company stands behind the work. Open page