[DISCUSS] Flow of releasing packages

[Jonathan Buttner]

This issue is to discuss the proposed flow for releasing a package and the CI jobs in place to support that flow.

Should we be able to release straight to production without having to go through snapshot and staging?

If it is a valid use case to release straight to production it would be handy to have CI jobs automatically kicked off for staging and snapshot once a build completes on the production branch.

I ran into this recently where I PR'd the endpoint package straight to the production branch here: #149
instead of going through the snapshot -> staging release flow. As a result the staging and snapshot distributions did not have the v0.11.0 package released to them.

To release the package to staging and snapshot the CI job has to be manually run on those branches.
For example here: https://beats-ci.elastic.co/blue/organizations/jenkins/Beats%2Fpackage-storage/activity?branch=staging

[Nicolas Ruflin]

@jonathan-buttner I think it is discourage but valid way to release a package. @kuisathaverat We had in the past some dependencies between repositories, so I assume adding these dependencies should be possible?

The way I see the dependencies is:

• If production is update, staging must be updated
• If staging is updated, snapshot must be updated

This means, if production is updated, indirectly snapshot will be rebuilt too.

[Ivan Fernandez Calvo]

In the past, we triggered a build of package-storage Docker image on merges on a branch of the package-registry. I dunno if the same approach would ve valid.

I do not have clear here is what we want to deploy on staging when we make a change on production, I will try to explain what I understood about who this repository works.

• Package storage contains packages
• It has three different packages "manifest" on three different branches
  • snapshot - e.g. package1-v1.0.2, package2-v0.1.0, package3-v0.1.0
  • staging - e.g. package1-v1.0.1, package2-v0.1.1
  • production - e.g. package1-v1.0.0

so if I make a change on the package1 in production and now is the version v1.0.3, what we want to deploy on staging and production without propagating those changes. There is something I do not see.

[Jonathan Buttner]

In the past, we triggered a build of package-storage Docker image on merges on a branch of the package-registry. I dunno if the same approach would ve valid.

I do not have clear here is what we want to deploy on staging when we make a change on production, I will try to explain what I understood about who this repository works.

• Package storage contains packages

• It has three different packages "manifest" on three different branches

  • snapshot - e.g. package1-v1.0.2, package2-v0.1.0, package3-v0.1.0
  • staging - e.g. package1-v1.0.1, package2-v0.1.1
  • production - e.g. package1-v1.0.0

so if I make a change on the package1 in production and now is the version v1.0.3, what we want to deploy on staging and production without propagating those changes. There is something I do not see.

If we make a change in production and now package1 is on version v1.0.3, that package will be propagated to staging and snapshot when those branches are built because the docker file copies the production packages during the docker build process: https://github.com/elastic/package-storage/blob/staging/Dockerfile#L9
https://github.com/elastic/package-storage/blob/snapshot/Dockerfile#L10

So if a change is made on production (a merge to production branch) CI should kick off a job for staging and snapshot to rebuild the docker image. Same goes for staging, ci should kick off a job for snapshot (but not production).

[Nicolas Ruflin]

@kuisathaverat Does what @jonathan-buttner explains above solve your question? If yes, anything I can help with getting these changes in?

[Ivan Fernandez Calvo]

yes, it works completely different than I thought

[Ivan Fernandez Calvo]

Do you know that for the same commit SHA we will have different Docker images with different content?

e.g.

we have the following branches status

• production - commit SHA 111111111 - packages1 - dockerImage:111111111
• staging - commit SHA 2222222222 - packages1 + packages2 - dockerImage:2222222222
• snapshot - commit SHA 3333333333 - packages1 + packages2 + packages3 - dockerImage:3333333333

If we make some changes on production we will have something like this

• production - commit SHA 4444444444 - packages1.1 - dockerImage:4444444444
• staging - commit SHA 2222222222 - packages1.1 + packages2 - dockerImage:2222222222
• snapshot - commit SHA 3333333333 - packages1.1 + packages2 + packages3 - dockerImage:3333333333

[Nicolas Ruflin]

ups, was not thinking of this. Could we make the second on dockerImage:333+staging+prod or similar?

[Ivan Fernandez Calvo]

we can put labels in the Docker image to know which version is in it, to know what it is really inside.
If we will need to grab exact version we can use something like this dockerImage:b366a24-c116a45-a123c56 with the short SHA of each repo, this tag will be an additional one we can keep the commit SHA one (dockerImage:b366a24b366a24b366a24) and the branch one (dockerImage:snapshot)

[Nicolas Ruflin]

SGTM. To make sure we talk about the same thing:

• PR to staging is merged with commit hash aaabbb
• This creates distribution:staging and distribution:aaabbb + contains the labels on what prod commit packages it contains
• This triggers a build for snapshot. Current snapshot commit is cccddd and image for it already exist
• It creates distribution:snapshot and distribution:cccddd-aaabbbb + contains labels.

Basically everything we have today stays the same but we get additional images with short hashes (I skipped short / long hashes in my example) + we add labels to the containers for debugging purpose.

[Marcin Tojek]

I suppose I can close the issue. It's a bit stale now.