Rethink and automate the release process

[leodido]

What would you like to be added:

Since Falco had been donated to the CNCF, most of its release process (if not thw whole release process) relies on Sysdig infrastructure.

Since most of the process is also manual we need to:

• Rethink the process to make it as automated as we can
• Integrate the release process with clear GitHub milestones and make it community driven (eg., @poiana opening a release PR when milestone is completed)
• Integrate it with the work @markyjackson-taulia is doing in New Falco CI Infrastructure test-infra#48
• Download dependencies from their upstream sources (not from Sysdig's S3)
• Distribute and push the falco artifacts automatically (eg., docker images, drivers, etc.), without relying on Sysdig infrastructure

All the bullet points here can be split into multiple issues but this one can be used to track the progress.

Everyone is invited to discuss and propose!

Why is this needed:

Because the project needs to stay independent from Sysdig as a company.

[krisnova]

Hey @leodido is it possible to define the problem space a bit more before we look at a solution? I am sure we all agree that we want our build to be better, but for documentation purposes can we highlight what is wrong with the current build so we can all share ideas on what we think needs to be done?

[leodido]

Hello @kris-nova in this issue I was talking only about the automation of the release process (which clearly has the build as a prerequisite).

What I think is wrong about the current process:

• it is completely manual
• it is obscure to the community (not documented in the public).

This causes inability to understand why (and how) a new release will be available.

What I'd like to be done.

I would like a release process like the following.

1. The maintainers assign issues and PRs to milestones (continuous triaging).

   1.1. Every milestone corresponds to a release/version

   1.2. @poiana can provide help in this if we configure the milestone, milestoneapplier, the milestonestatus, and optionally the project test-infra plugins

   1.3. Contributors can propose issues/PRs to be included into the current milestone

   1.4. Depending on the type of issues/PRs the maintainers decide whether the release will be a x.x.patch or a x.minor.x (semantic versioning).

   Using this mechanism the community will know what the next release will contain. Also this mechanism make possible to track the percentage of completion.

2. When a milestone (or a project) is complete the release process starts opening a PR against the default branch (ie., dev branch).

   2.1. The PR adds to the CHANGELOG file the release notes (that we already have within the PR template)

   2.2. The same PR also eventually apply changes to README if required

   2.3. The maintainers verify that documentation (integrations, website, etc.) is updated. Otherwise they'll hold the release throwing the /hold command on the PR.

3. When the above PR is merged in dev the @poiana bot (which is the only account with permissions to push to master) will be responsible of merging the changes to master

   3.1. The triggering mechanism can be implemented with a custom plugin for test-infra. This custom plugin will implement one of the following strategies:
   - slash command (e.g., /release)
   - particular label (eg., trigger/release) attached to the previous PR
   - particular PR title (eg., release: preparing <tag>)
   - detecting changes (e.g. version bump at the top of the file) to file CHANGELOG.

   3.2. The tag can be inferred from the milestone title or from the CHANGELOG changes.

   3.3. The bot will create a ProwJob performing
   - the merge (eg., git checkout dev; git pull; git checkout master; git pull; git merge origin/dev; git push)
   - the tag
   - the github release associated to the tag (containing the diff of the CHANGELOG as text corpus).

   Not clear to me why the master should have the merge commits. The strategy for the default branch is to allow only rebase strategy for merging in order to have a linear git history.

4. The CI will be responsible, when running on the master branch and/or on a git tag, to create artifacts and push them.

   4.1. Probes
   4.2. DEB, RPM, TGZ packages
   4.3. Docker images

   This assumes that the artifacts creation is tested and done on all PRs (or at least on the changelog/releasing PR).

5. The CI itself sends heads-up messages to the Slack channels about the new release.

[markjacksonfishing]

Relates to falcosecurity/community#26

[Issif]

I like the process described by @leodido, just want to add that a kanban board (like here) by milestone will be great for following statuses.

[leodido]

While doing #849 me and @fntlnz had the opportunity to review the current branch model of this repo.

In order to have a new automated and more robust release process we propose to:

1. rename master branch to something like old-master to do not lose the old tags
2. rename dev into master branch
3. make the new master the default repo branch

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[fntlnz]

We still want this

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[leodido]

Keep this open