search

cross-language-cpp / djinni-generator

Command-line tool that generates gluecode from a djinni-IDL file
https://djinni.xlcpp.dev/djinni-generator/setup
Apache License 2.0
92 stars 19 forks source link

CD deploy main branch, initial step #138

Closed a4z closed 1 year ago

a4z commented 1 year ago

Each successful commit to master uploads a djinni binary as a pre-release release. Any existing pre-release release will be replaced.

That should be the first step to solving the issue discussed in #94

With this change, no release is needed anymore. A simple curl -LJO https://github.com/https://github.com/cross-language-cpp/djinni-generator/releases/download/current-latest/djinni will give the latest djinni build.

The usage of that needs, of course, to be implemented in the support-lib CI.

More variations of the topic are possible, e.g., pre-releasing branches under a special name, and if support lib knows that name it does not even have to wait for a merge to main.

jothepro commented 1 year ago

Nice! This will definitely allow us to move forward faster.

Would the support-lib then always reference the latest version? Maybe it would make sense to have this behavior in feature branches and require a pinned version in the main branch?

Does the pre-release create a notification if one has subscribed to the repository?

a4z commented 1 year ago

Glad you like it!

Would the support-lib then always reference the latest version? Maybe it would make sense to have this behavior in feature branches and require a pinned version in the main branch?

Yes, there are options :-)
A support-lib release build (tag) should be test-built with the current generator release.

The main branch in the support-lib should possibly stay on the latest. We could make that configurable, but that's a resource question. We have no resources, and I guess that's the answer :-)

PRs should stick to the latest, except we plan to make LTS version support, which will never happen.

Does the pre-release create a notification if one has subscribed to the repository?

I don't know, we will see

a4z commented 1 year ago

K, let's see. It would be unfortunate if it created a notification on each merge into main, but in that case we can still revert the change I guess?

I do not think that we will revert the change since it's needed. But after thinking about it, I do also not think that this will create notifications, since this does pre-releases, not releases So that should be configurable on the consumer side, I guess.