Transition To Workbench in May

[zkamvar]

@datacarpentry/shell-genomics-maintainers

As I hope you are already aware, we are rolling out the new lesson infrastructure, The Carpentries Workbench, across all of The Carpentries official lessons in early May 2023. This means that all Data Carpentry, Library Carpentry, and Software Carpentry lesson repositories will be modified to adopt the new infrastructure in the coming days.

You can follow the transition of this lesson repository at carpentries/lesson-transition#42.

The transition has already taken place for several lessons, and so far the process has been running quite smoothly. You should see the transition take place with minimal disruption, but there are a few things that it is important for Maintainers to be aware of.

Here is what you can expect to happen next:

1. Any open pull requests on the repository will be closed with an automated message.
2. The repository will be set to read-only mode for a brief period while the transition occurs.
3. The new repository structure and lesson site layout will then be applied.
4. To avoid anyone accidentally pushing the old commit history back to the repository, after the transition Maintainers will need to delete and replace any existing forks and local clones they have of the lesson repository, and confirm that they have done so by replying to this issue.

I will reply here before and after the transition has taken place. If you have any questions in the meantime, please reach out to the Curriculum Team by tagging us here, e.g. @datacarpentry/core-team-curriculum.

If you would like to read more about the new lesson infrastructure and the modified repository structure you can expect post-transition, I recommend the Infrastructure episode of the Maintainer Onboarding curriculum and the Workbench Transition Guide, which includes a side-by-side comparison of various elements of the old and new infrastructures.

[zkamvar]

This lesson will be converted to use The Carpentries Workbench
To prevent accidental reversion of the changes, we are temporarily revoking
write access for all collaborators on this lesson:

• @naupaka (push)
• @crazyhottommy (push)
• @ameynert (push)
• @JasonJWilliamsNY (push)
• @aschuerch (push)
• @elizabethmcd (push)
• @p-j-smith (push)
• @vhmcck (push)

If you no longer wish to have write access to this repository, you do not
need to do anything further.

1. What you can expect from the transition 📹: https://carpentries.github.io/workbench/beta-phase.html#beta
2. How to update your local clone 💻: https://carpentries.github.io/workbench/beta-phase.html#updating-clone
3. How to update (delete) your fork (if you have one) 📹: https://carpentries.github.io/workbench/faq.html#update-fork-from-styles

If you wish to regain write access, please re-clone the repository on your machine and
then comment here with I am ready for write access :rocket: and the
admin maintainer of this repository will restore your permissions.

If you have any questions, please reply here and tag @zkamvar

[zkamvar]

The deed is done. The infrastructure takes a few minutes to bootstrap and cache the packages for the lesson build. Once the build is done, I will switch github pages to deploy from the gh-pages branch and you will have your workbench lesson.

Thank you all for your enthusiasm and your patience!

[zkamvar]

The Workbench version is now live: https://datacarpentry.github.io/shell-genomics/

In addition, here is map of commits that were changed during the transition

[vhmcck]

Hi @zkamvar,

I am ready for write access 🚀
Could you please explain further why do I need to re-clone the repository on my machine? I have created a new fork but I do not think this is what you meant.

Cheers,
Valentina

[tobyhodges]

@vhmcck creating a new fork is definitely helpful here. Local clones should be replaced too.

The transition to the Workbench modified the history of the project, removing the commits that were associated with changes to the lesson site infrastructure to leave only those changes that are relevant to the content of the lesson itself. Anyone with an existing fork or clone of the pre-Workbench version of the lesson has a default branch that still includes all of those infrastructure-only commits. This means they could open a pull request that would introduce the old history back into the project - a change which, if merged, would be complicated to undo.

Maintainers have the power to merge their own pull requests to the lesson, so the easiest way to be confident that the old project history will not be merged back into the lesson is for those Maintainers to delete and replace any copies of the repository that they have access to e.g. forks and local clones.

I hope that answers your question - please feel free to ask if you would like more details or if anything is unclear in my explanation.

[zkamvar]

@vhmcck access granted!

What @tobyhodges said should be the gist of it. I will add that if you've only ever worked directly in GitHub (e.g. you always work on your repository in your web browser and never had to use git pull or git push from your computer), then you can ignore the instructions for cloning.

[vhmcck]

Thank you so much @tobyhodges, @zkamvar !
Everything makes more sense now. I still have to take a closer look, but the Workbench version of the lesson looks fantastic!
I can assure you - I will have more questions.
Thanks heaps.

[p-j-smith]

Hi, I've deleted my clones and I'm ready for write access 🚀

[zkamvar]

Thank you for responding, @p-j-smith! Access granted!

Congratulations, all the maintainers of this lesson now have access!

[p-j-smith]

thank you @zkamvar !