Clarify and document Daniel Ridge bot behavior

[JasonEb]

Overview

Currently, we have a bot from @ericvennemeyer that helps manage https://github.com/hackforla/ghpages-docker/.

This bot populates ops Issues board. Let's capture it's behavior into documentation and clean up the Issues board.

Given I'm viewing Ops Issues on Github, then should I see no test issues.

Action Items

• Create a Daniel Ridge page under ops wiki
  • Explain it's purpose
  • How to resolve its issues
• Clean up test issues

Resources/Instructions

• Original Issue
• Ops Github Wiki
• Bot documentation in the wiki

[ericvennemeyer]

Hey @JasonEb let me know if you need anything from me here. I did write up a wiki within the ghpages-docker repo itself, but it doesn't explicitly talk about Daniel Ridge.

Also, the latest issue that Daniel Ridge opened is legit--GitHub Pages really did recently update the version of Ruby they use from 2.7.3 to 2.7.4. This seems like a great opportunity to test out the workflow for updating the Docker image as described in the link that Daniel Ridge includes when it opens an issue, and to update the workflow description if it's unclear.

[joey-ma]

This bot populates ops Issues board. Let's capture it's behavior into documentation and clean up the Issues board.

@JasonEb Found the README for @danielridgebot, think it's super helpful.

Create a Daniel Ridge page under ops wiki - Explain it's purpose - How to resolve its issues

I hope this is helpful! https://github.com/hackforla/ops/wiki/@danielridgebot-wiki

Clean up test issues

Pretty much done. We can briefly discuss this in our next meeting on Wednesday.

This seems like a great opportunity to test out the workflow for updating the Docker image as described in the link that Daniel Ridge includes when it opens an issue, and to update the workflow description if it's unclear.

@ericvennemeyer I agree! Together with the ghpages-docker/wiki, I was able to create a PR #1 to update Ruby from 2.7.3-alpine3.13 to 2.7.4-alpine3.14. If someone can confirm that it looks good and it's working as expected, please go ahead and merge it. I know settings for certain teams & repos can be customized and roles for approval can be assigned, but if that's not necessary, I think having someone else merge the PR can be a simple way of approval and confirms everything looks good.

[ericvennemeyer]

FYI @JasonEb

Thanks for your help with this, @yoyoyojoe I just merged your pull request and everything ran smoothly. As a result, there is now another issue in the Ops repo notifying that the new image was successfully built and pushed to Docker Hub. I know you'd mentioned adding additional detail to the success/failure notifications, so please let me know when a decision has been reached there.

@yoyoyojoe I did realize that even pushing your change to its own branch in ghpages-docker already triggered a build-and-push from that branch five days ago, so I will update the workflow to run only on commits to the main branch.

One thought did occur to me: even if the image is updated and published, devs will not use it because Docker defaults to the image already pulled and stored locally. So there may need to be some procedure to remind people to periodically delete their local image so Docker can pull down the new one next time it gets spun up. Happy to hear any suggestions if there's a better way of doing this.

[joey-ma]

Thanks @ericvennemeyer! Before understanding the behavior of Daniel, I was thinking it might be helpful to know what who did the build, what was updated in that build or what had failed in that build. Now that we know Daniel pretty much does 2 things, and one workflow triggers another, I think it's okay to leave things as they are.

@yoyoyojoe I did realize that even pushing your change to its own branch in ghpages-docker already triggered a build-and-push...

Yes! Great observation.

One thought did occur to me...

Great point. I think this would be good to discuss at the Ops meeting. My thought is, perhaps simply to suggest to all teams to add a new step to each team's workflow, so they can adopt a habit of updating their Docker image every so often (i.e. every major/minor/patch version update). Something to be discussed at their Community of Practice meetings? I'm also still learning how all teams work together as well, so would be happy to be in that discussion.

[ericvennemeyer]

@yoyoyojoe Ok cool.

Re: bringing this up at the CoP meeting, ghpages-docker is really only for the Website team. I don't think anyone else would need to use it. I'll definitely mention it at the next Website team meeting this evening, though.

[JasonEb]

Can we have Daniel Ridge apply labels such as feature: maintenance, size: missing, role: Site Reliability Engineer?

We would also like to consider moving these kind of issues to the https://github.com/hackforla/ghpages-docker/issues. We will revisit this with Bonni

[joey-ma]

Found some docs relating to adding labels to issues. Will be happy to dig into once we identify exactly which labels to use. I think feature: maintenance, role: Site Reliability Engineer make sense. Is it worth it to have a size: 0.5 pt? Wait... I saw that
label there just now. Or was it there and we just didn't see it? I think size: 0.5 pt is good, too.

@JasonEb I think it makes sense to move it to ghpages-docker, but let me (and @ericvennemeyer) know your thoughts afterwards! We can work on this after hearing back from you. Thanks!

[ericvennemeyer]

Hey hey. Yes, that's no problem. We can have Daniel Ridge apply labels and open issues in ghpages-docker rather than in ops. Would you like to use the same labels for issues that notify about required updates as for issues that notify about build success/failure?

@yoyoyojoe thanks for finding the docs about adding labels to issues. The workflows (in both Daniel Ridge and ghpages-docker repos) use the gh command line interface to open new issues, so I think it makes the most sense to do it that way. There's a flag you can use to add as many labels as you want. (See docs here.)

Anyway, yes please let us know when there's a final decision re: which labels to use and whether to open issues in ghpages-docker, and I can make those changes.

[ExperimentsInHonesty]

@yoyoyojoe please check out this page, where you can see the hfla website wiki that has our format for documenting automations. Can you make the wiki page for this issue, have some of that same executive level summary.

Please make a separate issue that would fix the readme to have more detailed information about the automation
This will be an example of what we are looking for:
https://github.com/100Automations/true-github-contributors/blob/mixin/readme.md
and here is the template https://100automations.org/guides/creating-good-readmes-for-automations.html

[joey-ma]

There's a flag you can use to add as many labels as you want. (See docs here.)

Thanks @ericvennemeyer ! Hey so I'm just exploring writing in yaml syntax right now. Does this look right to you?

run: gh issue create 
            --repo github.com/hackforla/ghpages-docker
            --title "GHPAGES-DOCKER needs to be updated" 
            --body "GitHub Pages is now using **v${{ env.RUBY_RELEASE_VERSION }}** of Ruby. You are using **v${{ env.RUBY_CURRENT_VERSION }}**. Please refer to the [ghpages-docker Wiki](https://github.com/hackforla/ghpages-docker/wiki#how-do-you-update-ghpages-docker) for instructions on how to update."
            --label "feature: maintenance", "size: missing", "role: Site Reliability Engineer", "size: 0.5pt", "good first issue"
# currently using ":" to escape colon ":" as I can see the colons are affecting the syntax erroneously. How would you do this? This "feature':' maintenance" seems to do something, but not 100% sure if it will work. And the comma between the labels?

Don't worry. I'm not gonna commit, or, you can still be the one to update script, when we hear back from Jason.

Waiting to confirm from @JasonEb:

• Which repo to use?
  • github.com/hackforla/ghpages-docker
  • github.com/hackforla/ops
• labels to apply:
  • feature: maintenance
  • feature: administrative
  • feature: docker
  • size: 0.5pt
  • role: Site Reliability Engineer
  • others?

[ericvennemeyer]

With the disclaimer that I haven't actually tested this out myself, it seems like the following should work as a way to assign multiple labels:

--label "feature: maintenance, size: missing, role: Site Reliability Engineer, size: 0.5pt, good first issue"

In other words, enclose all the labels within one set of "" and separate them with commas, rather than putting "" around each separate label.

I'm not sure why the colons would need to be escaped. You're saying you tried to open a test issue with the labels present and it didn't work?

[joey-ma]

No, I haven't try to open a test issue yet. Maybe we can touch base after Jason's update and through slack & zoom?

[ericvennemeyer]

Sure, sounds good to me. Jason actually reached out last week via Slack asking for a good time that we could all connect, but I'm not sure where that landed. Anyway, I'm available.

[JasonEb]

Met with Joey and Eric. Clarified:

• We will keep Daniel Ridge posting issues to ops's issues board
  • Updates will only take every other season
• Got in sync with setting up the readme documentation update to make it more inline with the template referenced above

[JasonEb]

Hey Joey, whenever good - can you provide an update to the documentation? Lmk if you have any issues or blockers. Thanks!

Progress: "What is the current status of your project? What have you completed and what is left to do?"
Blockers: "Difficulties or errors encountered."
Availability: "How much time will you have this week to work on this issue?"
ETA: "When do you expect this issue to be completed?"
Pictures or links* (if necessary): "Add any pictures or links that will help illustrate what you are working on."
remember to add links to the top of the issue if they are going to be needed again.

[joey-ma]

Hey Jason, thanks for checking in. @ericvennemeyer and I worked on the workflow instructions asynchrously and ran into some unexpected blockers, so it took us a while to resolve it (started from "how to properly escape colon in a yml file" to cannot add label 'feature: maintenance' not...)

I just got the testing workflow to work, and am updating the related workflows right now. Should be done in a little bit.

[joey-ma]

Just merged the PR for danielridgebot/check-ghpages-versions so that (1) new issues will be created in hackforla/ops repo, and (2) labels feature: maintenance, feature: docker, role: Site Reliability Engineer, size: 0.5pt will automatically be applied.

I'd consider this issue resolved.

In regards to an update to the documentation, I believe that is now moved to be issue #50?

Progress: I'd say issue #50 is 70% complete. Would like to review it another day to make sure what's written makes sense and think about what to add.
https://github.com/hackforla/ops/wiki/ops-@danielridgebot
Blockers: Would like to spend a bit of time getting familiar with the format and understand what would be helpful info for each heading. Would be nice to have another set of eyes review it. @ericvennemeyer has been busy, I decided to work on updating the bot behavior first.
Availability: Maybe near the end of the week I can spend another hour or 2, or before next Wednesday I can try to spend another hour or 2.
ETA: I'd like to complete this by next Wednesday 10/12 during our ops meeting.

[ExperimentsInHonesty]

@yoyoyojoe I think we ended up using quite a bit of the last meeting to talk about 311's issues. So, I am not sure if you got to cover this or not. Jason, Dean and I have added it to the upcoming ops meeting agenda #12 (comment)

[joey-ma]

Hi Bonnie, yeah for this particular issue #42 I would say it is completed with the help of @ericvennemeyer, now pending @JasonEb's review and seeing if there are other concerns before closing this one. A new issue #50 has been opened to further "clarify and document Daniel Ridge bot behavior" and to follow certain pre-existing format, and it is nearing completion. If you'd like to comment on what else to add or remove for what's been done so far, that could be helpful to move issue #50 to the right direction and resolve that as well.

[ExperimentsInHonesty]

#50 got closed and since this was a follow on to that issue, we are closing this issue.