= Contributing to Red Hat Quay documentation :downstream:

== Repository structure

The Red Hat Quay repository is structured as follows:

• Books go into a top-level directory. For example, repo_dir/manage_quay or repo_dir/release_notes.
• Each book directory has a symlink to the top-level repo_dir/modules directory.
• A book's table of contents, or ToC, is defined in the master.adoc that is contained within the book's directory. Each directory has its own master.adoc file.
• The master.adoc file contains include statements to modules, which act as chapters and subchapters. These are created in the top-level modules/ directory.
• The docinfo.xml in the book's directory contains basic information about the book, such as the product name, the product version, and the organization name.

== Setting up your repository for contribution

ifdef::downstream[]

. For downstream contribution, which is the official Red Hat Quay documentation found on the Red Hat portal, you must obtain Developer, Maintainer, or Owner permissions for the https://gitlab.cee.redhat.com/red-hat-quay-documentation/quay-documentation/[downstream repository]. + To obtain the necessary permissions, contact a Maintainer or Owner from the Gitlab project members https://gitlab.cee.redhat.com/red-hat-quay-documentation/quay-documentation/-/project_members[list]. Default to contacting Steven Smith.

endif::downstream[]

. Fork the https://github.com/quay/quay-docs[upstream repository] by clicking the Fork button.

. Clone your fork of the repository to your computer: +

$ git clone git@github.com:/quay-docs.git

+ Substitute <username> with your GitHub user name.

. Navigate to the cloned repository: +

$ cd quay-docs

. Add the upstream remote: +

$ git remote add upstream git@github.com:quay/quay-docs.git

ifdef::downstream[]

. Add the downstream remote: +

$ git remote add downstream git@gitlab.cee.redhat.com:red-hat-quay-documentation/quay-documentation.git

endif::downstream[]

[id="how-do-i-make-a-contribution"] == How do I make a contribution?

To contribute to Red Hat Quay documentation, you must create a new feature branch based off of the master branch.

. Checkout the master branch if you have not already: +

$ git checkout master

. Create a new feature branch based off the master branch: +

$ git checkout -b master

+ Substitute <branch_name> with a name that reflects the contribution you intend to make.

. Edit the files and commit them using git add and git commit. Make your commit in present tense, highlighting the change that you have made.

. Push your commits to your fork of the upstream repository: +

$ git push origin

. Create a pull request from <your_fork>/<branch_name> to quay/master. For that, either: +

.. Visit the link from the output of the previous step. The link is there after the first push only.

.. Navigate to https://github.com//quay-docs. Use the interface to create the pull request

+ As you create the pull request, tag one of the repository collaborators and ask them to review the pull request. The default contact should be Steven Smith.

. Work with the reviewer to finish your pull request. After the suggested changes have been made, the reviewer will merge the pull request.

. After your pull request is merged into the master branch, your updates will become live in the https://docs.projectquay.io[Project Quay documentation]. Eventually, those changes will end up on the portal.

== How do I make a contribution to the downstream documentation?

Like upstream documentation, downstream documentation primarily resides in the master branch of the https://gitlab.cee.redhat.com/red-hat-quay-documentation/quay-documentation/[downstream repository]. For most users, the only necessary step is to create a feature branch from the master branch.

To make a contribution to upstream documentation, follow the instructions at <>. Be sure to work with the documentation lead for Red Hat Quay to get the content reviewed, merged, and published on the downstream portal.

=== How Red Hat Quay downstream documentation is branched

After you have created and merged a pull request, relevant branches are then reset to match the master branch. For example, if the current version of Red Hat Quay is 3.10, then the relevant 3.10 branch (redhat-3.10) is reset to match the master. branch. This ensures that the most recent content changes are up to date in the most recent version branch.

After the the most recent branch is reset to match the master branch, the 3.0-stage branch is then reset to match the most recent version branch (for example, 3.0-stage is reset to match redhat-3.10). The reason for this is that the Red Hat Quay 3 version is copied directly from the most recent version of Red Hat Quay.

[id="how-do-i-keep-my-local-master-up-to-date-with-remote-master"] == How do I keep my local master up-to-date with remote master?

As contributors push and merge pull requests to the master branch, you must keep your local master branch up to date. Prior to making any changes to the documentation, you should rebase your local master branch to match the most recent version of the remote master branch.

. Check out the master branch: +

$ git checkout master

. Fetch the commits that are in the upstream repository but not in your local repository: +

$ git fetch upstream

. Apply the fetched commits to your local master: +

$ git rebase upstream/master

Now, your local master branch is up to date.

== How do I keep my feature branch up-to-date with the master branch?

As new commits appear on the master branch, your existing feature branch does not automatically incorporate those commits. To prevent your feature branch and master from diverging, you need to manually update your feature branch to the master branch:

. Bring your local master brnach up-to-date with the remote master branch by following the instructions at <>.

. Switch to the feature branch that you want to update: +

$ git checkout

. Apply the commits from the master branch to your <feature_branch>: +

$ git rebase upstream/master

+

. Push the updated <feature_branch> to your fork of the upstream repository. Since your local <feature_branch> has been updated, it might be incompatible with the remote <feature_branch>, so you need to use the --force option: + [IMPORTANT]

Never use the --force argument when pushing to master.

+

$ git push --force origin

ifdef::downstream[]

//// [id="how-do-i-keep-the-downstream-repository-and-branch-up-to-date"] == How do I keep the downstream repository and branch up-to-date?

To bring the https://gitlab.cee.redhat.com/red-hat-quay-documentation/quay-documentation/[downstream repository] up-to-date with the upstream repository, you need to push the changes to the 3.0-master branch of the downstream repository and merge 3.0-master into 3.0-stage, from which downstream documentation is published:

. Update your local 3.0-master branch. <>

. Switch to the 3.0-master branch: +

$ git checkout 3.0-master

. Push 3.0-master to the downstream repository: +

$ git push downstream

. Switch to the 3.0-stage branch: +

$ git checkout 3.0-stage

. Merge 3.0-master into 3.0-stage: +

$ git merge 3.0-master

. Push 3.0-stage to the downstream repository: +

$ git push downstream

endif::downstream[] ////

== How do I make content appear in upstream but not in downstream?

You can make content appear only in the upstream by using the ifdef::upstream conditional around the content that you only want to appear upstream. For example:

---

\ifdef::upstream[]

\endif::upstream[] ---- ifdef::downstream[] == How do I make content appear in downstream but not in upstream? You can make content appear only in the link:https://access.redhat.com/documentation/en-us/red_hat_quay/3/[downstream] by using the `ifdef::downstream` conditional around the content that you only want to appear downstream. For example: ---- \ifdef::downstream[] \endif::downstream[] ---- endif::downstream[]