-
Notifications
You must be signed in to change notification settings - Fork 543
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CI] extract profile settings and build docker based on its values #13782
Conversation
!ci-build-me |
4b6a0d7
to
8ea7959
Compare
!ci-build-me |
!ci-build-me |
1 similar comment
!ci-build-me |
!ci-build-me |
1 similar comment
!ci-build-me |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The mechanics of this PR are much needed, but I am unsure how to reconcile the changes to deb and docker names, with how these packages are being used publicly.
I double-checked the build steps running in compatible
, to see if we are actively using the dune profile, but these CI jobs also use devnet
flags. The functionality appears to be only a placeholder (at least within CI). Devnet+Berkeley may cause confusion internally as well, since devnet
internally refers to the devnet testnet (which is a deployment based on compatible). Devnet = compatible and Develop = berkeley.
Would it provide a similar result to add an isolated build step for the lightnet container, while not modifying the existing deb and docker builds?
@@ -0,0 +1,25 @@ | |||
let Prelude = ../External/Prelude.dhall | |||
|
|||
let ProfileName = < Devnet | Lightnet | Hardfork > |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hardfork profile, nice!
] | ||
let dependsOnJs = [ | ||
{ name = "TestnetIntegrationTests", key = "build-test-executive" }, | ||
{ name = "TestnetIntegrationTests", key = "build-js-tests" }, | ||
{ name = "MinaArtifactBullseye", key = "daemon-berkeley-bullseye-docker-image" }, | ||
{ name = "MinaArtifactBullseye", key = "archive-bullseye-docker-image" } | ||
{ name = "MinaArtifactBullseyeLightnet", key = "daemon-berkeley-bullseye-devnet-docker-image" }, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we able to use ${deb_profile}, ${DUNE_PROFILE}, or other var name in place of hardcoding devnet
for docker container names?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will remove devnet segment in key name
scripts/rebuild-deb.sh
Outdated
|
||
copy_common_daemon_configs berkeley testnet 'seed-lists/berkeley_seeds.txt' | ||
|
||
build_deb mina-berkeley | ||
build_deb "mina-berkeley-${DUNE_PROFILE}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For additional consideration, this may have impact for community users who has automations hardcoded to specific release channels. For example, it is possible that Coinbase builds their own containers, for the purpose of including additional tooling/monitoring. In this scenario, their automations may be coded to apt install mina-berkeley.deb
or similar. Externally, I am unsure of how to reconcile this. Even though it can be included in release notes, large companies often will not follow every release, or catch that the deb name has changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right! I will add suffix only if the profile is different than devnet to assure compatibility
4ebd90b
to
10f63d5
Compare
!ci-build-me |
10 similar comments
!ci-build-me |
!ci-build-me |
!ci-build-me |
!ci-build-me |
!ci-build-me |
!ci-build-me |
!ci-build-me |
!ci-build-me |
!ci-build-me |
!ci-build-me |
1da28d1
to
f58a2fa
Compare
!ci-build-me |
!ci-build-me |
1 similar comment
!ci-build-me |
ea811eb
to
f9b5281
Compare
!ci-build-me |
1 similar comment
!ci-build-me |
!ci-build-me |
48f4591
to
d58d24c
Compare
d58d24c
to
aee05d8
Compare
!ci-build-me |
…to dkijania/mina-profile-docker
!ci-build-me |
!ci-build-me |
!ci-build-me |
!ci-build-me |
!approved-for-mainnet |
Explain your changes:
Exposed profile as parameter rather than hardcoded value in infra. As a consequence we will have set of dockers for each profile we define and would like to use
Explain how you tested your changes:
Run CI
Checklist: