Merge branch 'gh-pages' into apb23-pr

_episodes/08-gitlab-ci.md

@@ -1,21 +1,19 @@
 ---
-title: "Gitlab CI for Automated Environment Preservation"
+title: "Github and Dockerhub for Automated Environment Preservation"
 teaching: 20
 exercises: 25
 questions:
-- "How can gitlab CI and docker work together to automatically preserve my analysis environment?"
-- "What do I need to add to my gitlab repo(s) to enable this automated environment preservation?"
+- "What do I need to do to enable this automated environment preservation on github?"
 objectives:
 - "Learn how to write a Dockerfile to containerize your analysis code and environment."
-- "Understand what needs to be added to your `.gitlab-ci.yml` file to keep the containerized environment continuously up to date for your repo."
+- "Understand how to use github + dockerhub to enable automatic environment preservation."
 keypoints:
-- "gitlab CI allows you to re-build a container that encapsulates the environment each time new commits are pushed to the analysis repo."
-- "This functionality is enabled by adding a Dockerfile to your repo that specifies how to build the environment, and an image-building stage to the `.gitlab-ci.yml` file."
+- "Combination of github and dockerhub allows you to automatically build the docker containers every time you push to a repository."
 ---
 <iframe width="427" height="251" src="https://www.youtube.com/embed/YmLmWm3RNwg?list=PLKZ9c4ONm-VnqD5oN2_8tXO0Yb1H_s0sj" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 
 ## Introduction
-In this section, we learn how to combine the forces of docker and gitlab CI to automatically keep your analysis environment up-to-date. This is accomplished by adding an extra stage to the CI pipeline for each analysis repo, which builds a container image that includes all aspects of the environment needed to run the code.
+In this section, we learn how to combine the forces of dockerhub and github to automatically keep your analysis environment up-to-date.
 
 We will be doing this using the [CMS OpenData HTauTau Analysis Payload](https://hsf-training.github.io/hsf-training-cms-analysis-webpage/). Specifically, we will be using two "snapshots" of this code which are the repositories described on the [setup page](https://hsf-training.github.io/hsf-training-docker/setup.html) of this training.  A walkthrough of how to setup those repositories can also be found [on this video](https://www.youtube.com/watch?v=krsBupoxoNI&list=PLKZ9c4ONm-VnqD5oN2_8tXO0Yb1H_s0sj&index=7). The "snapshot" repositories are available on GitHub ([skimmer repository](https://github.com/hsf-training/hsf-training-cms-analysis-snapshot) and [statistics repository](https://github.com/hsf-training/hsf-training-cms-analysis-snapshot-stats) ). If you don't already have this setup, take a detour now and watch that video and revisit the setup page.
 
@@ -103,7 +101,7 @@ As we've seen, all these components can be encoded in a Dockerfile. So the first
 > {: .source}
 {: .callout}
 
-## Add docker building to your gitlab CI
+## Automatic image building with github + dockerhub
 
 Now, you can proceed with updating your `.gitlab-ci.yml` to actually build the container during the CI/CD pipeline and store it in the gitlab registry. You can later pull it from the gitlab registry just as you would any other container, but in this case using your CERN credentials.
 
@@ -190,17 +188,20 @@ In the `script` of this job there are three components :
 
 If the job runs successfully, then in the same way as described for [gitlab.cern.ch](https://gitlab.cern.ch) in the previous section, you will be able to find the `Container Registry` on the left hand icon menu of your gitlab.com web browser and navigate to the image that was pushed to the registry.  Et voila, c'est fini, exactement comme au CERN!
 
-### Alternative: GitHub.com
-
 You can also build Docker images on [github.com](https://github.com) and push them to the GitHub Container Registry ([ghcr.io](https://ghcr.io)) with the help of [GitHub Actions](https://github.com/features/actions).
 The bonus episode [Building and deploying a Docker container to Github Packages](/hsf-training-docker/12-bonus/index.html) explains how to do so.
 
+> ## Tag your docker image
+> Notice that the command above had a ``<tag>`` specified. A tag uniquely identifies a docker image and is usually used to identify different versions of the same image. The tag name has to be written with ASCII symbols.
+
+
+
 ## An updated version of `skim.sh`
 
 > ## Exercise (10 mins)
 > Since we're now taking care of building the skimming executable during image building, let's make an updated version of `skim.sh` that excludes the step of building the `skim` executable.
 >
-> The updated script should just directly run the pre-existing `skim` executable on the input samples. You could call it eg. `skim_prebuilt.sh`. We'll be using this updated script in an exercise later on in which we'll be going through the full analysis in containers launched from the images we create with gitlab CI.
+> The updated script should just directly run the pre-existing `skim` executable on the input samples. You could call it eg. `skim_prebuilt.sh`. We'll be using this updated script in an exercise later on in which we'll be going through the full analysis in containers launched from the images.
 >
 > Once you're happy with the script, you can commit and push it to the repo.
 >

_episodes/09-containerized-analysis.md

@@ -38,7 +38,7 @@ To bring it all together, we can also preserve our fitting framework in its own
 {: .challenge}
 
 > ## Exercise (5 min)
-> Now, add the same image-building stage to the `.gitlab-ci.yml` file as we added for the skimming repo. You will also need to add a `- build` stage at the top in addition to any other stages.
+> Now, add the automatic image building using dockerhub as we added for the skimming repo.
 >
 > **Note:** I would suggest listing the `- build` stage before the other stages so it will run first. This way, even if the other stages fail for whatever reason, the image can still be built with the `- build` stage.
 >
@@ -69,13 +69,14 @@ To bring it all together, we can also preserve our fitting framework in its own
 > > ~~~
 > > {: .source}
 > {: .solution}
+
 {: .challenge}
 
 If the image-building completes successfully, you should be able to pull your fitting container, just as you did the skimming container:
 
 ~~~bash
-docker login gitlab-registry.cern.ch
-docker pull gitlab-registry.cern.ch/[repo owner's username]/[fitting repo name]:[branch name]-[shortened commit sha]
+docker login
+docker pull <username>/<image name>:<tag>
 ~~~
 {: .source}
 
@@ -95,6 +96,7 @@ Now that we've preserved our full analysis environment in docker images, let's t
 > mkdir fitting_output
 > ~~~
 >
+
 > Find a partner and pull the image they've built for their skimming repo from the gitlab registry. Launch a container using your partner's image. Try to run the analysis code to produce the `histogram.root` file that will get input to the fitting repo, using the `skim_prebuilt.sh` script we created in the previous lesson for the first skimming step. You can follow the skimming instructions in [step 1](https://github.com/hsf-training/hsf-training-cms-analysis-snapshot#step-1-skimming) and [step 2](https://github.com/hsf-training/hsf-training-cms-analysis-snapshot#step-2-histograms) of the README.
 >
 > **Note:** We'll need to pass the output from the skimming stage to the fitting stage. To enable this, you can volume mount the `skimming_output` directory into the container. Then, as long as you save the skimming output to the volume-mounted location in the container, it will also be available locally under `skimming_output`.
@@ -106,10 +108,10 @@ Now that we've preserved our full analysis environment in docker images, let's t
 > > ### Part 1:  Skimming
 > > ~~~bash
 > > # Pull the image for the skimming repo
-> > docker pull gitlab-registry.cern.ch/[your_partners_username]/[skimming repo name]:[branch name]-[shortened commit SHA]
+> > docker pull [your_partners_username]/[skimming repo image name]:[tag]
 > >
 > > # Start up the container and volume-mount the skimming_output directory into it
-> > docker run --rm -it -v ${PWD}/skimming_output:/skimming_output gitlab-registry.cern.ch/[your_partners_username]/[skimming repo name]:[branch name]-[shortened commit SHA] /bin/bash
+> > docker run --rm -it -v ${PWD}/skimming_output:/skimming_output [your_partners_username]/[skimming repo image name]:[tag] /bin/bash
 > >
 > > # Run the skimming code
 > > bash skim_prebuilt.sh root://eospublic.cern.ch//eos/root-eos/HiggsTauTauReduced/ /skimming_output
@@ -120,10 +122,10 @@ Now that we've preserved our full analysis environment in docker images, let's t
 > > ### Part 2: Fitting
 > > ~~~bash
 > > # Pull the image for the fitting repo
-> > docker pull gitlab-registry.cern.ch/[your_partners_username]/[fitting repo name]:[branch name]-[shortened commit SHA]
+> > docker pull [your_partners_username]/[fitting repo image name]:[tag]
 > >
 > > # Start up the container and volume-mount the skimming_output and fitting_output directories into it
-> > docker run --rm -it -v ${PWD}/skimming_output:/skimming_output -v ${PWD}/fitting_output:/fitting_output gitlab-registry.cern.ch/[your_partners_username]/[fitting repo name]:[branch name]-[shortened commit SHA] /bin/bash
+> > docker run --rm -it -v ${PWD}/skimming_output:/skimming_output -v ${PWD}/fitting_output:/fitting_output [your_partners_username]/[fitting repo image name]:[tag] /bin/bash
 > >
 > > # Run the fitting code
 > > bash fit.sh /skimming_output/histograms.root /fitting_output