!ci-build-me

!ci-nightly-me

coverage: 61.792% (-0.001%) from 61.793%
when pulling 1f93250 on dkijania/sign_apt_debians
into ec43a6b on compatible.

!ci-build-me

!ci-nightly-me

Nightly are failing due to develop conflict. When this will be resolved nightly will reach teardown phase and I can prove that publishing is still working good

I think this is a good opportunity to take a moment to figure out a way to test this kind of PRs i.e., those involving the publishing of container images and Debians, or Post Tear Down, in general.

As these are moved to the "Tear Down" phase, which is not started unless ALL previous Jobs pass; CI does not really perform a test of the involved code if there are conflicts with develop or master.

At this moment, we would only be able to test ANY change to the publishing phase "after the fact" i.e., merging.

I want to call attention to this and maybe discuss a path for testing "Post Tear Down" Jobs. What do you think? @dkijania

@SanabriaRusso Good point.From one side, merges checks are really useful as they help us distribute effort of merging compatible/develop to master way before we need it. From other side they are a bit painful as we need to create separate PR and molest reviews for approvals.
If PR is conflicted than it means it won't be merged therefore we don't really need debian and dockers produced by this CI job. We are saving some resources 😄 If we need to generate debian/docker from our branch for any reason we can use command: !ci-docker-me and !ci-debian-me which will ran separate pipeline which will produce some artifacts (https://buildkite.com/o-1-labs-2/mina-build-docker) - it is still not perfect (as we need to do some research in order to acquire builds).
So one approach would be to leave it as it is and just accept that some PR (especially CI related) can suffer (I'm ok with that)
Another approach would be to separate merges as another CI stage at the beginning (currently we have 3 - quick-tests/long-tests/teardown) and allow failures from merges stage (which will mark pipeline as red anyhow).

In this particular PR is tested my code on another pipeline which was tear down only. I modified my code so it always wanted to publish already built debians from nightly. Once it was ok. I ran nightly. I agree that it is not really fun testing such pr but they are not very frequent.

However, moving merges into separate group and work more on more tailored pipeline IMHO is a good direction alone