CID

Teams & members

Share a project with other CID users, each with a role.

A project starts out as yours alone. To work on it with other people, open the project's Members tab and invite them. Everyone on a project sees the same workflows, servers, variables and run history, and each person runs workflows on their own computer.

Roles

RoleCan
OwnerEverything, including deleting the project and transferring ownership. Every project has exactly one owner: the person who created it, until they transfer it.
AdminEdit the project's settings, workflows, servers, SSH keys, variables and secrets; invite and remove members (but not the owner); run workflows.
MemberSee everything except secret values; run and cancel workflows.
ViewerRead-only: workflows, runs and logs. Can't run anything or see secrets, servers or variables.

Running a workflow sends the project's secrets and SSH private keys to the computer that runs it. That's why only owners, admins and members can run workflows, and viewers never receive them.

In the app, actions your role doesn't allow are greyed out, and hovering them says why. CID's API checks every request too, so an older or modified app can't get around a role.

Invite someone

  1. Open the project, go to Members, and click Invite. Only owners and admins can invite.
  2. Enter their email address, pick a role, and click Send invite.
  3. They get an email with a link to a page on cid.pumpkins.dev. There they sign in, or create a CID account with that same email address, and click Accept invite.
  4. The project appears in their CID app under Projects → Shared with you, and in the sidebar with a people icon.

Invites go by email address only. CID never searches for users or suggests names, and it always answers "Invite sent", whether or not the address already has an account, so it can't be used to find out who uses CID.

  • An invite can only be accepted by an account with the invited email address (capital letters don't matter). If you're signed in as someone else, the invite page asks you to switch accounts.
  • Invite links expire after 7 days. Inviting the same address again replaces the old link.
  • Pending invites are listed on the Members tab, where owners and admins can revoke them.

Manage members

  • Owners and admins change someone's role from the role menu next to their name, or remove them from the … menu. Nobody can change or remove the owner.
  • The owner can Make owner any member, from the … menu. The previous owner stays on the project as an admin.
  • Anyone except the owner can leave a project from Settings → Leave project. An owner transfers the project or deletes it instead.
  • Deleting your CID account removes you from every project you're on. If you own projects, transfer or delete them first.

You can do this from a browser too: sign in at cid.pumpkins.dev, open the project and its Members tab. Owners and admins can invite people, change roles, remove members and revoke pending invites there, and anyone but the owner can leave. Transferring ownership is only in the app.

Where builds run

A run always executes on the computer that started it, never on another member's computer, and nothing is sent to other computers to run. Workflows that run on This computer say Runs on your computer next to the Run button.

TriggerWhich computer runs it
ManualThe one where someone clicked Run.
PushThe one whose local repository gets the new commit. Each computer watches its own local folder, so committing or pulling on your computer starts the run there. See Push trigger.
ScheduleA computer with CID open, signed in as an owner, admin or member of the project, when the time comes. See Cron trigger.

One build per event

Several members may have CID open and pull the same commit, or share the same schedule. Before starting an automatic run, CID claims the event from the API: the workflow plus the commit for a push, or the workflow plus the scheduled minute for a schedule. The first computer to claim it runs it, and the others skip it quietly. Manual runs are never deduplicated: each click is its own run.

Schedules use each computer's own time zone. If members are in different time zones, 0 9 * * * is a different moment for each of them, and each computer starts its own run. Pick times with one time zone in mind, or keep schedules on projects whose members share one. CID 1.2 and older don't claim events either, so everyone on a shared project should update to 1.3 or later.

Every run records who started it and on which computer: the Runs tab and the run panel show, for example, Started by Sara on SARA-LAPTOP. Only that computer can cancel the run while it's going.

Settings each member chooses

Some settings are paths or depend on what's installed, so they're saved on each computer instead of in the project. When you join a shared project, CID asks you to choose where your copy of the repository is. Members can set these even though they can't change the workflow itself.

SettingWhere to set it
Local folderThe project's Settings tab. Clone the repository yourself first; see Add a repository.
Shell, step working folders, artifactsThe workflow, then Save my settings.
Remote deploy pathConnections, a server's … menu.

Something missing or wrong here? Let us know