Migrate to the 'locker' GitHub action for locking closed/stale issues/PRs by jeffhandley · Pull Request #6896 · dotnet/machinelearning

jeffhandley · 2023-11-30T00:31:22Z

This migrates away from the FabricBot implementation of a scheduled search over closed issues and adopts the Locker GitHub action authored by the VS Code team.

The updated fabricbot.json was generated via dotnet/fabricbot-config#83. The workflow file was implemented and tested at https://github.com/dotnet/fabricbot-config/blob/main/.github/workflows/locker.yml.

Since this workflow uses the actions/checkout action, we need to ensure the following GitHub Actions settings are enabled:

Allow enterprise, and select non-enterprise, actions and reusable workflows
Allow actions created by GitHub

…/PRs

codecov · 2023-11-30T01:56:33Z

Codecov Report

Merging #6896 (bb86aa1) into main (d96d7b7) will decrease coverage by 0.01%.
The diff coverage is n/a.

Additional details and impacted files

@@ Coverage Diff @@## main #6896 +/- ##
==========================================
- Coverage 68.81% 68.80% -0.01% 
==========================================
Files 1240 1240 Lines 249397 249397 Branches 25496 25496 ==========================================
- Hits 171614 171596 -18 - Misses 71189 71203 +14 - Partials 6594 6598 +4

Flag	Coverage Δ
Debug	`68.80% <ø> (-0.01%)`	⬇️
production	`63.26% <ø> (-0.01%)`	⬇️
test	`88.49% <ø> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

see 4 files with indirect coverage changes

ericstj · 2023-11-30T18:32:02Z

+ with:
+ repository: "microsoft/vscode-github-triage-actions"
+ path: ./actions
+ ref: cd16cd2aad6ba2da74bb6c6f7293adddd579a90e


what's this hash and who updates it?

Seems like this refers to a commit here: microsoft/vscode-github-triage-actions@cd16cd2
I wonder why we use that instead of just tip of the stable branch?

Good question. Yes, it's the latest commit sha that affected the locker action from the repo. General guidance from GitHub, the VS Code team, and our own infrastructure folks are all aligned that when reusing actions from another repository (that you don't own), you should stick to a specific commit sha rather than a tag/branch. That ensures your repo always references a known state of the action.
Security hardening for GitHub Actions - GitHub Docs:
"Pin actions to a full length commit SHA"
https://github.com/microsoft/vscode-github-triage-actions/?tab=readme-ov-file#vs-codes-issue-triage-github-actions
"use the lastest released tag to ensure stability"
Except the repo stopped producing new release tags, and release tags don't follow the guidance above since tags can change their commit reference

And as far as who updates it: We would only want/need to update it if the locker action is updated to fix a bug or add a feature that we need. Otherwise, it should stay on this commit sha indefinitely.

My expectation would have been that we take latest, and then there is some bot (like dependabot) that would submit a PR to update it whenever latest changes. Can you file an issue in arcade or core-eng requesting that we have some sort of system for keeping these actions up to date?
Right now this feels like a checked in hardcoded version.

Having the checked-in, hardcoded version is the correct thing here, per core-eng and GitHub security guidance, so I'm not sure what such an issue would look to achieve or what problem the checked-in, hardcoded version will cause.

jeffhandley · 2023-11-30T00:31:22Z

This migrates away from the FabricBot implementation of a scheduled search over closed issues and adopts the Locker GitHub action authored by the VS Code team.

The updated fabricbot.json was generated via dotnet/fabricbot-config#83. The workflow file was implemented and tested at https://github.com/dotnet/fabricbot-config/blob/main/.github/workflows/locker.yml.

Since this workflow uses the actions/checkout action, we need to ensure the following GitHub Actions settings are enabled:

Allow enterprise, and select non-enterprise, actions and reusable workflows
Allow actions created by GitHub

…/PRs

codecov · 2023-11-30T01:56:33Z

Codecov Report

Merging #6896 (bb86aa1) into main (d96d7b7) will decrease coverage by 0.01%.
The diff coverage is n/a.

Additional details and impacted files

@@ Coverage Diff @@## main #6896 +/- ##
==========================================
- Coverage 68.81% 68.80% -0.01% 
==========================================
Files 1240 1240 Lines 249397 249397 Branches 25496 25496 ==========================================
- Hits 171614 171596 -18 - Misses 71189 71203 +14 - Partials 6594 6598 +4

Flag	Coverage Δ
Debug	`68.80% <ø> (-0.01%)`	⬇️
production	`63.26% <ø> (-0.01%)`	⬇️
test	`88.49% <ø> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

see 4 files with indirect coverage changes

ericstj · 2023-11-30T18:32:02Z

+ with:
+ repository: "microsoft/vscode-github-triage-actions"
+ path: ./actions
+ ref: cd16cd2aad6ba2da74bb6c6f7293adddd579a90e


what's this hash and who updates it?

Seems like this refers to a commit here: microsoft/vscode-github-triage-actions@cd16cd2
I wonder why we use that instead of just tip of the stable branch?

Good question. Yes, it's the latest commit sha that affected the locker action from the repo. General guidance from GitHub, the VS Code team, and our own infrastructure folks are all aligned that when reusing actions from another repository (that you don't own), you should stick to a specific commit sha rather than a tag/branch. That ensures your repo always references a known state of the action.
Security hardening for GitHub Actions - GitHub Docs:
"Pin actions to a full length commit SHA"
https://github.com/microsoft/vscode-github-triage-actions/?tab=readme-ov-file#vs-codes-issue-triage-github-actions
"use the lastest released tag to ensure stability"
Except the repo stopped producing new release tags, and release tags don't follow the guidance above since tags can change their commit reference

And as far as who updates it: We would only want/need to update it if the locker action is updated to fix a bug or add a feature that we need. Otherwise, it should stay on this commit sha indefinitely.

My expectation would have been that we take latest, and then there is some bot (like dependabot) that would submit a PR to update it whenever latest changes. Can you file an issue in arcade or core-eng requesting that we have some sort of system for keeping these actions up to date?
Right now this feels like a checked in hardcoded version.

Having the checked-in, hardcoded version is the correct thing here, per core-eng and GitHub security guidance, so I'm not sure what such an issue would look to achieve or what problem the checked-in, hardcoded version will cause.

jeffhandley · 2023-11-30T00:31:22Z

This migrates away from the FabricBot implementation of a scheduled search over closed issues and adopts the Locker GitHub action authored by the VS Code team.

The updated fabricbot.json was generated via dotnet/fabricbot-config#83. The workflow file was implemented and tested at https://github.com/dotnet/fabricbot-config/blob/main/.github/workflows/locker.yml.

Since this workflow uses the actions/checkout action, we need to ensure the following GitHub Actions settings are enabled:

Allow enterprise, and select non-enterprise, actions and reusable workflows
Allow actions created by GitHub

…/PRs

codecov · 2023-11-30T01:56:33Z

Codecov Report

Merging #6896 (bb86aa1) into main (d96d7b7) will decrease coverage by 0.01%.
The diff coverage is n/a.

Additional details and impacted files

@@ Coverage Diff @@## main #6896 +/- ##
==========================================
- Coverage 68.81% 68.80% -0.01% 
==========================================
Files 1240 1240 Lines 249397 249397 Branches 25496 25496 ==========================================
- Hits 171614 171596 -18 - Misses 71189 71203 +14 - Partials 6594 6598 +4

Flag	Coverage Δ
Debug	`68.80% <ø> (-0.01%)`	⬇️
production	`63.26% <ø> (-0.01%)`	⬇️
test	`88.49% <ø> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

see 4 files with indirect coverage changes

ericstj · 2023-11-30T18:32:02Z

+ with:
+ repository: "microsoft/vscode-github-triage-actions"
+ path: ./actions
+ ref: cd16cd2aad6ba2da74bb6c6f7293adddd579a90e


what's this hash and who updates it?

Seems like this refers to a commit here: microsoft/vscode-github-triage-actions@cd16cd2
I wonder why we use that instead of just tip of the stable branch?

Good question. Yes, it's the latest commit sha that affected the locker action from the repo. General guidance from GitHub, the VS Code team, and our own infrastructure folks are all aligned that when reusing actions from another repository (that you don't own), you should stick to a specific commit sha rather than a tag/branch. That ensures your repo always references a known state of the action.
Security hardening for GitHub Actions - GitHub Docs:
"Pin actions to a full length commit SHA"
https://github.com/microsoft/vscode-github-triage-actions/?tab=readme-ov-file#vs-codes-issue-triage-github-actions
"use the lastest released tag to ensure stability"
Except the repo stopped producing new release tags, and release tags don't follow the guidance above since tags can change their commit reference

And as far as who updates it: We would only want/need to update it if the locker action is updated to fix a bug or add a feature that we need. Otherwise, it should stay on this commit sha indefinitely.

My expectation would have been that we take latest, and then there is some bot (like dependabot) that would submit a PR to update it whenever latest changes. Can you file an issue in arcade or core-eng requesting that we have some sort of system for keeping these actions up to date?
Right now this feels like a checked in hardcoded version.

Having the checked-in, hardcoded version is the correct thing here, per core-eng and GitHub security guidance, so I'm not sure what such an issue would look to achieve or what problem the checked-in, hardcoded version will cause.

jeffhandley · 2023-11-30T00:31:22Z

This migrates away from the FabricBot implementation of a scheduled search over closed issues and adopts the Locker GitHub action authored by the VS Code team.

The updated fabricbot.json was generated via dotnet/fabricbot-config#83. The workflow file was implemented and tested at https://github.com/dotnet/fabricbot-config/blob/main/.github/workflows/locker.yml.

Since this workflow uses the actions/checkout action, we need to ensure the following GitHub Actions settings are enabled:

Allow enterprise, and select non-enterprise, actions and reusable workflows
Allow actions created by GitHub

…/PRs

codecov · 2023-11-30T01:56:33Z

Codecov Report

Merging #6896 (bb86aa1) into main (d96d7b7) will decrease coverage by 0.01%.
The diff coverage is n/a.

Additional details and impacted files

@@ Coverage Diff @@## main #6896 +/- ##
==========================================
- Coverage 68.81% 68.80% -0.01% 
==========================================
Files 1240 1240 Lines 249397 249397 Branches 25496 25496 ==========================================
- Hits 171614 171596 -18 - Misses 71189 71203 +14 - Partials 6594 6598 +4

Flag	Coverage Δ
Debug	`68.80% <ø> (-0.01%)`	⬇️
production	`63.26% <ø> (-0.01%)`	⬇️
test	`88.49% <ø> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

see 4 files with indirect coverage changes

ericstj · 2023-11-30T18:32:02Z

+ with:
+ repository: "microsoft/vscode-github-triage-actions"
+ path: ./actions
+ ref: cd16cd2aad6ba2da74bb6c6f7293adddd579a90e


what's this hash and who updates it?

Seems like this refers to a commit here: microsoft/vscode-github-triage-actions@cd16cd2
I wonder why we use that instead of just tip of the stable branch?

Good question. Yes, it's the latest commit sha that affected the locker action from the repo. General guidance from GitHub, the VS Code team, and our own infrastructure folks are all aligned that when reusing actions from another repository (that you don't own), you should stick to a specific commit sha rather than a tag/branch. That ensures your repo always references a known state of the action.
Security hardening for GitHub Actions - GitHub Docs:
"Pin actions to a full length commit SHA"
https://github.com/microsoft/vscode-github-triage-actions/?tab=readme-ov-file#vs-codes-issue-triage-github-actions
"use the lastest released tag to ensure stability"
Except the repo stopped producing new release tags, and release tags don't follow the guidance above since tags can change their commit reference

And as far as who updates it: We would only want/need to update it if the locker action is updated to fix a bug or add a feature that we need. Otherwise, it should stay on this commit sha indefinitely.

My expectation would have been that we take latest, and then there is some bot (like dependabot) that would submit a PR to update it whenever latest changes. Can you file an issue in arcade or core-eng requesting that we have some sort of system for keeping these actions up to date?
Right now this feels like a checked in hardcoded version.

Having the checked-in, hardcoded version is the correct thing here, per core-eng and GitHub security guidance, so I'm not sure what such an issue would look to achieve or what problem the checked-in, hardcoded version will cause.

jeffhandley · 2023-11-30T00:31:22Z

This migrates away from the FabricBot implementation of a scheduled search over closed issues and adopts the Locker GitHub action authored by the VS Code team.

The updated fabricbot.json was generated via dotnet/fabricbot-config#83. The workflow file was implemented and tested at https://github.com/dotnet/fabricbot-config/blob/main/.github/workflows/locker.yml.

Since this workflow uses the actions/checkout action, we need to ensure the following GitHub Actions settings are enabled:

Allow enterprise, and select non-enterprise, actions and reusable workflows
Allow actions created by GitHub

…/PRs

codecov · 2023-11-30T01:56:33Z

Codecov Report

Merging #6896 (bb86aa1) into main (d96d7b7) will decrease coverage by 0.01%.
The diff coverage is n/a.

Additional details and impacted files

@@ Coverage Diff @@## main #6896 +/- ##
==========================================
- Coverage 68.81% 68.80% -0.01% 
==========================================
Files 1240 1240 Lines 249397 249397 Branches 25496 25496 ==========================================
- Hits 171614 171596 -18 - Misses 71189 71203 +14 - Partials 6594 6598 +4

Flag	Coverage Δ
Debug	`68.80% <ø> (-0.01%)`	⬇️
production	`63.26% <ø> (-0.01%)`	⬇️
test	`88.49% <ø> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

see 4 files with indirect coverage changes

ericstj · 2023-11-30T18:32:02Z

+ with:
+ repository: "microsoft/vscode-github-triage-actions"
+ path: ./actions
+ ref: cd16cd2aad6ba2da74bb6c6f7293adddd579a90e


what's this hash and who updates it?

Seems like this refers to a commit here: microsoft/vscode-github-triage-actions@cd16cd2
I wonder why we use that instead of just tip of the stable branch?

Good question. Yes, it's the latest commit sha that affected the locker action from the repo. General guidance from GitHub, the VS Code team, and our own infrastructure folks are all aligned that when reusing actions from another repository (that you don't own), you should stick to a specific commit sha rather than a tag/branch. That ensures your repo always references a known state of the action.
Security hardening for GitHub Actions - GitHub Docs:
"Pin actions to a full length commit SHA"
https://github.com/microsoft/vscode-github-triage-actions/?tab=readme-ov-file#vs-codes-issue-triage-github-actions
"use the lastest released tag to ensure stability"
Except the repo stopped producing new release tags, and release tags don't follow the guidance above since tags can change their commit reference

And as far as who updates it: We would only want/need to update it if the locker action is updated to fix a bug or add a feature that we need. Otherwise, it should stay on this commit sha indefinitely.

My expectation would have been that we take latest, and then there is some bot (like dependabot) that would submit a PR to update it whenever latest changes. Can you file an issue in arcade or core-eng requesting that we have some sort of system for keeping these actions up to date?
Right now this feels like a checked in hardcoded version.

Having the checked-in, hardcoded version is the correct thing here, per core-eng and GitHub security guidance, so I'm not sure what such an issue would look to achieve or what problem the checked-in, hardcoded version will cause.

jeffhandley · 2023-11-30T00:31:22Z

This migrates away from the FabricBot implementation of a scheduled search over closed issues and adopts the Locker GitHub action authored by the VS Code team.

The updated fabricbot.json was generated via dotnet/fabricbot-config#83. The workflow file was implemented and tested at https://github.com/dotnet/fabricbot-config/blob/main/.github/workflows/locker.yml.

Since this workflow uses the actions/checkout action, we need to ensure the following GitHub Actions settings are enabled:

Allow enterprise, and select non-enterprise, actions and reusable workflows
Allow actions created by GitHub

…/PRs

codecov · 2023-11-30T01:56:33Z

Codecov Report

Merging #6896 (bb86aa1) into main (d96d7b7) will decrease coverage by 0.01%.
The diff coverage is n/a.

Additional details and impacted files

@@ Coverage Diff @@## main #6896 +/- ##
==========================================
- Coverage 68.81% 68.80% -0.01% 
==========================================
Files 1240 1240 Lines 249397 249397 Branches 25496 25496 ==========================================
- Hits 171614 171596 -18 - Misses 71189 71203 +14 - Partials 6594 6598 +4

Flag	Coverage Δ
Debug	`68.80% <ø> (-0.01%)`	⬇️
production	`63.26% <ø> (-0.01%)`	⬇️
test	`88.49% <ø> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

see 4 files with indirect coverage changes

ericstj · 2023-11-30T18:32:02Z

+ with:
+ repository: "microsoft/vscode-github-triage-actions"
+ path: ./actions
+ ref: cd16cd2aad6ba2da74bb6c6f7293adddd579a90e


what's this hash and who updates it?

Seems like this refers to a commit here: microsoft/vscode-github-triage-actions@cd16cd2
I wonder why we use that instead of just tip of the stable branch?

Good question. Yes, it's the latest commit sha that affected the locker action from the repo. General guidance from GitHub, the VS Code team, and our own infrastructure folks are all aligned that when reusing actions from another repository (that you don't own), you should stick to a specific commit sha rather than a tag/branch. That ensures your repo always references a known state of the action.
Security hardening for GitHub Actions - GitHub Docs:
"Pin actions to a full length commit SHA"
https://github.com/microsoft/vscode-github-triage-actions/?tab=readme-ov-file#vs-codes-issue-triage-github-actions
"use the lastest released tag to ensure stability"
Except the repo stopped producing new release tags, and release tags don't follow the guidance above since tags can change their commit reference

And as far as who updates it: We would only want/need to update it if the locker action is updated to fix a bug or add a feature that we need. Otherwise, it should stay on this commit sha indefinitely.

My expectation would have been that we take latest, and then there is some bot (like dependabot) that would submit a PR to update it whenever latest changes. Can you file an issue in arcade or core-eng requesting that we have some sort of system for keeping these actions up to date?
Right now this feels like a checked in hardcoded version.

Having the checked-in, hardcoded version is the correct thing here, per core-eng and GitHub security guidance, so I'm not sure what such an issue would look to achieve or what problem the checked-in, hardcoded version will cause.

jeffhandley · 2023-11-30T00:31:22Z

This migrates away from the FabricBot implementation of a scheduled search over closed issues and adopts the Locker GitHub action authored by the VS Code team.

The updated fabricbot.json was generated via dotnet/fabricbot-config#83. The workflow file was implemented and tested at https://github.com/dotnet/fabricbot-config/blob/main/.github/workflows/locker.yml.

Since this workflow uses the actions/checkout action, we need to ensure the following GitHub Actions settings are enabled:

Allow enterprise, and select non-enterprise, actions and reusable workflows
Allow actions created by GitHub

…/PRs

codecov · 2023-11-30T01:56:33Z

Codecov Report

Merging #6896 (bb86aa1) into main (d96d7b7) will decrease coverage by 0.01%.
The diff coverage is n/a.

Additional details and impacted files

@@ Coverage Diff @@## main #6896 +/- ##
==========================================
- Coverage 68.81% 68.80% -0.01% 
==========================================
Files 1240 1240 Lines 249397 249397 Branches 25496 25496 ==========================================
- Hits 171614 171596 -18 - Misses 71189 71203 +14 - Partials 6594 6598 +4

Flag	Coverage Δ
Debug	`68.80% <ø> (-0.01%)`	⬇️
production	`63.26% <ø> (-0.01%)`	⬇️
test	`88.49% <ø> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

see 4 files with indirect coverage changes

ericstj · 2023-11-30T18:32:02Z

+ with:
+ repository: "microsoft/vscode-github-triage-actions"
+ path: ./actions
+ ref: cd16cd2aad6ba2da74bb6c6f7293adddd579a90e


what's this hash and who updates it?

Seems like this refers to a commit here: microsoft/vscode-github-triage-actions@cd16cd2
I wonder why we use that instead of just tip of the stable branch?

Good question. Yes, it's the latest commit sha that affected the locker action from the repo. General guidance from GitHub, the VS Code team, and our own infrastructure folks are all aligned that when reusing actions from another repository (that you don't own), you should stick to a specific commit sha rather than a tag/branch. That ensures your repo always references a known state of the action.
Security hardening for GitHub Actions - GitHub Docs:
"Pin actions to a full length commit SHA"
https://github.com/microsoft/vscode-github-triage-actions/?tab=readme-ov-file#vs-codes-issue-triage-github-actions
"use the lastest released tag to ensure stability"
Except the repo stopped producing new release tags, and release tags don't follow the guidance above since tags can change their commit reference

And as far as who updates it: We would only want/need to update it if the locker action is updated to fix a bug or add a feature that we need. Otherwise, it should stay on this commit sha indefinitely.

My expectation would have been that we take latest, and then there is some bot (like dependabot) that would submit a PR to update it whenever latest changes. Can you file an issue in arcade or core-eng requesting that we have some sort of system for keeping these actions up to date?
Right now this feels like a checked in hardcoded version.

Having the checked-in, hardcoded version is the correct thing here, per core-eng and GitHub security guidance, so I'm not sure what such an issue would look to achieve or what problem the checked-in, hardcoded version will cause.

jeffhandley · 2023-11-30T00:31:22Z

This migrates away from the FabricBot implementation of a scheduled search over closed issues and adopts the Locker GitHub action authored by the VS Code team.

The updated fabricbot.json was generated via dotnet/fabricbot-config#83. The workflow file was implemented and tested at https://github.com/dotnet/fabricbot-config/blob/main/.github/workflows/locker.yml.

Since this workflow uses the actions/checkout action, we need to ensure the following GitHub Actions settings are enabled:

Allow enterprise, and select non-enterprise, actions and reusable workflows
Allow actions created by GitHub

…/PRs

codecov · 2023-11-30T01:56:33Z

Codecov Report

Merging #6896 (bb86aa1) into main (d96d7b7) will decrease coverage by 0.01%.
The diff coverage is n/a.

Additional details and impacted files

@@ Coverage Diff @@## main #6896 +/- ##
==========================================
- Coverage 68.81% 68.80% -0.01% 
==========================================
Files 1240 1240 Lines 249397 249397 Branches 25496 25496 ==========================================
- Hits 171614 171596 -18 - Misses 71189 71203 +14 - Partials 6594 6598 +4

Flag	Coverage Δ
Debug	`68.80% <ø> (-0.01%)`	⬇️
production	`63.26% <ø> (-0.01%)`	⬇️
test	`88.49% <ø> (ø)`

Flags with carried forward coverage won't be shown. Click here to find out more.

see 4 files with indirect coverage changes

ericstj · 2023-11-30T18:32:02Z

+ with:
+ repository: "microsoft/vscode-github-triage-actions"
+ path: ./actions
+ ref: cd16cd2aad6ba2da74bb6c6f7293adddd579a90e


what's this hash and who updates it?

Seems like this refers to a commit here: microsoft/vscode-github-triage-actions@cd16cd2
I wonder why we use that instead of just tip of the stable branch?

Good question. Yes, it's the latest commit sha that affected the locker action from the repo. General guidance from GitHub, the VS Code team, and our own infrastructure folks are all aligned that when reusing actions from another repository (that you don't own), you should stick to a specific commit sha rather than a tag/branch. That ensures your repo always references a known state of the action.
Security hardening for GitHub Actions - GitHub Docs:
"Pin actions to a full length commit SHA"
https://github.com/microsoft/vscode-github-triage-actions/?tab=readme-ov-file#vs-codes-issue-triage-github-actions
"use the lastest released tag to ensure stability"
Except the repo stopped producing new release tags, and release tags don't follow the guidance above since tags can change their commit reference

And as far as who updates it: We would only want/need to update it if the locker action is updated to fix a bug or add a feature that we need. Otherwise, it should stay on this commit sha indefinitely.

My expectation would have been that we take latest, and then there is some bot (like dependabot) that would submit a PR to update it whenever latest changes. Can you file an issue in arcade or core-eng requesting that we have some sort of system for keeping these actions up to date?
Right now this feels like a checked in hardcoded version.

Having the checked-in, hardcoded version is the correct thing here, per core-eng and GitHub security guidance, so I'm not sure what such an issue would look to achieve or what problem the checked-in, hardcoded version will cause.

Migrate to the 'locker' GitHub action for locking closed/stale issues…
bb86aa1
…/PRs

jeffhandley requested a review from ericstj November 30, 2023 00:31

ghost assigned jeffhandley Nov 30, 2023

michaelgsharp approved these changes Nov 30, 2023
View reviewed changes

ericstj reviewed Nov 30, 2023
View reviewed changes

jeffhandley merged commit 4223c27 into mainDec 1, 2023

jeffhandley deleted the jeffhandley/locker-action branch December 1, 2023 01:17

github-actionsBot locked and limited conversation to collaborators Jan 1, 2024

Migrate to the 'locker' GitHub action for locking closed/stale issues…
bb86aa1
…/PRs

jeffhandley requested a review from ericstj November 30, 2023 00:31

ghost assigned jeffhandley Nov 30, 2023

michaelgsharp approved these changes Nov 30, 2023
View reviewed changes

ericstj reviewed Nov 30, 2023
View reviewed changes

jeffhandley merged commit 4223c27 into mainDec 1, 2023

jeffhandley deleted the jeffhandley/locker-action branch December 1, 2023 01:17

github-actionsBot locked and limited conversation to collaborators Jan 1, 2024

Migrate to the 'locker' GitHub action for locking closed/stale issues…
bb86aa1
…/PRs

jeffhandley requested a review from ericstj November 30, 2023 00:31

ghost assigned jeffhandley Nov 30, 2023

michaelgsharp approved these changes Nov 30, 2023
View reviewed changes

ericstj reviewed Nov 30, 2023
View reviewed changes

jeffhandley merged commit 4223c27 into mainDec 1, 2023

jeffhandley deleted the jeffhandley/locker-action branch December 1, 2023 01:17

github-actionsBot locked and limited conversation to collaborators Jan 1, 2024

Migrate to the 'locker' GitHub action for locking closed/stale issues…
bb86aa1
…/PRs

jeffhandley requested a review from ericstj November 30, 2023 00:31

ghost assigned jeffhandley Nov 30, 2023

michaelgsharp approved these changes Nov 30, 2023
View reviewed changes

ericstj reviewed Nov 30, 2023
View reviewed changes

jeffhandley merged commit 4223c27 into mainDec 1, 2023

jeffhandley deleted the jeffhandley/locker-action branch December 1, 2023 01:17

github-actionsBot locked and limited conversation to collaborators Jan 1, 2024

Migrate to the 'locker' GitHub action for locking closed/stale issues…
bb86aa1
…/PRs

jeffhandley requested a review from ericstj November 30, 2023 00:31

ghost assigned jeffhandley Nov 30, 2023

michaelgsharp approved these changes Nov 30, 2023
View reviewed changes

ericstj reviewed Nov 30, 2023
View reviewed changes

jeffhandley merged commit 4223c27 into mainDec 1, 2023

jeffhandley deleted the jeffhandley/locker-action branch December 1, 2023 01:17

github-actionsBot locked and limited conversation to collaborators Jan 1, 2024

Migrate to the 'locker' GitHub action for locking closed/stale issues…
bb86aa1
…/PRs

jeffhandley requested a review from ericstj November 30, 2023 00:31

ghost assigned jeffhandley Nov 30, 2023

michaelgsharp approved these changes Nov 30, 2023
View reviewed changes

ericstj reviewed Nov 30, 2023
View reviewed changes

jeffhandley merged commit 4223c27 into mainDec 1, 2023

jeffhandley deleted the jeffhandley/locker-action branch December 1, 2023 01:17

github-actionsBot locked and limited conversation to collaborators Jan 1, 2024

Migrate to the 'locker' GitHub action for locking closed/stale issues…
bb86aa1
…/PRs

jeffhandley requested a review from ericstj November 30, 2023 00:31

ghost assigned jeffhandley Nov 30, 2023

michaelgsharp approved these changes Nov 30, 2023
View reviewed changes

ericstj reviewed Nov 30, 2023
View reviewed changes

jeffhandley merged commit 4223c27 into mainDec 1, 2023

jeffhandley deleted the jeffhandley/locker-action branch December 1, 2023 01:17

github-actionsBot locked and limited conversation to collaborators Jan 1, 2024

Migrate to the 'locker' GitHub action for locking closed/stale issues…
bb86aa1
…/PRs

jeffhandley requested a review from ericstj November 30, 2023 00:31

ghost assigned jeffhandley Nov 30, 2023

michaelgsharp approved these changes Nov 30, 2023
View reviewed changes

ericstj reviewed Nov 30, 2023
View reviewed changes

jeffhandley merged commit 4223c27 into mainDec 1, 2023

jeffhandley deleted the jeffhandley/locker-action branch December 1, 2023 01:17

github-actionsBot locked and limited conversation to collaborators Jan 1, 2024

Uh oh!

Conversation

jeffhandley commented Nov 30, 2023

Uh oh!

codecovBot commented Nov 30, 2023

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

jeffhandley commented Nov 30, 2023

Uh oh!

codecovBot commented Nov 30, 2023

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

jeffhandley commented Nov 30, 2023

Uh oh!

codecovBot commented Nov 30, 2023

Codecov Report

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!