Getting started with TTI Code

TTI Code · code.tti.tamu.edu · TTI's self-hosted Git forge — repositories, packages, and CI on TTI infrastructure.

1 · Sign in & your profile

Click Sign in and use TAMU single sign-on — there is no separate TTI Code password. Your account is created automatically on first sign-in.

Overnight, a directory sync fills in your profile from the TTI directory: your display name, photo, and department. That's not just cosmetic — it's what makes people findable (see Adding people).

2 · Repositories

Create a repo with the + button in the navbar, or migrate one in from GitHub/GitLab — the importer brings code, issues, labels, and releases. Visibility levels:

Org repos under tti/ typically use branch protection: changes land via pull request with a passing status check, not direct pushes to main.

3 · Clone & push

Your SSO password will not work for git push. Use one of:

SSH (recommended)

Add your public key under avatar → Settings → SSH / GPG Keys, then note the non-standard port:

git clone ssh://git@code.tti.tamu.edu:2227/tti/example-repo.git

HTTPS with a token

Mint a token under avatar → Settings → Applications → Generate new token and use it as the password:

git clone https://code.tti.tamu.edu/tti/example-repo.git
# username: your login · password: the token

4 · Adding people to a repo

Repo → Settings → Collaborators. Search by real name or NetID — because profiles are directory-synced, typing Rivera finds every Rivera with the department shown next to each, so you can pick the right one. Choose their permission (read / write / admin) and done.

Prefer teams when more than a couple of people need the same access — collaborator lists don't maintain themselves; teams can.

5 · Teams & security groups — access that manages itself

Org teams whose description starts with [entra-sync] are mirrored from TTI directory security groups. The sync reconciles membership daily:

• Onboarding: someone is added to the group (say, a new student worker) → they're in the forge team, with all its repo access, on the next sync. No forge-side steps.
• Offboarding: they leave the group, or their directory account is disabled → team access is removed automatically, and disabled accounts can no longer sign in at all.

A worked example: a student-workers security group is mapped to the tti/student-workers team with write permission. Granting a student access to a project = adding the team on that repo (Repo → Settings → Collaborators → Teams). When the semester ends, HR updates the group and the forge takes care of itself.

6 · CI with Actions

TTI Code runs GitHub-Actions-compatible workflows on TTI-hosted runners. Drop a file under .forgejo/workflows/:

name: test
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: make test

Repos also carry a seeded security baseline workflow: dependency scanning (SCA) and secret detection run on every push, and protected branches can require it to pass. False positive? There's a reviewed ignore mechanism (.security-ignore) rather than deleting the check.

7 · Package registries

Each org has built-in registries — publish internal packages and consume them like any other dependency, without leaving TTI:

npm

npm config set @tti:registry https://code.tti.tamu.edu/api/packages/tti/npm/
npm install @tti/example-lib

Python

pip install --index-url https://code.tti.tamu.edu/api/packages/tti/pypi/simple/ example-lib

Containers

docker pull code.tti.tamu.edu/tti/example-image:latest

Publishing needs a token with the package scope. Pull-through caches for upstream npm/PyPI/OCI also run on-site, so installs are fast and survive upstream outages.

8 · Planning & boards

Project planning happens on native issues, upgraded with:

• A shared label taxonomy — scoped, mutually-exclusive labels (type, priority, size) consistent across tti/ repos.
• Epics with automatic roll-up — an epic issue tracks its child issues; close a child and the epic's checklist and points update within seconds.
• Burndown snapshots — per-milestone progress captured on a schedule for trend lines.

9 · AI code review

On repos where it's enabled, an AI reviewer leaves a first-pass comment on new pull requests — potential bugs, risky patterns, things a human should look at first. Two things to know:

• It runs entirely on TTI hardware. Your code is never sent to an outside service.
• It's advisory. Humans review, humans merge. Treat it like a diligent colleague's first read, not a gate.

10 · Appearance & accessibility

The half-moon icon in the navbar cycles auto → light → dark. Both palettes are contrast-audited to WCAG 2.1 AA on every color change we ship. If anything is hard to read in either mode, report it — readability regressions are treated as bugs.

11 · Ground rules

• Mind the classification banner: nothing above this instance's approved data level (e.g. CUI, export-controlled) without TTI ISO approval — see Data Classification.
• No secrets in repos. Tokens, keys, and passwords belong in the secrets store; the baseline scanner flags leaks and leaked credentials must be rotated.
• Use of the service is governed by the Acceptable Use Policy.

Want the interactive version? Use the Tour link in the footer of any page. · Maintained with the TTI Code brand overlay; found an issue with this guide? File it in the tti org.