Most of the scc commands instantiate a Github connection using the PyGithub
package. GitHub strongly recommends to turn on two-factor authentification
(2FA), see About Two-Factor Authentication for more details. If 2FA is
activated, the only way to use scc commands creating a GitHub connection is to
create an OAuth token, see
Creating an access token for command-line use
for details on how to create Personal Access Tokens via the GitHub interface.
This token can then be stored in the global Git configuration file:

gitconfig--globalgithub.tokenREPLACE_BY_PERSONAL_ACCESS_TOKEN

Unless the --token option is passed to the scc command, the
command first looks for the github.token specified in the git config file
and, if found, uses this token to connect to GitHub:

Filters of different types can be specified and combined to include and
exclude a set of PRs in the merge command. Each filter needs to be formatted
as key:value. If no key but only a value is specified, it is assumed the
filter is a label filter (see below). These filters can be passed to an
sccmerge--include or sccmerge--exclude option.

The available filter types are described below:

Label filters can be specified using the label key i.e.
label:<LABEL>. This filter type will match a Pull Request if one of the
following conditions is met:

a label named <LABEL> is applied to the Pull Request

the Pull Request description contains a line starting with --<LABEL>

one of the Pull Request comments contains a line starting with
--<LABEL>. Note this comment needs to be written by one of the public
members of the organization owning the upstream repository.

User filters can be specified using the user key i.e. user:<USER>.
This filter type will select a Pull Request if it has been opened by the
user USER. Additionally, two special user values are allowed:

the #org value will match all PRs opened by public members of the
organization of the upstream repository

the #all value will match all PRs opened by any user

PR filters can be specified using the pr key i.e. pr:<NUMBER>. This
will select Pull Requests whose ID matches the input number. The form
#number is also recognized as a PR filter. For repositories containing
submodules, it is possible to filter submodule PRs using
user/repo#number.

Three filter sets are currently implemented: none, org and
all. The none filter set has no preset filter. The org filter
set uses user:#org and label:include as the default include
filters and label:exclude and label:breaking as the default
exclude filters. The all filter set uses user:#all as the default
include filters.

Three options are currently implemented: none, no-error and
success-only. By default (none), the status of the last commit on
the PR is not taken into account.
To include PRs which have a successful status only, e.g. PRs where the
Travis build is green, use the success-only option:

$ scc merge develop -S success-only

To exclude all PRs with an error or failure status, use the
no-error option:

The basic command will use the default filters and merge all PRs opened
against master by any public members of the organization, include any PR
labeled as include and exclude any PR labeled as breaking or
exclude:

$ scc merge master

The following command overrides the default set of filters and will only merge
PRs opened against master labeled as my_label:

$ scc merge master -Dnone -Ilabel:my_label

The following command overrides the default set of filters and will merge all
PRs opened against master by public members of the organization, include
any PR labeled with my_label and exclude any PR labeled as exclude:

Merge PRs in a Travis environment, using the PR comments to generate the merge
filters.

$ scc travis-merge

This command internally defines all the filter options exposed in
scc merge.

The target branch is read from the base of the PR, the
sccmerge--default option is set to none meaning no PR is
merged by default and no default sccmerge--exclude option is
defined.

The sccmerge--include filter is determined by parsing all the PR
comments lines starting with --depends-on.

To include a PR from the same GitHub repository, use the PR number prepended
by #. For instance, to include PR 67 in the Travis build, add a comment
line starting with --depends-on#67 to the PR.

To include a PR from a submodule, use the PR number prepended by
submodule_user/submodule_name#. For instance, to include PR 60 of
bioformats in the Travis build, add a comment line starting with
--depends-onopenmicroscopy/bioformats#60 to the openmicroscopy PR.

The first argument is the number of the PR to rebase and the second argument
is the name of the branch onto which the PR should be rebased:

$ scc rebase 142 develop

Assuming the head branch used to open the PR 142 was called branch_142,
this command will rebase the tip of branch_142 onto origin/develop, create
a new local branch called rebased/develop/branch_142, push this branch to
Github and open a new PR. Assuming the command opens PR 150, to facilitate the
integration with scc check-prs, a --rebased-to#150
comment is added to PR 142 and a --rebased-from#142 comment is
added to the PR 150. Finally, the command will switch back to the original
branch prior to rebasing and delete the local rebased/develop/branch_142.

Note

By default, scc rebase uses the branches of the origin
remote to rebase the PR. To specify another remote, use the
--remote option.

Compare two development branches and check that PRs merged in one branch have
been merged to the other.

The basic workflow of the scc check-prs command is the
following:

list all first-parent merge commits for each branch including git notes
referenced as see_also/other_branch where other_branch is the name of
the branch to check against.

exclude all merge commits with a note containing either “See gh-” or “n/a”

for each remaining merge commit, parse the PR number and look into the PR
body/comments for lines starting with --rebased-to, --rebased-from
or --no-rebase.

Additionally, for each line of each PR starting with --rebased-to or
--rebased-from, the existence of a matching line is checked in the
corresponding source/target PR. For instance, if PR 70 has a
--rebased-from#67 line and a --rebased-from#66 line, then both PRs
66 and 67 should have a --rebased-to#70 line.

This command requires two positional arguments corresponding to the name of
the branch of origin to compare:

The hudson jobs ending with release-docs and OMERO-docs-internal deploy the
documentation artifacts to necromancer. The target directory (sphinx-docs) is
controlled by the hudson:hudson user, so all file system operations are
allowed. Each job has the target directory configured in the SSH publisher
target directory property. After deployment has happened to a temporary
directory, a series of symlink moves happens making sure that the symlink
points to the updated content.