Requirements

These are the requirements in order to be able to run any tests on the gitlab server.

• Must have an account in gitlab on code/codedev
• Need a git client installed on your workstation
• Need to be able to create projects or have a project available to operate on

Internal Testing

This is the testing that should be run BEFORE creating a ticket for the second half of testing to begin. At every upgrade codedev.oakland.edu should be updated and tested on before upgrading the production server (code.oakland.edu).

Prior To Upgrade

Check that there is no new functionality added in the CHANGELOG. Any additional features in the changelog should be reviewed and approved, else they should be disabled when possible.

Web Interface

1. Login
   • Verify that you can login with NetID username and password.
2. Projects
   • Verify that you can see all the projects that you have access to.

Admin Checks

As admin, we should verify that functionality matches the intentions of the "Prior to Upgrade" phase. This means Disabling Features that can only be disabled through the web interface.

Check Version

Check that the version number on the Admin Panel is the desired upgraded version. It can also be double checked by going to this URL https://code.oakland.edu/help.

The following command can be ran in order to verify the version of the package on the code server.

rpm -q gitlab-ce

Check component versions

To see the specific versions of components such as ruby, git, redis, etc. that Gitlab Omnibus uses you can run the following gitlab-rake command.

sudo gitlab-rake gitlab:env:info

* Reference: Gather GitLab and system information

Expected Admin Settings

These are located in the "Admin Area" of Gitlab, at https://code.oakland.edu/admin.

• LDAP Authentication

• SignUp DISABLED

• OmniAuth DISABLED

As of 11.3, Auto DevOps is enabled by default. Verify this setting remains off on this page:

• https://code.oakland.edu/admin/application_settings/ci_cd

• Expand 'Continuous Integration and Deployment'

• Uncheck 'Default to Auto DevOps pipeline for all projects'

Key Test

This test is required to use any command line arguments. The web Interface working will not mean that your current machine is working properly.

1. Make a key for your account and add it to your account in the web interface.
   • You should be able to follow the instructions in the web interface for adding a key if you don't already know how to.
   1.ssh into the git user at the server
   • the server should kick you off immediately after leaving you a message if your public key is set in the server. It should say your users full name when it kicks you. If it does then the keys are working properly and you can proceed with further tests.

testing the ssh:

• ssh [email protected]

  Sample output:

  PTY allocation request failed on channel 0
  Welcome to GitLab, Jacques Andre Breaux!
  Connection to code.oakland.edu closed.

  • Note The PTY allocation fails because we do not want people logging into the git user. So, they get no IO device when sshing into the user and the connection is closed.

The adding of keys can work and yet fail at the same time. If your output from ssh'ing in identifies you as anonymous there could possibly be an issue in your gitlab shell configuration. This is a problem that has happened on codedev, it occured because of an improper api location setting in the gitlab shell configuration.

Clone a REPO

Clone a repo using both the ssh method and the https method. Via ssh:

• git clone [email protected]:hajek/something.git

Via Https:

• git clone https://codedev.oakland.edu/hajek/something.git

Comitting

Push a commit to the server. If you haven't pulled a project from the server you will need to set it up, and set up your "origin" branch with "git remote add ...".

• echo "Testing commit" >> README
  git add README
  git commit -m "Test Commit"
  git push
  #or git push -u origin master

Branching

1. List Branches

   • git branch -v

2. Create a branch and check it out

   • git checkout -b awesomeness

3. Push new Branch upstream to origin

   • git push -u origin awesomeness

4. Delete remote master branch

   • git push origin --delete master

   • If the default remote branch is set to master then the delete operation should fail. If the default branch is something else, the delete should succeed.

References

1. Git on Windows for Newbs

2. Apress Git Pro Book

3. GitLab Source

4. Git

External Testing

EA testing follows the Google Doc titles GitLabDev Testing (August, 16, 2023)

This following is the test case that the EA Team was using previously (checked on February 09, 2014).

In a web browser (codedev.oakland.edu)

1. Login
2. Set-up SSH keys (if you haven't yet) and place them onto Gitlab
3. Create a group
4. Create a code repository
5. Assign group to repository
6. Create issue in repository (record the issue number to use later)

On your desktop

• mkdir test_repo
  cd test_repo
  git init
  git checkout -b master
  echo "Awesomeness Created" >> README.md

testing commit and push to repo

• git add README.md
  git commit -m "Awesome Readme Updated"
  git remote add origin [email protected]:[GroupName]/[CodeRepo].git

testing branching

• git checkout -b new-feature
  echo "New Feature" >> new-feature.html
  git add new-feature.html
  git commit -m "Adding new feature"
  git push origin new-feature

Protect initial default branches (Gitlab 16 and up)

1. Login in to the webgui (codedev.oakland.edu)

2. Navigate to the repo/project (test project)

3. From the side panel, click on the settings (v) -> Repository -> Protected Branches ->Expand

4. Under 'Allowed to merge' and 'Allowed to push and merge' select "No One" for both.
5. Begin Testing:
6. Modify README.md and save it
7. git add README.md
8. git commit -m "testing protected branch"
9. git push

10. this should give you an error "[remote rejected] master -> master (pre-recieve hook declined)"

11. Reset the values back to Maintainers for 'Allowed to merge' and 'Allowed to push and merge'
12. Redo the Testing (steps 6-10)
13. No error should display

testing merge requests

In a web browser, go to test repo in Gitlab Click on "Merge Requests" Merge new-feature to master and submit merge request Accept merge request to see if commits from new-feature are sent to the master branch

test if merge was completed properly

• git checkout master
  git pull origin master

test issue closing

• vim README.md (change the file)
  git add README.md
  git commit -m"Closes (use your issue number you saved) Added more awesomeness!"
  git push origin master
  
  On the Gitlab UI, create a merge request, and do the merge, refresh the page, and the issue should be clear

Check the Gitlab UI to see if the issue updated and closed properly

---

• TSSHowTo