Merging our two projects

[mskelton]

Hello folks! I just saw your comment on my wait-for-vercel-action repo about this project you created. First of all, great work on improving on the idea with this new project!

I wanted to open up a discussion to see if you have any interest in trying to merge our projects in some fashion. I'm generally not a huge fan of lots of projects that accomplish the same goal as it makes it harder for users to know what to use and it also makes it difficult for contributors as they have to pick and choose a project rather than aligning as a community on the best available solution.

I really like the improvements you've made in this repo especially when it comes to your really awesome README which does a great job of explaining the purpose of this action. Would you be opposed to discussing ways to combine our two projects in some way?

[Vadorequest]

Hello @mskelton, thanks for your interest!

Our vision is to provide a production-grade action, which is very reliable, heavily tested, and maintained.

Our short-term goal is to use this action in another OSS repository, it's a WIP and it works as-it. We also plan to show "real-world use cases" by using this project as an example (in the readme).

I wanted to open up a discussion to see if you have any interest in trying to merge our projects in some fashion. I'm generally not a huge fan of lots of projects that accomplish the same goal as it makes it harder for users to know what to use and it also makes it difficult for contributors as they have to pick and choose a project rather than aligning as a community on the best available solution.

I completely agree with you. It would make more sense if there were only one of such tool, considering how small the range of features is.

I really like the improvements you've made in this repo especially when it comes to your really awesome README which does a great job of explaining the purpose of this action. Would you be opposed to discussing ways to combine our two projects in some way?

We aren't opposed, but we are careful. We saw your action first and tried it, and it didn't work well (I'm not the one who tested it and don't remember why, but it didn't). Also, I noticed a few flaws in your "algorithm" which were similar to what we had done, such as:

• Reading many deployments and taking the latest, doesn't always work, and can be terribly bad when pushing multiple commits on the same repo/branch.
• No TS, no tests

Overall, we didn't really feel confident using your action, and we thought about collaborating to your project, but the differences would be so huge (adding TS, Jest, babel, tests, etc.) and I know by experience such a PR would be hard to merge and take a long time. So, we decided to take a shortcut and build something from scratch.

Now that it's done and everyone can see the benefits, I'm inclined to accept external contributions in order to widen our features. Is that what you had in mind?

By comparing both projects, I'd say the only feature we're missing might be related to await-build, but I'm not sure what it does exactly. 🤔 (let me know if I'm mistaken!)

I had a few ideas of potential features to add to our current implementation:

• Automatically set meta tags, like the GitHub commit hash/branch source
• Not necessarily wait for a READY status, but maybe for any status in particular (READY being the default)

Those two features would allow more use-cases.

[Vadorequest]

So, that is one interesting feature to have, to wait at least for BUILDING before considering the provided timeout. Might make sense, for people who use the action right after having triggered the Vercel deployment, as they won't know how much time it might be QUEUED and how long the BUILD phase will take.

That's not our use-case, but that's definitely something we might cover.

[Demmonius]

Yes I agree but I was wondering how you can get the deployment URL before the build?

[Vadorequest]

Good point. I don't see how that's possible either, since Vercel dynamically creates the build ID that's used in the deployment domain. 🤔

Based on that assumption, one can only call our action once the build has finished.

@mskelton For what reasons/use-cases did you implement the await-build option?

[mskelton]

The await-build paramater was added in this PR: mskelton/wait-for-vercel-action#4. I'm honestly not entirely sure when it would be used as I no longer use the action myself as I use a different method for my e2e tests now.

Seems like the await-build should probably be the default though, so if that is how you have yours setup there probably isn't a need for the non await-build functionality.

[Vadorequest]

Yeah, by reading https://github.com/mskelton/wait-for-vercel-action/pull/4/files I don't really understand the intention behind the code. I'd say it would break things if we were to integrate such a change.

[mskelton]

So, just an idea I had and not sure if you are interested in it, but one way to help "merge" the projects to some degree would be if I was to delist my action from the marketplace and let you guys take over the name with your action making it a v2 or something like that. Then we could make a migration guide and I could eventually archive my repo. Not sure if you are interested in doing this, but just a thought.

[Vadorequest]

Yeah, sure, we can do something like that.

I'm not sure what happens if you "delist" (unpublish?) your action (is that even possible?), but one thing that can be done without breaking anybody's CI would be to deprecate it and point toward this action/repo. And then, later on, remove it on the marketplace.

Are there things you wish to change in this repo? (doc, implementation, features...)
Do you want to become a contributor/maintainer? I believe not since you don't seem to have a need for it "I no longer use the action myself".

---

I opened https://stackoverflow.com/questions/65319710/how-does-unpublishing-a-github-action-from-the-marketplace-works-is-it-possib because I wasn't sure how unpublishing a github action from the marketplace works.

[mskelton]

I'm not sure what happens if you "delist" (unpublish?) your action (is that even possible?), but one thing that can be done without breaking anybody's CI would be to deprecate it and point toward this action/repo. And then, later on, remove it on the marketplace.

I assume it wouldn't break anything since my repo would exist and like you commented in your stack overflow question, the marketplace entry is just to make it easier to find actions.

Are there things you wish to change in this repo? (doc, implementation, features...)

Not that I can think of right now, it looks really good!

Do you want to become a contributor/maintainer? I believe not since you don't seem to have a need for it "I no longer use the action myself".

Not at the moment. I'll definitely keep my eye on this project to see what future improvements and changes you guys come up with, and if I happen to do a lot more with Vercel down the road I'll let you know at that point if I'm interested in helping maintain this.

[Vadorequest]

Yes indeed, it wouldn't break anything because it's the GitHub repo that matters, not the Marketplace.

I wrote UnlyEd/next-right-now#223 to discuss security more in-depth.

So, I guess you can just mention this GitHub action on your repo, and add a notice about you won't maintain yours, and I guess that's it?

[mskelton]

Just updated my repo with a note to encourage new users not to use mine in favor of this one. I also delisted it from the marketplace, so if you do want to rename the action and use the marketplace listing, feel free to do so.

[Vadorequest]

@mskelton FYI See #8 where someone using your action tried to switch to ours but was faced with a different behaviour. At first glance, I feel like we might have overlooked some feature your action provides and ours doesn't?