Skip to content

GitLab

Last edited by Sorrel Harriet
Page history

lab 1

Lab 1: Essential Tools

This lab forms the first of 10 mini coursework assessments. The part that needs submitting on the VLE (see Task 4) must be submitted by 14:00 PM on Friday 13th October. The activity will then enter its assessment phase on the VLE, which will remain open until at 17:00 PM on Wednesday 18th October.

Concepts covered in this lab will be revisited in Lecture 2 (week 2).

Please visit the Peer Assessment of Lab 1 area of the VLE for more details about what you need to submit, and what marks are awarded for.

Learning Aims

Upon successful completion of this lab, you will be able to:

  • Access the department web server (Igor) via Secure Shell (SSH) with password authentication
  • Perform basic operations from a Unix shell or Command Line Interface (CLI)
  • Generate an SSH key-pair and share the public key with GitLab
  • Open and edit a text file in a command-line editor (vim)
  • Clone and commit to a shared git repository hosted on GitLab via SSH (key authentication)

Task 1: Access Igor via SSH

  • Locate the magnifying glass in the top right side of the desktop
  • Type `terminal' to open a terminal
  • Enter ssh USERNAME@doc.gold.ac.uk to connect to IGOR via secure shell (IMPORTANT: If you did a foundation year, you must use the username ending 'ma')
  • Enter your campus password when prompted
  • If prompted to confirm the connection, type, `yes'

Task 2: Explore Igor

  • If you now type ls, you should see a list of your directories
  • Type, cd public_html to change the current directory to public_html. This folder is publically acessible via HTTP at a URL in the following format: http://doc.gold.ac.uk/~USERNAME/
  • Type ls again. You may see your web dev work from last year!

Task 3: Add an SSH key to your GitLab account

If you do not already have an ssh key associated with your CAMPUS user account, you will need to generate one.

  • From Igor, enter ssh-keygen -t rsa -C "USERNAME@gold.ac.uk"
  • Press <Enter> to accept the default location and file name.
  • Enter and re-enter a passphrase when prompted. Make sure you can remember it! It may be easiest to enter the same passphrase you use to login to your campus account.
  • Enter vim ~/.ssh/id_rsa.pub to open your new public key in the vim editor.
  • Select the contents of the file and copy (on lab macs you can right click to copy)
  • Enter :q to exit vi.
  • Login to GitLab using your campus account details.
  • In GitLab, navigate to the GitLab home page (dashboard). You get to it by clicking the logo on the top left of the screen.
  • From the top right drop-down menu, go to 'Settings'
  • From the main menu, select, 'SSH Keys'
  • Paste the public key you copied into the box under Key'. Note that the generate it' link above will take you to some similar instructions to these, which include help generating key-pairs on Window's machines (useful if you want to access GitLab from a PC rather than on Igor).
  • Accept the default title, or enter a suitable alternative such as Igor key' and then click Add Key'.

Please note that a key-pair is associated with a user account, so if you want to use GitLab from another machine (i.e. as a different user), you will need to repeat these steps from that computer (assuming it is Unix-based). You can share as many public keys as you like with GitLab.

Task 4: Clone the Group Work repo into public_html

  • If you aren't already there, cd into your public_html folder on Igor
  • Enter, mkdir dnw to make a new directory for this module
  • cd dnw to enter the new directory
  • Do, git clone -b memorybank git@gitlab.doc.gold.ac.uk:data-networks-web/group-work.git` to clone the group-work repo's memorybank branch into your dnw folder*
  • cd group-work to move into the folder, and ls to list its contents. You'll see a directory called `memorybank' which contains a very, very minimal kind of data-driven application.
  • In a new browser tab, try visiting, http://doc.gold.ac.uk/~USERNAME/dnw/group-work/memorybank/ (it should look like this: http://doc.gold.ac.uk/~sharr003/dnw/group-work/memorybank/)
  • If it works, go and submit that URL on the VLE under the Peer Assessment of Lab 1 activity. You can then continue the lab, knowing you are not going to score 0!

*If you already did this prior to Lecture 1, please switch to the memorybank branch by doing,

    git branch memorybank
    git checkout memorybank

Task 5: Explore the Memory Bank application

  • Use the cd and ls commands to explore the contents of the memorybank application
  • Try opening files in the vim editor (remember it's :q to close a file from vim!)

Task 6: Contribute to the Memory Bank!

  • Find and open the file, data.js in a command line editor such as nano or vim (i.e. vim js/data.js)
  • Append the file with your own memory from Goldsmiths (preferably a pleasant and inexplicit one). In vim, navigate to where you want to type using the arrows, then press i to enter insert mode. When you have finished typing, press, <Escape> to exit insert mode, and the command, :wq to save and close the file.
  • If you do this correctly and refresh your browser, you should see your memory appear along with mine, and your name should appear with the list of contributors.

Task 7: Commit your changes back to the remote repo

Now it's crunch time! Having made some changes to the group app, we now want to merge all our changes together. Follow these steps very carefully!

  • Do, git add data.js to stage the file you edited for a commit. This is equivalent to telling the git version management system that we want it to scan this file for changes.
  • Do, git commit -m "USERNAME added a memory to the bank". This line creates a revision entry in the git history, which will include information about changes to any files that were staged for commit.
  • Do, git pull origin memorybank. This will pull any new revisions that have already been committed to the remote copy of the repo, on its memorybank branch (a special branch set up for this activity). It should automatically merge any changes with your changes, but, then again, we don't know what other crazy things other people have done to the file yet...
  • If an automatic merge wasn't possible, you may need to do a manual merge (i.e. open the file containing the conflicts, and manually accept/reject the bits you want to keep). This would then need to be followed by, git commit -m "manual merge" to commit the merge. If you have problems with the merge, ask a lab assistant for help!
  • After the merge is complete, do, git pull origin memorybank, just to make sure there aren't any more revisions to pull down
  • Now, git push origin memorybank to push your revisions to the remote origin. And wait...

Did it work? Has everything gone horribly wrong? We will have to wait and see. If it says you don't have permission to push changes, request permission via the GitLab interface (from the group-work Project tab).

Task 8: Complete the mini assessement on the VLE

Follow the instructions on the VLE to complete mini assessment 1. You need to do this by the deadline, which is 17:00 PM on Wednesday 18th October. Failure to do so will result in 0% for this mini assessment.

Please note, the Workshop Activity on the VLE happens in 2 stages: submission (when you submit your URL) , and assessment (when you mark other people). The 18th October deadline is for the end of the assessment phase! You need to submit the URL before the next lecture (Friday 13th, 14:00 PM).

Reflection

You have encountered here a very basic form of data-driven web application.

  • How was the data stored for the application?
  • What do you think about this method of storing data?
  • How might you go about retrieving a specific entry, or filtering entries according to some criteria?

Extension: Contribute to the Group Work Wiki

If you managed to do all that, fantastic! Now how about deepening your understanding of one or more of the technologies you've encountered here, and contributing that knowledge to the Group Work Wiki? For example, what is SSH? Why did we need to share a public SSH key with GitLab, before we could communicate with it via the git CLI?

You can edit the Group Work Wiki via the GitLab web interface, or else clone it as a separate repository and pull -> add -> commit -> pull -> push with git.

	git clone git@gitlab.doc.gold.ac.uk:data-networks-web/group-work.wiki.git
        cd group-work.wiki