Lunie: Automate deployment.

[NodeGuy]

Every push to master should automatically deploy a new release to GitHub.

This can be done on CircleCI.
It would be good to run it by Jessy before implementing.

[jbibla]

🎵what a wonderful world this could be 🎵

[faboweb]

What would the script do?

• Bump the minor version
• Build the application
• Create a GitHub release

[faboweb]

We can use a tool for releasing: https://github.com/remixz/publish-release
We can use the CI to trigger the tool

[faboweb]

But we would not compare hashes

[NodeGuy]

What would the script do?

• Bump the minor version

No, we would do that so that we have control over SemVer semantics.

• Build the application

Yes.

• Create a GitHub release

Yes.

We can use a tool for releasing: https://github.com/remixz/publish-release
We can use the CI to trigger the tool

Nice find!

But we would not compare hashes

Correct, because the CI build would be canonical.

[faboweb]

We did an auto-bump in an old project: it would always bump the minor
version. If we want to do a major bump, we just bump the major bump the
major version. The only downside would be no x.x.0 version.

David Braun [e-mail] schrieb am Mi., 23. Mai 2018, 20:24:

What would the script do?

• Bump the minor version

No, we would do that so that we have control over SemVer semantics.

• Build the application

Yes.

• Create a GitHub release

Yes.

We can use a tool for releasing: https://github.com/remixz/publish-release
We can use the CI to trigger the tool

Nice find!

But we would not compare hashes

Correct, because the CI build would be canonical.

—
You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub
https://github.com/cosmos/voyager/issues/709#issuecomment-391449762, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFmO2V-4KKvRxIsIfwLMcwViDEqrk02jks5t1allgaJpZM4UCLM8
.

[nylira]

I think 0.7.1 instead of 0.7.0 would be weird, likewise with a missing 1.0.0. It's not conventional and doesn't follow SemVer correctly.

However, if we don't autobump the version, we would have to manually bump the version with every pull request. Similar to what we're doing with the changelog. Is that right? I support going with this.

[faboweb]

Note: We need a bot that is able to commit to master and to create a release.

[jbibla]

sounds like we can figure out a way to automate builds AND use semver which would be ideal.

regarding comparing hashes, this should also be automatable but can be left for v2 of automated builds.

[faboweb]

Note: We need to update the changelog with the new version number

[NodeGuy]

I think 0.7.1 instead of 0.7.0 would be weird, likewise with a missing 1.0.0. It's not conventional and doesn't follow SemVer correctly.

I agree, I think we should comply with SemVer.

However, if we don't autobump the version, we would have to manually bump the version with every pull request.

No, we would bump the version only once per release, not on every PR.

There is no need to change how we increment the version number from how we're doing it today. That process can stay the same.

Note: We need a bot that is able to commit to master and to create a release.

Not quite: The bot would watch for a commit to master and then it would create the release. Our pushing a commit to master will be our signal that we're ready to make a release.

We want to automate the process of releasing but not the act of releasing. We could get away with that if we weren't publishing security-sensitive software but because Voyager is so security sensitive we want to always keep our hand on the release lever.

Regarding the comparing of hashes, I've given it some more thought. The question in my mind is "why are we comparing hashes?". If it's because we think our build process is buggy or nondeterministic, then let's automate it and fix it until it works. If we're comparing hashes because we don't trust the build machine not to be compromised then it could be a good idea to have redundant builds in heterogenous environments to reduce the risk. This hazard is explained well in Deterministic Builds Part One: Cyberwar and Global Compromise.

Perhaps we want to go further than this and think of a blockchain-oriented solution, e.g., have every validator build the code as well and compare hashes as part of the Cosmos protocol.

[faboweb]

Everything not automated has potential to be forgotten.

Note: We need a bot that is able to commit to master and to create a release.

The push to master should be the only action we need to do to release. Everything else should be automated. Therefor the bot updates the version and publishes the release so nobody of us has to do this manually.

"why are we comparing hashes?". If it's because we think our build process is buggy or nondeterministic

Yes ;) And until we know that it is deterministic, we should check the hashes.

redundant builds in heterogenous environments

That is a good idea that was discussed several times already. Let's do this. But later when there is more time.

have every validator build the code

Great idea. But validators probably don't want to be compromised like that. Full-nodes could do it though.

[NodeGuy]

The push to master should be the only action we need to do to release. Everything else should be automated. Therefor the bot updates the version and publishes the release so nobody of us has to do this manually.

OK. How are we going to tell the bot which version number to use, or do you want to break compliance with SemVer?

[faboweb]

I don't mind having no x.x.0. It is still semantic if it starts with
version x.x.1.
Do update the minor version. We would just push a commit changing the
version to x.(x+1).0. the bot then increments the version to x.(x+1).1.

David Braun [e-mail] schrieb am Do., 24. Mai 2018, 19:19:

The push to master should be the only action we need to do to release.
Everything else should be automated. Therefor the bot updates the version
and publishes the release so nobody of us has to do this manually.

OK. How are we going to tell the bot which version number to use, or do
you want to break compliance with SemVer?

—
You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub
https://github.com/cosmos/voyager/issues/709#issuecomment-391793053, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFmO2RPFJZ45eziINb2yq0nZSEhr5cFHks5t1uuQgaJpZM4UCLM8
.

[NodeGuy]

Well, not exactly (from SemVer 2.0.0):

Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.

We would be signaling a bug fix even if there isn't one.

Version 1.0.0 defines the public API.

We would't be able to define the public API by publishing Version 1.0.0.

[faboweb]

I would offer myself to release 1.0.0 by hand. :)

David Braun [e-mail] schrieb am Do., 24. Mai 2018, 23:12:

Well, not exactly:

Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards
compatible bug fixes are introduced. A bug fix is defined as an internal
change that fixes incorrect behavior.

We would be signaling a bug fix even if there isn't one.

Version 1.0.0 defines the public API.

We would't be able to define the public API by publishing Version 1.0.0.

—
You are receiving this because you were assigned.

Reply to this email directly, view it on GitHub
https://github.com/cosmos/voyager/issues/709#issuecomment-391864309, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFmO2WR4WYoJHZEEiJW8HG5IjoNQ5oBFks5t1yJWgaJpZM4UCLM8
.

[NodeGuy]

I would offer myself to release 1.0.0 by hand. :)

Deal.

Note: We need a bot that is able to commit to master and to create a release.

Shall I ask @jessysaurusrex to create one?

[jessysaurusrex]

Let me talk to my people, we'll sort it out.

[NodeGuy]

How's this going, @jessysaurusrex ?