[Feature]: Have github actions to allow CI/CD

[AliSajid]

Describe the feature

Currently, shuttle requires manual deployment. The shuttle/deploy-action also looks more "hack-y" than elegant.

I would like for there to be independent and composable github actions that allow you to

• Set up shuttle on the runner
• Build and test your project
• Set or reset secrets (possibly using the Github Action secrets as the backing store)
• Deploy the application.

Suggestion or Example of how the feature would be used

No response

Duplicate declaration

• [X] I have searched the issues and this feature has not been requested before.

[AliSajid]

Additional Thoughts:

I am considering designing five different actions here:

What is needed:

1. Set up shuttle binary
2. Log in to shuttle
3. Check if a project exists and create one if necessary
4. Create a secrets.toml file for consumption by deploy
5. Deploy a rust project to shuttle and create necessary outputs

Plan:

I will create three actions. Each action will do one thing and one thing only.

action	kind
shuttle-setup	typescript
shuttle-login	typescript
shuttle-create-project	typescript
shuttle-set-secrets	typescript
shuttle-deploy	docker

Each action will have its own repository.

[oddgrd]

Apologies for the delayed reply here @AliSajid. This sounds great, using shuttle in a CI/CD workflow definitely could use some work! I think your proposed actions make sense, although the create project step is due to be removed in a month or two (:crossed_fingers:), so I wouldn't spend a lot of time on that, but that's up to you. :slightly_smiling_face:

[AliSajid]

@oddgrd So are we implicitly creating projects? The only reason I have this up is because deploys would fail if a project didn't exist. If that's the plan then this will definitely become a redundant method.

[AliSajid]

Also, AliSajid/shuttle-login is almost ready for prime time. The functionality is there and I'm just writing some tests to ensure that all edge cases are covered.

[oddgrd]

Yes, a user will no longer need to be concerned with starting/stopping projects (containers), they will just deploy and their service will be started in a container by our orchestrator. But this is some weeks away, I'd say.

[jonaro00]

The current GitHub action can do pretty much all of the above points, to the point where I can consider this issue closeable.

[jonaro00]

Since the current action can accomplish everything above except (re)starting projects (which will be removed), I'll close this.