alleyinteractive / .github Goto Github PK

Description

I would like to see the default version of PHP used on the reusable workflows in this project default to 8.1. Currently, they're defaulting to 8.0. We can time this with the push for 8.1 this year and merge it before the end of security updates for 8.0 this November.

This would cause any project that doesn't have a PHP version specified to be upgraded to 8.1.

Use Case

When using the reusable workflows in this repository, the default PHP version should be 8.1.

Description

When creating a built release, the notes generated don't take into account the previous version but all commits.

https://github.com/alleyinteractive/.github/blob/main/.github/workflows/built-release.yml#L161-L163

Use Case

Here is an example: https://github.com/alleyinteractive/wp-curate/releases/tag/v1.4.1

I'd expect see only the notes since 1.4.0, not since the first pull request was merged.

Description of the documentation inaccuracy

The current version of CONTRIBUTING.md includes a lot about our philosophy of creating and naming things, but not as much detail as it could about the mechanics of contributing to a specific repo. The contributing guide is linked from repos that don't have their own, so we should add some additional generic info on how to contribute (like pull request workflow, etc). See, for example, https://github.com/alleyinteractive/create-wordpress-project/blob/develop/CONTRIBUTING.md for what this could include. Any links to specific projects should be removed. The resulting documentation should be able to be used for any of our projects.

Additional Information

No response

Description

I would like to see Memcache available for the https://github.com/alleyinteractive/.github?tab=readme-ov-file#php-tests-with-mysql workflow.

Use Case

Running unit tests with Memcache

Add Composer caching to the Unit Test and Coding Standards workflows.

Please consider prefixing file names of reusable (workflow_call:) workflows with reusable-

Currently, the "Push to -built branch" job only shows file additions and deletions, which is less helpful than it could be. For the sake of troubleshooting, this job should show all file changes being pushed to the built branch. e.g. add git status before the commit.

Description of the bug

In this repository, the three issue templates supply prefixes to new issue titles:

• [BUG]:
• [DOCS]:
• [FEATURE]:

Now that I've seen some issues hit our repositories with these templates, I've found these prefixes a little difficult to read, for a few reasons:

• Issues are already being assigned a label based on the issue type. Why does the type need to also be in the title?
• Since the issue types in brackets function more as metadata, not prose, I don't think the colon after the brackets serves a purpose. A colon introduces text, but with the brackets, there's nothing before the colon to do the introducing. BUG: or [BUG] makes sense to me, but not [BUG]:.
• If the types need to be in the title, do they have to be IN ALL CAPS? 😱

I'm curious to know whether repo maintainers find value in having the type in the title, and, if so, whether we could tone down the type to [Bug], [Docs], and [Feature]. Otherwise, I would hope we could remove the prefixes from the titles and lean on the labels to provide that metadata.

Steps To Reproduce

1. Open an issue in one of Alley's repositories.
2. Observe that the issue title has a prefix in all caps, a questionable colon after the prefix, and an identical label 😆

Additional Information

No response

Description of the bug

If the plugin does not have a .deployignore file, the action fails:

mv: cannot stat '.deployignore': No such file or directory

Example: https://github.com/alleyinteractive/byline-manager/actions/runs/5296076805/jobs/9586941269

Steps To Reproduce

Use the action in a plugin without a .deployignore file.

Additional Information

No response

Essentially, moving and creating a workflow that's flexible and can be used in Alley open source projects.

Examples:

• https://github.com/alleyinteractive/mantle-framework/blob/main/.github/workflows/update-changelog.yml
• https://github.com/alleyinteractive/wp-concurrent-remote-requests/blob/main/.github/workflows/update-changelog.yml

Description of the bug

When actions/cache was upgraded to v4 it broke tests on Mantle for an unknown reason.

Upgraded in #70 but immediately started breaking tests. I re-ran alleyinteractive/mantle-framework#496 in between upgrading and downgrading it to ensure it was actions/cache.

Steps To Reproduce

https://github.com/alleyinteractive/mantle-framework/actions/runs/7980743349/job/21791054693

Additional Information

No response

Description

I would like to be able to use code.alley.com as a domain for Alley's GitHub pages.

Use Case

When a GitHub page is created for a repository under alleyinteractive it should live on the code.alley.com subdomain.

Description

Currently, the phpunit tests don't install either memcache or redis, and therefore tests are run without a persistent object cache present. Ideally, we would have a configuration available to let us specify which caching engine we are using and how we are integrating with it (e.g., object-cache.php present in repo vs. needing to be copied from elsewhere). This would support testing against VIP environments and Pantheon environments.

Use Case

When a user uses this action, they should be able to configure it to use the persistent object cache provider of their choice.

Description

I would like our new default labels to be applied to all of our open source repositories plus any non-client private repos that we have (e.g., broadway, production-docs).

• For labels that don't exist, create the label and apply the same description and color that are in use in the default labels list.
• For labels that do exist, apply the description and color from the default labels list, if it differs from what is defined in the repo.

Use Case

As a member of the technology department, I want to be able to use consistent labeling on issues when preparing items for the tech department priorities board.

Description

I would like to be able control the MySQL version used in the php-tests.yml workflow OR disable it entirely.

Use Case

When testing with SQLite, I want to be able to disable the use of the database.

Description

This code is doing nothing to remove the files from the -built tag/branch:

Use Case

As titled.