CUNY Academic Commons

I've wired up an initial attempt at using GitHub actions for the PHPCS and linting checks and got this message from GitHub:

The job was not started because recent account payments have failed or your spending limit needs to be increased. Please check the 'Billing & plans' section in your settings.

It may be that a credit card needs to be updated/attached for things to start working.

Once that's set, we'll have either 2000 or 3000 free minutes to work with. There is a rate of $0.008 per minute once we go over that. We should be able to calculate pretty closely what to expect once we get a few runs in to see how long the workflow takes.

Matt, it appears that we'll have to migrate off of our "legacy" 300/yr organization account. Instead, we'll need to move to something like the "Team" account https://github.com/pricing. But this will mean a change in the structure of the billing, and I want to check with you first because it appears that a GC credit card is attached to the account. Annual bills are likely to be around $300 (maybe a bit lower) after the change.

Hi Boone -- I've just added my personal credit card. How many members do we need on the team?

also -- there are currently 24 members on our "team." In order to upgrade to a team plan, I think I need to remove most everyone or have to pay for them. I assume that Boone, Ray, Jeremy, and CAC Release Manager should stay. Anyone else?

Those four seem correct to me, Matt.

Hmmm. . .I'm noticing some City tech people on the team, like Jenna, Charlie, and George Mamadashvili -- presumably for the CBOX OpenLab project Do they need access to the repository?

I'm struggling somewhat to understand what counts as a "user" for billing purposes. Here's GitHub's documentation: https://docs.github.com/en/billing/managing-billing-for-your-github-account/about-per-user-pricing The meaningful distinction seems to be between public and private repos.

- Our private repos are listed here https://github.com/orgs/cuny-academic-commons/repositories?q=&type=private&language=&sort= For these, it would be sufficient for me, Ray, and Jeremy to be users, as we're the only ones contributing code.
- We have many more public repos, including the commons-in-a-box repos. Charlie, Jenna, and Bree need to be able to manage issues and have issues assigned to them. It's unclear to me whether this requires them to be paid users.

Jeremy, Ray, do you have any idea about this?

At worst, I think it would be safe to prune membership (for the purposes of billing) to: me, Ray, Jeremy, CAC Release Manager, Bree, Jenna, Charlie

Jeremy, Ray, do you have any idea about this?

Boone, I think you have an accurate interpretation of the per-user billing system.

Was just looking at the different offerings by GitHub, but couldn't we switch our legacy account to a GitHub Free for Organizations account? https://docs.github.com/en/get-started/learning-about-github/githubs-products#github-free-for-organizations

At this tier, we would get up to 2,000 GitHub Actions minutes per month. Whereas the tier we are looking to pay for -- Github Team -- gives you 3,000 minutes.

At the Free Organizations tier, we also lose some additional features for private repos that we currently use. The most pertinent being Wikis and Repository Insights graphs (Pulse, contributors, traffic, commits, code frequency, network, and forks). We currently use the Wiki to document our Git and release workflow, however we could easily create a new repo to house this info as well. Repository Insights are nice for historical purposes, but isn't really imperative.

• https://docs.github.com/en/get-started/learning-about-github/faq-about-changes-to-githubs-plans#if-i-downgrade-from-github-team-or-a-legacy-plan-to-github-free-what-features-will-i-lose
• https://docs.github.com/en/billing/managing-billing-for-your-github-account/downgrading-your-github-subscription#downgrading-an-organizations-subscription-with-legacy-per-repository-pricing

I believe we do not lose much from switching to the Free Organizations tier, unless I'm misinterpreting something from the different tiers.

Thanks for this, Ray. I think it's worth trying the Free level to see if it does what we need it to do. We can always bump it up later if necessary. Matt, does that sound OK to you? We'll probably still need a CC on file in case of Actions overages, but there should be no recurring cost.

As you note, we use the Wiki for very little. I've just taken a local clone of the wiki for historical purposes, and we can set up a new "action required" workflow when/if we decide to make the change.

Matt, can you try downgrading our legacy Github account to the free plan as per the instructions listed here: https://docs.github.com/en/billing/managing-billing-for-your-github-account/downgrading-your-github-subscription#downgrading-an-organizations-subscription-with-legacy-per-repository-pricing

Hi all - It looks like our account has finally been migrated over, and actions are running!

I'm struggling a bit to get the entire thing to get the 'deploy' task to finish. Actions are having a hard time with private submodules. I've made some changes in the branch to try to account for it, but it's still not working. Jeremy, would you mind taking a further look? I've made you an Admin of the two private repos in question, in case you need to mess with deploy keys and secrets. I'll also email you the SSH keys I generated for the purpose of this bot.

If we need to make the submodules public and switch to https:// instead of SSH submodules, we can do it - there's no real reason why these repos need to be private. But it'd be a good thing to figure out in case there comes a time when we do legitimately need a private submodule.

I've made you an Admin of the two private repos in question, in case you need to mess with deploy keys and secrets.

Thanks Boone! I think I also need admin access to the CAC repo itself so that I can add a personal access token as a secret. It should then have privileges to see those other private repositories. This process worked for one of our other composer-based configs, so it at least sounds right to me. :)

Once all of this is working, it may be worth setting up a CUNY bot account on GitHub to attach a personal access token to that isn't an individual user account.

Related: https://github.com/actions/checkout/issues/35

Thanks, Jeremy! I've added you as an admin to cuny-academic-commons/cac.

We're getting close! The PHPCS action is completing (in 20 minutes vs 1 hour), though there are a few discrepancies in the errors caught by GitHub vs CircleCI. These all seem valid, and the output on my local environment matches the output from GitHub, so it seems right to fix them.

Errors that likely need (hot-)fixing:

• Geo Mashup, php/Hooks/Base.php:16, `$this` can no longer be unset since PHP 7.1
• Leaflet Maps Marker, leaflet-marker.php:829 and leaflet-tools.php:716, unparenthesized expression containing a "." before a "+" or "-"
• Newsletters Lite, vendors/processing/wp-background-process.php:63, $this can no longer be used with the global keyword
• Make, functions.php:385, "$this" can no longer be used in a plain function or method since PHP 7.1

These seem like candidates for ignoring via PHPCS config:

• Event Tickets, src/Tickets/Commerce/Gateways/PayPal/Client.php:248, func_get_args() now returns the current rather than original value of $method
• The Events Calendar, src/Tribe/Views/V2/Repository/Event_Period.php:145, func_get_args() now returns the current rather than original value of $key

Thank you, Jeremy! I've looked through your list and your judgment looks right on all of these. In each case, could you take a couple minutes to see if there's a wordpress.org support thread (or better, a GitHub ticket) reporting the issue? In my experience, very few plugin authors will actually fix these kinds of things based on our requests, but still, I feel better knowing that I've at least tried.

But yet, please go ahead and fix them directly in the branch. To make life easier for me, would you please do it in the 2.0.x branch? There'll be at least one more 2.0.x release, and I don't want to deal with merge conflicts if these plugins are updated in 2.0.x but the PHP fix is only in 2.1.x.

More info on each:

• Geo Mashup is a non-issue, the unset occurs on an array of objects, of which one may be referenced view `$this`. I've added that to the ignore list.
• Leaflet Maps Marker: https://wordpress.org/support/topic/php-8-0-error-using-an-unparenthesized-expression/#new-topic-0
• Newsletter Lite is actually a non-issue and can be ignored, short gist here: https://gist.github.com/jeremyfelt/16d732f642df130c5a674b82e9d6f4c4
• Make: email sent to report the issue (they do not monitor the support forums)

I have the hotfixes made locally and tests are passing. I'll get that sorted on branches today.

Things are looking good here. PHPCS and PHP linting checks are running in GitHub actions (and CircleCI) on the 2.0.x branch.

• Leaflet Maps Marker https://github.com/cuny-academic-commons/cac/commit/06a59135660a3da99bb61bc72b26aaf71f2b05d5
• Make https://github.com/cuny-academic-commons/cac/commit/42a1b1a9ed28aff6cc726747da3b8c6d4da81b22
• Exclusions https://github.com/cuny-academic-commons/cac/commit/9871334403a78a46d7a75d578c0bd0262a1acd5a

• Leaflet Maps Marker confirmed the plugin is generally EOL, but also patched the currently released version for future downloads.
• Make (The Theme Foundry) is patching the bug and will push in their next minor release.

I also scratched an itch and ended up with the fix/run-parallel-linting branch, which:

• Uses the very cool PHP Parallel Lint to lint files in parallel processes. This sped up the linting task significantly.
• Applies a rudimentary jobs system to the PHPCS script so that scans can be run in parallel. This has sped up the PHPCS task significantly, especially locally.
• Fixes a bug in which the wp-content/object-cache directory was not actually being scanned by PHPCS because it had no subdirectories.

This branch's GitHub actions are taking ~15 minutes total, which is fun to see after the previous CircleCI times. (Also worth noting that CircleCI sped up significantly as well once things started running in parallel).

Boone - if nothing in that list sounds scary, I'm happy to merge to 2.0.x. And I think we're in a place where I/we can remove the CircleCI config at any point.

Uses the very cool PHP Parallel Lint to lint files in parallel processes. This sped up the linting task significantly.

That sounds awesome, Jeremy! Thanks for your work on this!

Love it! I didn't know about parallel processing for PHPCS. Merge at your leisure. Once it's been running for a week or two, I will disconnect CircleCI.

This has been merged to the 2.0.x branch and both the PHPCS and PHP lint tasks are passing.

A caveat... :)

When I used the default GitHub auth token OR the `DEPLOY_SSH_KEY` secret, the https://github.com/cuny-academic-commons/cac-onboarding/ and https://github.com/cuny-academic-commons/cac-suggestions/ repositories cannot be found.

The default GitHub auth token is scoped to the CAC repository and does not have read access to CAC Onboarding or CAC Suggestions. This appears to be the case for `DEPLOY_SSH_KEY` as well, but I'm less confident on that.

For now: I generated a personal access token and added it as the `REPO_ACCESS_TOKEN` secret to the CAC repository.

Long term: the DEPLOY_SSH_KEY should be updated, if possible, to something that has full access.

Thanks, Jeremy. When I go the 'Actions secrets' settings panel in GH, it tells me:

Organization secrets can only be used by public repositories on your plan.

If you would like to use organization secrets in a private repository, you will need to upgrade your plan.

I assume that this means that we can't have non-personal deploy keys that can reach across the organization's repos. Does that track with your reading?