Setup CI

[thirtytwobits]

use our new texer container to build in Buildkite with PR validation builds.

[pavel-kirienko]

@clyde-johnston can you please look into this?

@thirtytwobits why Buildkite, why not GitHub Actions?

[TSC21]

I would go for actions. Quite easy to setup and use.

[thirtytwobits]

Or Travis? It'd be nice to not have so many different CI solutions. Can we keep it at two? Can we move our Travis builds to actions?

[pavel-kirienko]

Can we keep it at two? Can we move our Travis builds to actions?

Someday, sure, but we already use GitHub Actions for website deployment.

[clyde-johnston]

What event should trigger the build? Any push? Any push to master? Any change to the specification directory?

[pavel-kirienko]

Any push.

On Tue, Jul 14, 2020, 09:21 clyde-johnston notifications@github.com wrote:

What event should trigger the build? Any push? Any push to master? Any push to the specification directory?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/UAVCAN/specification/issues/72#issuecomment-657993007, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZFIZDMGXDERQRYCK5MTOTR3P2O3ANCNFSM4K6QOBDA .

[thirtytwobits]

Any push. … On Tue, Jul 14, 2020, 09:21 clyde-johnston @.***> wrote: What event should trigger the build? Any push? Any push to master? Any push to the specification directory? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#72 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZFIZDMGXDERQRYCK5MTOTR3P2O3ANCNFSM4K6QOBDA .

any push to master, right @pavel-kirienko ?

[pavel-kirienko]

Why? Let it be any push to any branch.

[thirtytwobits]

consistency. Having a single branch that can publish the spec from means there's no risk of another branch being created that publishes different versions. This would create a condition where the last branch to accept a change would be the one that the public-specification was published from. That seems dangerous.

[clyde-johnston]

This should not be a problem as each artifact is associated with its respective commit ID. Presumably the artifacts associated with commits in the master branch will be canonical. You would need to switch branches to download a more recent artifact in another branch. When the pull request for this branch has been approved and merged, a new artifact will be built from the new commit in the master branch.

[pavel-kirienko]

Automatic builds and automatic publications are two different things.

The doc should be always built and stored somewhere temporarily regardless of the current branch. If the branch is master, the doc should also be published somewhere so that it can be redirected to from uavcan.org/specification. Do we have any ideas on how to implement that?

Currently, I update the published doc manually by simply overwriting this file here: https://github.com/UAVCAN/uavcan.org/tree/master/specification

[clyde-johnston]

The normal method is to deploy the artifact (i.e. publish the document) to the web server once the build is complete. This can be done directly from the specification repository without copying the PDF to the uavcan.org repository.

If you want the specification to be part of the web source, you might want to consider making the specification repo a submodule of the uavcan.org repo. The limitation here is that you would need to check in and commit the submodule directory every time there was a change in the specification repo. It might be possible to automate this by sending a custom event from one repo to another but I am not sure. It would be unusual to do it this way.

[pavel-kirienko]

Clyde has set up auto-build but not auto-publish. Closing because this issue is about the former only, which is done.