To define release pipelines

[ayr-ton]

This is more a discussion right now, then we could think if it makes sense and new issues can be created from it.

I think the steps for lint-format-build-test are well defined for most platforms now.

Speaking of release, some pipelines are pretty predictable if the deploy step is separated as expected.

Like, if I have built this Flask API pipeline with a Dockerfile in mind if I have a stage for releasing this in GitHub registry or another one I like I should be able to deploy it easily in ECS/EKS/Heroku.

So, would work if PRs focused on this topic are for releasing in GitHub as a first trial? I have one in mind if this structure makes sense. If not, let's discuss another one.

[oesgalha]

Hello, @ayr-ton !

A release stage is definitely something we plan to work on. 😄

We still have to hash out some details on how to approach the release stage. From a UX perspective, we're trying to stay out of the way as much as possible. But releasing software requires additional configuration, such as the credentials to the used services. Should Pipelinit print instructions to configure the repository after it runs? Include comments in the generated files? Something else entirely? There is also the step to determine where an artifact should be released.

We're currently working on a ROADMAP, and the release stage will be there, but it isn't something we plan to start right now.

---

So, would work if PRs focused on this topic are for releasing in GitHub as a first trial? I have one in mind if this structure makes sense. If not, let's discuss another one.

What do you have in mind? A template for publishing packages in the GitHub registry? I think this would be a good starting point since this repository itself needs this.

[ayr-ton]

@oesgalha Thinking in the organization we may have:
The stack stuff (lint, build, test, etc)
Chose where to release (GitHub/nexus/dockerhub/ttl.sh), depending on the release type, if it is a container or a library.

The easiest for testing would be GitHub for containers or ttl.sh, as we can make containers from almost everything.

We can add the code mentioning the needed variables/secrets, similar to what happens in GitHub Actions examples.

So the stages I imagine would be a release-by-name, which will have a docker tag with the same branch name and a release-master for pushing the latest tag. Release versions like 1.0.0 can stay for the second version.

What do you think? It's a good path for this stage MVP?

I'm also thinking about the release process of helm charts, but I think this would be for a different phase.

[joao10lima]

@oesgalha @ayr-ton
Following the discussion, here's my proposal to kick off this feature based on what was said before:

• Add a new stage with its own template release.yml
• In the first implementation, we add support only for GitHub registry using a GitHub Token. Later we can add more registries based on the login information of the docker action https://github.com/docker/login-action#github-container-registry
• For the necessary information(GitHub token):
  • In the strict mode(CLI) give an error if not provided then asks the user to fill the information or to put in the pipelinit.toml
  • On the playground, just points to a generic GitHub secret ${{ secrets.GITHUB_TOKEN }} then give a warning telling the user to create the secrets, or we can simply do not support this workflow generation in the playground giving it a warning, telling the user to use the CLI.
• Following the @ayr-ton comment on the stage, i think we can already use the release version saving it throughout the stages using as example the Pipelinit own release stage:
  • https://github.com/pipelinit/pipelinit-cli/blob/main/.github/workflows/release.yaml

 on:
  push:
    tags:
      - 'v*.*.*'

[oesgalha]

About the registry choice...

I think the CLI should come with sensible defaults for registries. When the project is initialized, the configuration file has some comments showing how to configure other registries and what are the ones being used by default. That is, after the first run, the .pipelinit.toml file would look like this:

platforms = ["github"]

# Registries to publish artifacts.
[registries]
# Default values per stack are presented below.
# If your project use other registry(ies), uncomment and edit
# docker      = ["https://hub.docker.com"]
# javascript  = ["https://registry.npmjs.org"]
# python      = ["https://pypi.python.org/pypi"]

And an info level log should inform the user to configure the repository afterwards with the required secrets.

That way most projects won't need any additional configuration. Projects that uses private and/or alternative registries can edit it.

Also, for Docker, the default registry should be Docker Hub. Because that is the default registry used by the command line.

[ayr-ton]

Let me try writing some commits in my free time so we could start visualizing the discussion.
My future pipelines will use this a lot.

[ayr-ton]

@joao10lima seems that #80 is the MVP for this one already. Let me know if I can help with any testing \o/
Will hold with my code snippet for now.

[joao10lima]

@joao10lima seems that #80 is the MVP for this one already. Let me know if I can help with any testing \o/ Will hold with my code snippet for now.

Hello @ayr-ton, if you could test and post what you think on the PR it sure will be of great help, the crude of the implementation is already on the branch, for this one it is limited only for Docker release, and you can test in any project with a Dockerfile if you want to change the registry url just change it on the pipelinit.toml e run the CLI once more.