search

epi-project / brane

Programmable Orchestration of Applications and Networking
Apache License 2.0
9 stars 7 forks source link

Tracking issue: CD #100

Open DanielVoogsgerd opened 5 days ago

DanielVoogsgerd commented 5 days ago

Now that CI (#77) is almost done, it is time to move on to CD as well. It does not seem to difficult, but we shall see.

To do:

For progress see my fork and relevant triggered GitHub action runs, I am not creating a PR as of now as GitHub actions is basically a whole lot of testing by pushing.

DanielVoogsgerd commented 5 days ago

I think most parts are done already, from here it is mainly just finding a preferred trigger mechanism. @Lut99 what would you like. What we could do is trigger a release when we push to a tag v<x>.<y>.<z> for example, but I'm not set on anything in particular.

Besides that the main problem I'm having is related to the building of the worker instance images. It seems to be broken right now. I'll investigate at a later time.

> [build-policy-reasoner 5/7] RUN --mount=type=cache,id=cargoidx,target=/usr/local/cargo/registry     --mount=type=cache,id=reasonercache,target=/policy-reasoner/target     cargo build --release --features brane-api-resolver  && cp ./target/release/policy-reasoner /brane-chk:
2.001     Updating git repository `[https://github.com/Lut99/error-trace-rs`](https://github.com/Lut99/error-trace-rs%60)
2.318     Updating git repository `[https://github.com/Lut99/humanlog-rs`](https://github.com/Lut99/humanlog-rs%60)
2.577     Updating git repository `[https://gitlab.com/eflint/json-spec-rs`](https://gitlab.com/eflint/json-spec-rs%60)
3.203     Updating git repository `[https://github.com/Lut99/names-rs`](https://github.com/Lut99/names-rs%60)
3.410     Updating crates.io index
3.413 error: no matching package found
3.413 searched package name: `brane-ctl`
3.413 perhaps you meant:      brane-cfg, brane-dsl, brane-api, ...
3.413 location searched: https://github.com/epi-project/brane?branch=develop#ccebb813
3.413 required by package `key-manager v0.1.0 (/policy-reasoner/tools/key-manager)

And less importantly I think -- going from the list of release artifacts in #77. -- is that building the emulated binaries is broken with the following error:

WARNING: The requested image's platform (linux/arm64) does not match the detected host platform (linux/amd64/v3) and no specific platform was requested
9377c3fb0bed7b0f32f187768f96104011a4272b995e6d94523127825b86c0c5
the input device is not a TTY

Job 'docker exec -it brane-build /build.sh brane-cli --arch aarch64' failed. See output above.

 > Creating directory './target/debug'
 > docker buildx build --output type=docker,dest=./target/debug/build.tar -f ./contrib/images/Dockerfile.build --platform aarch64 .
 > docker load --input ./target/debug/build.tar
 > docker tag a872cc936ae503a28ae90ff53b11b6981c86e5d6f7f6cca1487abfde2ec747a4 brane-build
 > Running 'docker run --name brane-build -d --rm --entrypoint sleep -v /home/runner/work/brane/brane:/build brane-build infinity' iff 'docker ps -f name=brane-build --format {{.Names}}' returns exit code 0 and writes correct stdout
 > docker exec -it brane-build /build.sh brane-cli --arch aarch64

again I will investigate at a later time what the precise problem is.

Lut99 commented 3 days ago

OK, I pushed epi-project/policy-reasoner@7566f131bfd65db2cd6775b579d59687a5162f6b. Seems like switching the dependency of the policy reasoner on Brane from develop -> main, running cargo update and then adding a missing feature is enough to make it work? Can you try?

As for the other one: I'm not sure what the problem is... Can you give a little more detail?

DanielVoogsgerd commented 3 days ago

OK, I pushed epi-project/policy-reasoner@7566f13. Seems like switching the dependency of the policy reasoner on Brane from develop -> main, running cargo update and then adding a missing feature is enough to make it work? Can you try?

Yes it does, the worker images also compile now :) Another item off the checklist :)

As for the other one: I'm not sure what the problem is... Can you give a little more detail?

Haha, it was more meant as a pointer for myself in order to remember what I was stuck on. If I use the make.py --arch flag I am getting that error, I haven't really investigated it yet, so it might still be something obvious.

I am a bit hesitant to say so, but I think we can wrap up CD and ship the same images you did in the 3.0.0 release. This brings us to some design decisions:

We mainly need to know what kind of release mechanisms we want. I suggest we create a nightly/weekly github pre-release where we build the framework with the latest changes every night/week (if there are any changes).

For the main release we could either use something like release-please, release-plz or equivalent, but I am not certain how much that it compatible with the current workflow in this repository. Alternatively we could trigger a release when somebody pushes to a v* branch and create a release like that. Lastly one could use a manual trigger, I have not seen it worked out yet, but I'm pretty sure, I can get something to work, and as always, I am fully open to alternative solutions.

Lut99 commented 1 day ago

The release mechanisms you mention are good! I don't mind doing a nightly/weekly release (let's say weekly or so), albeit just to check if the compilation works. And yeah, if you could only make it run if there are changes, that'd be great xD

RE the main release: I guess I prefer some manual trigger for now, but I am also fine with the manual trigger being the creation of a tag. Can that still work with giving some nice CHANGELOG messages? Or will we have to automate that, somehow?

DanielVoogsgerd commented 1 day ago

I think one can basically edit the release afterward to add the changelog contents, we could automate it without too much effort, but that would probably require that we split the changelog into separate files for each version, or we would need to do some parsing, not sure how "hard" that would be.

Lut99 commented 1 day ago

I can live with editing releases after they are there. Probably not worth it to go and write a parser for the CHANGELOG file xD

(DON'T do it Tim. Don't do it. You have enough parsers to write. :P)

Lut99 commented 1 day ago

Also, to continue your question from https://github.com/epi-project/brane/issues/77#issuecomment-2196788803...

That brings me to a semi-related question, I noticed that make.py does a cross compile for the macOS builds / windows builds. I am pretty sure using zig. Is there a reason for this?

Using CD we can just use the GitHub macOS runners to build the artifacts on the native platform. Or am I missing something here? And the same for windows of course. Different architectures should not be too much trouble as we can just compile those with a Cargo target afaik, and using cross otherwise.

Well, cross-compiling has always been a bit of a headache... xD Obviously, GitHub CI/CD didn't work before, so I was left compiling everything manually. Back when I just started, I looked at it, but it turned out that cross-compilation was a nightmare in Rust itself due to all the system libraries we depend on. Then I used to borrow mac mini's for a while to compile for M{1,2,3} architectures, but at some point that stopped too. Then I read somewhere that Zig could do the trick too and I can't remember if that worked xD but I guess so, if I didn't rollback.

Anyway ~ history aside, yeah I'm fine with whatever. I think just compiling natively on GitHub's runners is the way to go. The only reason we might need actual cross-compilation is if an aarch64 macbook wants to compile instance images for running on an x86/64 machine, which used to happen back in the days of Web Services and Cloud-Based Systems where the VMs were actually too low on storage to compile the images themselves. But I don't think it's a use-case we need to explicitly support anymore; once we have the release thing working, people can just download that or the latest weekly images if necessary.