You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Strider currently assumes that all tasks conform to the "build->test->deploy" paradigm. This does not fit our use case. We are only concerned about the "Deploy" step, and a generic task model would suite us better.
We are using strider as a continuous delivery tool: Strider receives a poke via the GitHub / BitBucket plugin (webhook) and from there it performs some magic to deploy the new code on a Docker/Fleet cluster. We've had to shoe-horn this into the current model, and the inclusion of 'Test' buttons in our projects are unnecessary.
From a dev-ops perspective being able to define ad-hoc repeatable tasks would be useful too. Some examples could include: Task to update our cluster, or scale up or down.
The text was updated successfully, but these errors were encountered:
(Further to discussion in #667)
Strider currently assumes that all tasks conform to the "build->test->deploy" paradigm. This does not fit our use case. We are only concerned about the "Deploy" step, and a generic task model would suite us better.
We are using strider as a continuous delivery tool: Strider receives a poke via the GitHub / BitBucket plugin (webhook) and from there it performs some magic to deploy the new code on a Docker/Fleet cluster. We've had to shoe-horn this into the current model, and the inclusion of 'Test' buttons in our projects are unnecessary.
From a dev-ops perspective being able to define ad-hoc repeatable tasks would be useful too. Some examples could include: Task to update our cluster, or scale up or down.
The text was updated successfully, but these errors were encountered: