refactor: use Burrito for packaging #22
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
doorgan
force-pushed
the
doorgan/burrito_packaging
branch
3 times, most recently
from
327323d to
2c94e28
Compare
doorgan
force-pushed
the
doorgan/burrito_packaging
branch
from
4d8aed0 to
32644c2
Compare
doorgan
force-pushed
the
doorgan/burrito_packaging
branch
2 times, most recently
from
1864da9 to
0047f4d
Compare
doorgan
changed the title
doorgan
force-pushed
the
doorgan/burrito_packaging
branch
6 times, most recently
from
a1101ae to
2ff1264
Compare
doorgan
force-pushed
the
doorgan/burrito_packaging
branch
from
a7a7498 to
15ce974
Compare
doorgan
force-pushed
the
doorgan/burrito_packaging
branch
from
15ce974 to
3043a23
Compare
* refactor: integrate GenLSP * fixup!: fix tests * fixup!: use persistent_term instead of adding .lsp to Project * fixup!: fix dialyzer issues * fixup!: Don't use parenthesis on 0-arity function * fixup!: cleanup credo changes * fixup!: Remove outdated comments * fixup!: use info severity for normal shutdown log * fixup!: cleanup credo changes * refactor: isolate Engine from Expert * refactor: rename project node modules and simplify EngineApi/EngineNode code * refactor: use Burrito for packaging * chore: update github release workflow * feat: add plain(non burrito) releases * chore: Remove release-please-action * chore: Remove build/release tasks * chore: fix unordered aliases * chore: update lockfile * fix: rollback change to elixir version * chore: remove ci integration tests Using burrito we're no longer trying to activate the user's elixir executable on boot, making those tests stale * Revert changes to the release workflow It will be done in a follow-up PR * chore: add ci test for release builds * wip --------- Co-authored-by: doorgan <dorgandash@gmail.com>
Member
|
To recap the trouble I have been having testing this locally on x86_64 linux:
I am left with confusion why it passed in CI, but can't seem to pass for me locally. Digit is going to investigate, and I am going to invite him to the repository so it's easier for him. |
Member
Digit was able to get it to wrap in a VM, so I'm just going to classify this as I'm cursed and I'll figure it out later |
mhanberg
approved these changes
Jul 19, 2025
Member
mhanberg
left a comment
mhanberg
left a comment
There was a problem hiding this comment.
Seems fine burrito wise, please merge at your discretion.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Updates Expert to use Burrito for packaging
This builds both Expert and Engine with the same elixir and otp versions, the idea is that next we will build several Engine versions in CI and Expert will download the right one for the current project, or default to the one included in it.
To build a release for your machine:
To build releases for macos, linux and windows:
To only build Engine(this will generate namespaced files at
apps/engine/_build/dev_ns:Note that Engine will be built for
devand notprod, this is because it makes use ofMix.Projectand related code, which would not be available if it were build withprod. The idea behind this command is that we will have a CI step on release that will runmake build.engineagainst a matrix of supported elixir+otp versions and publish those artifacts, which Expert will then download so it matches the exact project versions.There are some other relatively minor differences or things to note:
debug_shell.shscript in it, as far as I can see. We need to rethink how to do this, we can still connect an observer to the server node with:observer.start(:"manager-project-entropy@127.0.0.1")but I'm not sure how to open a remote session like one would with a regular release script.Engine.Api). Because that code was moved to Expert and is no longer accessible by Engine, those tests were moved to Expert to avoid circular dependencies on tests.