Project

General

Profile

Actions

Feature #13891

closed

Migrate automated linting to GitHub Actions

Added by Boone Gorges about 3 years ago. Updated 11 months ago.

Status:
Resolved
Priority name:
Normal
Assignee:
Category name:
Internal Tools and Workflow
Target version:
Start date:
2021-01-26
Due date:
% Done:

0%

Estimated time:
Deployment actions:

Description

I'm currently paying monthly for Circle CI runs. It's possible we could do it free, or at least cheaper, on GitHub Actions.

Actions #1

Updated by Boone Gorges over 2 years ago

  • Target version changed from 1.19.0 to 2.0.0
Actions #2

Updated by Boone Gorges about 2 years ago

  • Assignee changed from Boone Gorges to Jeremy Felt

I'm hopeful that Jeremy knows how to do this :-D There'll be some technical issues (writing the necessary yaml files, setting up the actions on the GitHub side) as well as some bureaucratic ones (connecting a credit card to the GitHub account, etc). Please let me know if the latter issues get in the way of the former.

Actions #3

Updated by Boone Gorges almost 2 years ago

  • Target version changed from 2.0.0 to 2.1.0
Actions #4

Updated by Jeremy Felt over 1 year ago

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.

Actions #5

Updated by Boone Gorges over 1 year ago

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.

Actions #6

Updated by Matt Gold over 1 year ago

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

Actions #7

Updated by Matt Gold over 1 year ago

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?

Actions #8

Updated by Boone Gorges over 1 year ago

Those four seem correct to me, Matt.

Actions #9

Updated by Matt Gold over 1 year ago

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?

Actions #10

Updated by Boone Gorges over 1 year ago

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

Actions #11

Updated by Raymond Hoh over 1 year ago

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.

More info about downgrading our legacy account to the free organizations one can be found here:

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

Actions #12

Updated by Boone Gorges over 1 year ago

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.

Actions #14

Updated by Boone Gorges over 1 year ago

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.

Actions #15

Updated by Boone Gorges over 1 year ago

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.

Actions #16

Updated by Jeremy Felt over 1 year ago

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

Actions #17

Updated by Boone Gorges over 1 year ago

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

Actions #18

Updated by Jeremy Felt over 1 year ago

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
Actions #19

Updated by Boone Gorges over 1 year ago

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.

Actions #20

Updated by Jeremy Felt about 1 year ago

More info on each:

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

Actions #21

Updated by Jeremy Felt about 1 year ago

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

Hotfixes applied: We've heard back on both of the reported hotfixes:
  • 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.

Actions #22

Updated by Raymond Hoh about 1 year ago

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!

Actions #23

Updated by Boone Gorges about 1 year ago

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.

Actions #24

Updated by Jeremy Felt about 1 year ago

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.

Actions #25

Updated by Boone Gorges about 1 year ago

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?

Actions #26

Updated by Boone Gorges about 1 year ago

  • Target version changed from 2.1.0 to 2.2.0

I think this is mostly done, but I will keep the ticket open so that we can tie up loose ends.

Actions #27

Updated by Boone Gorges 11 months ago

  • Status changed from New to Resolved

Running smoothly on GitHub Actions. Thanks for your work, Jeremy!

Actions

Also available in: Atom PDF