> Pipelines are sequence of GitHub Actions workflows, executed in order, waiting for successful execution of each workflow before processing to next workflow execution

Isn't that exactly what an action already does? A lot of the features in the boxes below the fold also sound like things you get out of the box on GH. Triggering on push for example, that's probably how at least 90% of GH actions are run. I suggest you emphasize the parts that are actually novel, because the home page doesn't convey it at all.

Also I know it's crazy nitpicky and certainly not unique to pippy.dev but I always want to click on those feature boxes for more info. They just look like interactive things, and it's unsatisfying when they're not.

Thank you for the feedback. Agree that most of the features are offered as https://docs.github.com/en/actions/deployment/targeting-diff..., unfortunately i haven't played with it. Will improve the landing page to focus on the pieces different from what is offered by Github.

>but I always want to click on those feature boxes for more info

Sorry about that, will work on not using cards :( I do not have much design/UI experience, and the lack of it shows here.

came here to ask the same question

Your home page mostly focuses on stuff that I thought GitHub already provides. How do features like block for approval, locks, etc differ from the built in capabilities native to GitHub actions? We have a “service deploy” workflow that pauses for approval after preparing the deploy but before it’s installed on the cluster using stock actions. We also “lock” deploys without third party stuff. When it comes to “cloud api”, GitHub has an API for triggering action runs too.

Here on HN you focus on monitor + rollback after deploy, which is more of a differentiator.

(I didn’t watch the video)

If you are referring to https://docs.github.com/en/actions/deployment/targeting-diff..., unfortunately i haven't played with it, and agree that it does offer most of the features offered by the product. As you mentioned the differentiator is the automatic rollback and support for external monitoring (datadog as of now). Would love to learn more about how you are using Github actions so i can make the product better, if you can drop an email to hello @ nixmade.com

For Cloud API, my post have been a little confusing, was suggesting/hoping 3rd party services to integrate with open source orchestrator https://github.com/nixmade/orchestrator so they can have their own version of pippy (not Github Actions).

same. Read the features and assumed Github Actions were already Pipelines for GitHub Actions.

"If you have used Azure pipelines, in summary, this would be Azure Pipelines meets Github Actions."

I haven't used Azure pipelines, could you explain for an audience that doesn't have that comparative knowledge?

I know GitHub Actions pretty well but I'm having trouble understanding why I would want this extra layer on top of it.

Github does offer deployments https://docs.github.com/en/actions/deployment/targeting-diff... which is similar in comparison, but i feel there are lot of steps to go through to get this working and creating pipeline for simple workflows makes it hard.

Azure pipelines offered this by setting up reviewers, approvals, but reading more about Github deployments, they might be similar.

It sounds like approvals might be the key feature that Pippy is adding on top of GitHub Actions.

GHA already has approvals.

Pippy has stage level approvals. As far as I know,after playing with GHA a lot, the only approval is for the entire PR.

After reading this site I can't tell what this actually does that github actions doesn't already do except the integration of a datadog exporter.. which we already did that in our shared workflows but w/ openmetrics/prometheus. Also what 'enterprise' only has 50 pipelines.

Sorry about the site not being clear. Agree most of this is already offered by Github, I updated the site to have key differentiators

- Automatic rollback on monitoring failures

- Datadog monitoring, queries configured datadog monitors after the workflow execution upto 15mins (right now hard coded). Optionally rollback if monitors are in failed state. This is also achievable with having a Github Action workflow query datadog monitors and stop further stages.

Give me your Elevator Pitch for someone in Azure DevOps almost 100%. Even if some of teams moving to GitHub, we continue to leave their pipelines in Azure DevOps because it's so easy.

I have been made aware of deployments in Github https://docs.github.com/en/actions/deployment/targeting-diff... which offers similar functionality, without external monitoring or Rollback. The advantage of Azure devops is integration with Azure identity, making setup of approvals, reviewers easier.

pippy makes it easy to setup pipeline from simple workflows using UI (which Azure devops is good at), while in Github you may need to create a parent workflow which comprises of these individual simple workflows.

Would be cool if you can go deeper on the features on the homepage

Great concept. Needs a little refinement, but I really miss the ease-of-use of Azure DevOps now that I'm on GH. Excited to test it out

Btw, is it open-source?

Thanks for trying this out. The command line version is open source and completely free, its local only and interacts with Github only.

you can try it here https://github.com/nixmade/pippy

fantastic. ill give it a go!

Seems interesting, but how is it different than what GitHub already does?

I updated the site to include differentiators. Agree that most of it has already been offered by Github.