Add "Enable Pack Build and Test" Workflow

[mamercad]

Add a Workflow which ensure that the "Build and Test" Workflows are enabled in all of StackStorm-Exchange; GitHub will disable all Workflows in a repository if 60d have gone by without activity; fixes #136.

[arm4b]

From the https://github.com/StackStorm-Exchange/index/pull/27#issuecomment-1354073870

I wonder if it would make more sense to schedule this workflow on https://github.com/StackStorm-Exchange/ci instead of on the index. The current workflow in this repo only has write access to the index repo, and nothing else. I think I'd like to keep it that way.

@cognifloyd @mamercad I think the corner case here is that this repository GH Workflows can expire the same way as packs, making this workflow non-running after the 60 days.

With that, the difference between this repo and Index (https://github.com/StackStorm-Exchange/index/) is that Index repo CI won't expire due to daily automated commits.

:thinking:

[mamercad]

From the StackStorm-Exchange/index#27 (comment)

I wonder if it would make more sense to schedule this workflow on https://github.com/StackStorm-Exchange/ci instead of on the index. The current workflow in this repo only has write access to the index repo, and nothing else. I think I'd like to keep it that way.

@cognifloyd @mamercad I think the corner case here is that this repository GH Workflows can expire the same way as packs, making this workflow non-running after the 60 days.

With that, the difference between this repo and Index (https://github.com/StackStorm-Exchange/index/) is that Index repo CI won't expire due to daily automated commits.

🤔

Ah yes, thinking... we found the "zero point" 😄

[mamercad]

Looking good. Next time I have a moment I will make the PAT.

Does the user who makes the PAT need to be an admin? If not, I'll use the stackstorm-neptr bot account.

I don't think it does.

[mamercad]

Looking good. Next time I have a moment I will make the PAT. Does the user who makes the PAT need to be an admin? If not, I'll use the stackstorm-neptr bot account.

I don't think it does.

Also, let me know if/when you're ready to merge this, I can rebase it beforehand.

[cognifloyd]

@mamercad looks like there are some gotchas with the workflow. Could you take a look? I suspect we need to just change the working directory, or specify the repo on the command line: https://github.com/StackStorm-Exchange/ci/actions/runs/3737834951/jobs/6343366911

[mamercad]

@mamercad looks like there are some gotchas with the workflow. Could you take a look? I suspect we need to just change the working directory, or specify the repo on the command line: https://github.com/StackStorm-Exchange/ci/actions/runs/3737834951/jobs/6343366911

Surely; the first thing that I've noticed is that it looks like this is a thing we're going to run into (I can reproduce it in my fork):

❯ gh workflow list --repo mamercad/stackstorm-exchange-ci      
Enable Pack Build and Test  active  43546553
CI - Build and Test         active  43398038
Test                        active  43324335

❯ gh workflow enable "Enable Pack Build and Test" --repo mamercad/stackstorm-exchange-ci
could not find any workflows named Enable Pack Build and Test

❯ gh workflow disable "Enable Pack Build and Test" --repo mamercad/stackstorm-exchange-ci
✓ Disabled Enable Pack Build and Test

❯ gh workflow enable "Enable Pack Build and Test" --repo mamercad/stackstorm-exchange-ci
✓ Enabled Enable Pack Build and Test

The second command there is problematic if the workflow is already enabled since it exits nonzero:

❯ gh workflow enable "Enable Pack Build and Test" --repo mamercad/stackstorm-exchange-ci; echo $?
could not find any workflows named Enable Pack Build and Test
1

[cognifloyd]

Doh! Then I guess we do need an is-not-active check. Bummer.

Hmm. That check is baked into the gh client, so maybe the API won't have the same gotcha. So, we could also try using gh api .../enable instead of gh workflow enable.

I'm fine either way. Wdyt?

[mamercad]

Doh! Then I guess we do need an is-not-active check. Bummer.

Hmm. That check is baked into the gh client, so maybe the API won't have the same gotcha. So, we could also try using gh api .../enable instead of gh workflow enable.

I'm fine either way. Wdyt?

Yeah, that's a good thought, I'll iterate in the PR.