Skip to content
This repository has been archived by the owner on Jun 5, 2024. It is now read-only.

Add Version Check for third-party providers #7

Merged
merged 5 commits into from
Apr 22, 2022
Merged

Conversation

guineveresaenger
Copy link
Contributor

@guineveresaenger guineveresaenger commented Apr 20, 2022

Create pkgversion command to verify an upstream version change. The command requires an owner and a repo input and will query both the package version as listed on their latest release, as well as check the metadata file in pulumi/registry.

The command will print an updated release version if there's a version difference between the latest release and the registry version. It will print nothing if they're the same.

This is a very basic, no-frills functionality and I'm almost certain we'll need to expand on it.

I'm also happy to hear thoughts about naming this command differently.

Part of pulumi/registry#853

Copy link
Contributor

@jkisk jkisk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is looking great, could we adjust it though to return a version string if any difference and an empty string if there is not, along with an error?

@stack72
Copy link
Contributor

stack72 commented Apr 20, 2022

Is there any reason why if there's a newer version that we wouldn't use the info and just regenerate the yaml file rather than needing to parse the output and then run a second command?

@jkisk
Copy link
Contributor

jkisk commented Apr 20, 2022

Is there any reason why if there's a newer version that we wouldn't use the info and just regenerate the yaml file rather than needing to parse the output and then run a second command?

Oh I guess no particular reason, other than I had already written it the other way, that works! It does make it less straightforward to do more logic in the action though, such as limit updates to a provider to a certain amount per month or something. I like functions to have less complexity where possible, and the other command is already written.

@guineveresaenger
Copy link
Contributor Author

I'm with Paul here - regenerating the metadata file makes sense to me, we can write it to the environment and run the update.

Are we concerned with bad actors hammering our action usage?

@stack72
Copy link
Contributor

stack72 commented Apr 20, 2022

this is going to happen on a cron - we should not have to parse output as input to another action IMO

@guineveresaenger
Copy link
Contributor Author

Since the metadata command is doing more that just rewriting the metadata file (which I thought was its only purpose yesterday), I changed this back to just emit the version string. That way we can generate the metadata with the tried and proven command.

Copy link
Contributor

@stack72 stack72 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's ship this - we can refactor later if we decide that we need to combine the calls

@stack72 stack72 merged commit 086bc29 into master Apr 22, 2022
@stack72 stack72 deleted the versioncheck branch April 22, 2022 19:09
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants