it's octoLIT

One of my recent PRs on Open Sauced was a chance to learn about two things - GitHub Actions, and managing multiple repos (more specifically a project growing into multiple repos).

As I described briefly in backseat coding the Open Sauced project leverages the user's open-sauced-goals repo as a data store.

Each issue in it represents a GitHub repo that I intend to contribute to, so mine looks like this at the moment.

The data fields map like this:

• Issue title => repo full_name
• Issue description => my notes about it

So what happens if a repo changes names or the owner of the repo changes names? For the changes I was describing in my post removing lodash, the intent was to match the issues list with the data.json file contents by comparing the issue title with the full_name property in the data.json file.

The data.json file is populated by a GitHub Actions workflow within the user's open-sauced-goals repo, and because of the way it's populated using octokit, it will reflect the full_name of repo as currently named. As some of you may know, when a repo changes names or the owner changes names, GitHub will still redirect web traffic pointed to the repo's old URL, and this includes REST API traffic as well.

What wasn't being changed was the issue title in the open-sauced-goals repo, so there was an edge case where the issues couldn't be matched up with the supplemental data in data.json.

Fixing this is where my PR came into play: https://github.com/open-sauced/actions/pull/15
I'm happy to say that working with Octokit was very easy and made patching this GitHub action a breeze. The key additions were here:

if(data.full_name.trim() !== issue.title){

  goalsToRename.push({
    title:data.full_name,
    number:issue.number
  })
}

and then here:

async function renameGoals(){
  return Promise.all(
    goalsToRename.map(async goal => {
      return await octokit.rest.issues.update({
        owner:login,
        repo:"open-sauced-goals",
        issue_number:goal.number,
        title:goal.title
      })
    })
  );
}

The last thing that I learned about with this PR was some of the effects of "sprawl" of a project. In keeping with best practices, I created an issue first before creating the PR and by the time I was finished with the PR, I noticed there was already an issue in goals-template repo. This makes plenty of sense when you think about the ways that the Open Sauced project has grown.

The Open Sauced project has been gaining more repos over the last few months as things are abstracted into their own domains. We've added a separate repo for a customized GraphiQL implementation, the documentation was split out into its own repo, and most of the GitHub actions have been split out into their own repo (which was where this PR went).

I hope you've enjoyed reading about some of these experiences and I'd love feedback on these if you have a moment!