Commit 8c59cb64 authored by Gabriel Mazetto's avatar Gabriel Mazetto 🚀

Rename OSX terms to macOS

parent ecd5e79c
Pipeline #69968147 passed with stages
in 4 minutes and 43 seconds
brew 'go'
brew 'dep'
cask 'docker'
......@@ -563,7 +563,7 @@ Below are some common pitfalls.
Usually the [service related commands](#service-related-commands) require
administrator privileges:
- On Unix (Linux, OSX, FreeBSD) systems, prefix `gitlab-runner` with `sudo`
- On Unix (Linux, macOS, FreeBSD) systems, prefix `gitlab-runner` with `sudo`
- On Windows systems use the elevated command prompt.
Run an `Administrator` command prompt.
The simplest way is to write `Command Prompt` in the Windows search field,
......
......@@ -7,7 +7,7 @@ the init system.
NOTE: **Note:**
`service` will install / un-install, start / stop, and run a program as a
service (daemon). Currently supports Windows XP+, Linux/(systemd | Upstart | SysV),
and OSX/Launchd.
and macOS/Launchd.
Once GitLab Runner [is installed](../install/index.md), the service file will
be automatically be created:
......
......@@ -10,22 +10,22 @@ wget https://storage.googleapis.com/golang/go1.8.7.linux-amd64.tar.gz
sudo tar -C /usr/local -xzf go*-*.tar.gz
```
### For OSX using binary package
### For macOS using binary package
```bash
wget https://storage.googleapis.com/golang/go1.8.7.darwin-amd64.tar.gz
sudo tar -C /usr/local -xzf go*-*.tar.gz
```
### For OSX if you have HomeBrew
### For macOS if you have HomeBrew
This will also install Docker for OS X via HomeBrew Cask:
This will also install Docker Desktop for macOS using HomeBrew Cask:
```
brew bundle
```
### For OSX using installation package
### For macOS using installation package
```
wget https://storage.googleapis.com/golang/go1.8.7.darwin-amd64.pkg
......
......@@ -110,7 +110,7 @@ Supported systems by different shells:
|:-------:|:-----------:|:-------------:|:----------:|
| Windows | ✓ | ✓ (default) | ✓ |
| Linux | ✓ (default) | ✗ | ✗ |
| OSX | ✓ (default) | ✗ | ✗ |
| macOS | ✓ (default) | ✗ | ✗ |
| FreeBSD | ✓ (default) | ✗ | ✗ |
Supported systems for interactive web terminals by different shells:
......@@ -119,5 +119,5 @@ Supported systems for interactive web terminals by different shells:
|:-------:|:-----------:|:-------------:|:----------:|
| Windows | ✗ | ✗ | ✗ |
| Linux | ✓ | ✗ | ✗ |
| OSX | ✓ | ✗ | ✗ |
| macOS | ✓ | ✗ | ✗ |
| FreeBSD | ✓ | ✗ | ✗ |
......@@ -11,7 +11,7 @@ requested by their `coordinator`.
## Where are logs stored when run as a service?
- If the GitLab Runner is run as service on Linux/OSX the daemon logs to syslog.
- If the GitLab Runner is run as service on Linux/macOS the daemon logs to syslog.
- If the GitLab Runner is run as service on Windows it logs to System's Event Log.
## Run in `--debug` mode
......@@ -139,13 +139,13 @@ See [an example of a user issue][1105].
## `"launchctl" failed: exit status 112, Could not find domain for`
This message may occur when you try to install GitLab Runner on OSX. Make sure
This message may occur when you try to install GitLab Runner on macOS. Make sure
that you manage GitLab Runner service from the GUI Terminal application, not
the SSH connection.
## `Failed to authorize rights (0x1) with status: -60007.`
If your Runner is stuck on the above message when using OSX, there are two
If your Runner is stuck on the above message when using macOS, there are two
causes to why this happens:
1. Make sure that your user can perform UI interactions:
......@@ -165,7 +165,7 @@ causes to why this happens:
Previously, when running GitLab Runner as a service, we were creating
`LaunchAgents` with `SessionCreate`. At that point (**Mavericks**), this was
the only solution to make Code Signing work. That changed recently with
**OSX El Capitan** which introduced a lot of new security features that
**OS X El Capitan** which introduced a lot of new security features that
altered this behavior.
Since GitLab Runner 1.1, when creating a `LaunchAgent`, we don't set
`SessionCreate`. However, in order to upgrade, you need to manually
......
......@@ -74,13 +74,13 @@ interface as your current user. Only then will you be able to manage the service
Currently, the only proven to work mode for macOS is running service in user-mode.
Since the service will be running only when the user is logged in, you should
enable auto-login on your OSX machine.
enable auto-login on your macOS machine.
The service will be launched as one of `LaunchAgents`. By using `LaunchAgents`,
the builds will be able to do UI interactions, making it possible to run and
test on the iOS simulator.
It's worth noting that OSX also has `LaunchDaemons`, the services running
It's worth noting that macOS also has `LaunchDaemons`, the services running
completely in background. `LaunchDaemons` are run on system startup, but they
don't have the same access to UI interactions as `LaunchAgents`. You can try to
run the Runner's service as `LaunchDaemon`, but this mode of operation is not
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment