Skip to content

Fix #8: Add public API#34

Merged
danepowell merged 12 commits into
consolidation:mainfrom
danepowell:issue-8
Aug 27, 2024
Merged

Fix #8: Add public API#34
danepowell merged 12 commits into
consolidation:mainfrom
danepowell:issue-8

Conversation

@danepowell

@danepowell danepowell commented Jul 24, 2024

Copy link
Copy Markdown
Collaborator

@danepowell danepowell marked this pull request as draft July 24, 2024 21:32
@danepowell

Copy link
Copy Markdown
Collaborator Author

This works but I'm thinking we should actually cache the network request like in ACLI rather than just caching the response: https://github.com/acquia/cli/blob/main/src/Command/CommandBase.php#L1262

@danepowell

Copy link
Copy Markdown
Collaborator Author

@greg-1-anderson I need your input on how to handle caching.

I see Terminus has a hardcoded wait of 7 days between update checks: https://github.com/pantheon-systems/terminus/blob/3.x/src/Update/LatestRelease.php

ACLI on the other hand uses a Guzzle cache middleware which respects the max-age on the GitHub API response (typically 60 seconds): https://github.com/acquia/cli/blob/main/src/Command/CommandBase.php#L1262

In my ideal world, the actual time between update checks is ~24 hours. But I really like the idea of using a bog-standard HTTP cache in the self-update library rather than all consumers (ACLI, Terminus) having to hardcode their own update interval.

What would you prefer?

@danepowell

Copy link
Copy Markdown
Collaborator Author

I've decided to cache the GitHub response in the self-update library using symfony/cache; downstream projects can decide to implement polling periods however they'd like.

Comment thread src/SelfUpdateManager.php Outdated
@greg-1-anderson

Copy link
Copy Markdown
Member

A downstream library would need to construct the SelfUpdateManager with all the same parameters already passed to the SelfUpdateCommand

Regarding this question, I would recommend making a breaking change, and pass the SelfUpdateManager in to the constructor of the SelfUpdateCommand. The Front Controller would then create both of those objects, and the SelfUpdateManager can be cached / managed as needed for later automated use.

I don't have a strong opinion on caching. It would be good to have some level of configurability, with reasonable defaults provided.

@danepowell

danepowell commented Aug 8, 2024

Copy link
Copy Markdown
Collaborator Author

Thanks, I was just finishing this up as you commented. It's ready for review.

I took a similar approach, basically providing a method to get the manager from the command, to keep things backwards compatible. It feels a little dirty but I can't think of any practical reason not to do it.

Edit: actually, forcing downstream projects to build their own selfupdatemanager would make it easier to mock self-update checks without mocking the entire self-update command. I'm not sure if that's something you worry about in Terminus?

@danepowell danepowell marked this pull request as ready for review August 8, 2024 21:00
@greg-1-anderson

Copy link
Copy Markdown
Member

I'd really prefer to break b/c for this, and make a new major version. I'll +1 this as-is if you really need b/c for some reason in one of your client projects.

@greg-1-anderson

Copy link
Copy Markdown
Member

Also, you could mostly (maybe completely) preserve b/c if you made constructor parameters optional. Add SelfUpdateManager last, and instantiate one in the constructor if it's not provided. Some of the existing parameters of the constructor would have to become optional; the constructor should fail if a parameter that is subsumed by the self update manager is not null. Maybe that would be the best of both worlds? Then we could later make a new major version that removed the optional constructor parameters and made the self update manager required.

@danepowell danepowell removed the request for review from greg-1-anderson August 12, 2024 15:07
@danepowell danepowell marked this pull request as draft August 12, 2024 15:07
@danepowell

Copy link
Copy Markdown
Collaborator Author

I don't mind the BC break, I just want to do what's easiest, which is definitely not trying to support a bunch of optional arguments 😄

I refactored this to take the SelfUpdateManager as the only constructor parameter. It works pretty well, I've even got it working with autowiring in Acquia CLI so you don't have to actually hang onto the SelfUpdateManager in a client application. I still need to get tests working there, but I think it'll be fine.

Tests will pass here with consolidation/self-update-fixture#4

Comment thread src/SelfUpdateCommand.php Outdated
@danepowell danepowell marked this pull request as ready for review August 14, 2024 21:08
@danepowell

Copy link
Copy Markdown
Collaborator Author

@greg-1-anderson I'd appreciate a review this week if you're able. Tests should pass once we merge consolidation/self-update-fixture#4

@danepowell danepowell mentioned this pull request Aug 21, 2024
@lyrixx lyrixx mentioned this pull request Aug 22, 2024
6 tasks
@danepowell

danepowell commented Aug 27, 2024

Copy link
Copy Markdown
Collaborator Author

I'm going to merge this so we can close out the ongoing work and prevent merge conflicts, but I'll hold off on cutting a major release until I get your approval, and we can of course still make any changes you'd like.

Alpha (pre)release: https://github.com/consolidation/self-update/releases/tag/3.0.0-alpha1

@danepowell danepowell merged commit 3476c5e into consolidation:main Aug 27, 2024
@lyrixx

lyrixx commented Oct 28, 2024

Copy link
Copy Markdown

Are we ready for the final 3.0 ?

@danepowell

Copy link
Copy Markdown
Collaborator Author

I'm fine with a 3.0.0 release but I want to give @greg-1-anderson a chance to approve (or at least veto 😄 ) it

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Add public methods to get latest version and check if phar is up to date

3 participants