Add actions for push, create namespace and delete namespace

[rberrelleza]

Proposed changes:

• Have a separate action for login, that should be called first
• Remove login from all actions
• Support to specify an okteto enterprise URL
• Add actions for push, create namespace and delete namespace

You can see an example of how this would look like here: https://github.com/rberrelleza/actions-test/blob/42ab44b5e1a4b66e0190e3888a94f869dfa29c28/.github/workflows/main.yaml

[rberrelleza]

Could we also remove the kustomize logic and keep the deploy action just a simple kubectl apply?

If there's nothing okteto special we should probably remove it in favor of using a standard action. what do you think?

[rberrelleza]

@tullo what do you think about this changes? Would this break the way you use the action?

[pchico83]

Could we also remove the kustomize logic and keep the deploy action just a simple kubectl apply?

If there's nothing okteto special we should probably remove it in favor of using a standard action. what do you think?

@rberrelleza we need it for completeness, at least you include the kubectl apply as part of the push action. The combined action should be:

1. get k8s credentials
2. kubectl apply
3. okteto push

[rberrelleza]

@rberrelleza we need it for completeness, at least you include the kubectl apply as part of the push action. The combined action should be:

That flow looks a bit forced in my opinion, as it causes 2 deploys instead of one no?

I think we should support three different scenarios with the actions:

1. The repo doesn't have kubernetes manifests, and there's nothing running: in this case, push works fine as long as the dockerfile sticks to the port 8080 contract.
2. There are kubernetes manifests in the repo, but there's nothing running: I think build, update manifest and kubectl apply makes more sense (this is what the current deploy flow supports)
3. You are updating an existing deployment (e.g. updating a staging env after merging a PR): In this case, the push action as is works fine.

@pchico83 WDYT?

[pchico83]

@rberrelleza for the second I would go with kubectl apply + push. Most of the time, kubectl apply does nothing because the manifest does not change. But I find it clearer to have a single way to build/push/update image tags in our actions. It is the main motivation behind okteto push

[tullo]

@tullo what do you think about this changes? Would this break the way you use the action?

I will have look at it tomorrow @rberrelleza need to figure out how the new image makes it into the manifest if kustomize goes away

[rberrelleza]

I will have look at it tomorrow @rberrelleza need to figure out how the new image makes it into the manifest if kustomize goes away

@tullo okteto push takes care of building the image , pushing it (using Okteto registry), and updating the deployment with the new image. It uses information in the okteto.yml file (or the --name param) to figure out which deployment and image to replace

[tullo]

@rberrelleza the push action is doing 3 things at once, maybe it should be renamed to CI/CD?

To get the current behaviour that allows to injects build-time arguments during image build time - how could this be done with the updated action?

Looking at https://github.com/okteto/okteto/blob/master/cmd/push.go#L135 there it could append optional build arguments as well. Is that an option for you?

[rberrelleza]

@rberrelleza the push action is doing 3 things at once, maybe it should be renamed to CI/CD?

To get the current behaviour that allows to injects build-time arguments during image build time - how could this be done with the updated action?

Looking at https://github.com/okteto/okteto/blob/master/cmd/push.go#L135 there it could append optional build arguments as well. Is that an option for you?

@tullo Yes. Long term, the idea with the push action is for workflow authors to stop thinking in terms of individual steps, and instead think in terms of "I have code , and I want to run it in Okteto Cloud". Right now that involves build, push, update, deploy; later we want do more, like integrate with buildpacks, do smarter deploys, etc..

You make a good point with the buildargs. That is something that's not possible with the current version of okteto push (it is coming though). For now I'm going to close this PR, add the commands separately, but leave build and deploy as they are today (the only change will be in the auth model, since we are moving to a single login action instead of passing the token around).