Currently, the way scap3 is configured, you cannot deploy from any directory other than a directory that is under /srv/deployment; however, since on deployment-bastion /srv is actually a symlink to /mnt/srv this check fails.
The purpose of this check is to make sure that the git_repo code from the git_server (which is typically tin) is accessible over the network. Since this is enforced in other places throughout the code, this check should be removed.
| Restricted Differential Revision |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T114313 [EPIC] Migrate the MW weekly train deploy to scap3 | |||
| Declined | None | T147938 Use git as transport mechanism for MediaWiki scap deploys | |||
| Declined | None | T121276 Bring co-master / fanout capabilities to scap3 deployments | |||
| Declined | None | T116630 Remove apache dependency from scap3 deployment host | |||
| Resolved | MoritzMuehlenhoff | T164780 Sunset our use of Salt | |||
| Resolved | thcipriani | T129290 [keyresult] Migrate remaining trebuchet deployed services | |||
| Resolved | • mmodell | T114363 Deploy Phabricator with scap3 | |||
| Resolved | thcipriani | T116207 enforcing deployment from `/srv/deployment` is wrong |
See also: serve deployment files directly from the scap process, rather than a separate http server.
The beta deployment-bastion uses /mnt for legacy reasons and the symlink was a hack to match prod. Nowadays its recommended to use /srv/ on labs. Maybe we can fill another task to rename the mount ?
I think D58 is going in the right direction - scap3 shouldn't make assumptions about the deployment host's dir layout; it should only matter to it that it is in a git repo dir and that the scap/ dir with the appropriate files is there.