Re-organize workflows and releasing process #202
Conversation
|
|
||
| # Due to EigenSDK package differences on Ethereum mainnet, | ||
| # this workflow ensures the mainnet branch stays in sync with main | ||
| # while maintaining its own Docker image tag. |
There was a problem hiding this comment.
The original mainnet.yml is deleted and triggered manually by update-docker-mainnet.yml on-demand instead.
| | Staging | `staging` | `avaprotocol/ap-avs-staging` | `commit-hash` | GA: `update-docker-staging` | Automatic on PR merge to staging branch | | ||
| | Production | `main` | `avaprotocol/ap-avs` | `x.y.z` (semantic version) | GA: `release-and-update-docker` | Automatic on PR merge from staging to main | | ||
| | Mainnet | `mainnet` | `avaprotocol/ap-avs` | `mainnet` | GA: `update-docker-mainnet` | Manual trigger to sync main to mainnet and deploy | | ||
|
|
There was a problem hiding this comment.
@v9n, could you walk through this file to see if anything wrong with the plan?
- There meant be no changes to docker image or tags to the current production images.
- Question: Does the
deploy-ethereum.ymldepends on theavaprotocol/ap-avs@mainnetdocker image? If so, I need to update the flow to auto-update the@mainnettag first, before running deploy. - The operators only need to care about
avaprotocol/ap-avs@mainnet? They run only the operator program, right? Does theavaprotocol/ap-avs@mainnetcontain both aggregator and operator?
|
|
||
| - name: Run semantic versioning and release | ||
| id: semantic-release | ||
| uses: go-semantic-release/action@v1 |
There was a problem hiding this comment.
The go-semantic-release library will replace the existing tagging process offered by the Go native method. It enforces version format, auto-bump versions, and create a release.
The scripts are not tested yet, but if the plan in RELEASE.md makes sense I will test and finalize them.
|
|
||
| on: | ||
| push: | ||
| branches: | ||
| - staging |
There was a problem hiding this comment.
The staging Docker image is updated after each PR merge. This branch serves as a caching and testing pool before changes are merged into main, which basically means the code goes live.
| uses: docker/build-push-action@v6 | ||
| with: | ||
| build-args: | | ||
| RELEASE_TAG=${{ inputs.tag || github.sha || github.head_ref || github.ref_name }} | ||
| RELEASE_TAG=staging-${{ github.sha }} |
There was a problem hiding this comment.
i thinkwe should keep:
- branch-name: so we can pin toward
avaprotocol/avs-dev:test-my-new-featureinstead of manuallly update your code everytime to point to new sha - really userful to have the abilitty to trigger build with dispatch and set the tag yourself.
| tags: | | ||
| avaprotocol/ap-avs:mainnet | ||
| build-args: | | ||
| RELEASE_TAG=mainnet-${{ github.sha }} |
There was a problem hiding this comment.
not github.sha. should be the tag so we can have mainnet as latest and mainnet-1.5.0 and mainnet-1.6.0.
we don't usually need mainnet-abcdef for mainnet.
| uses: docker/build-push-action@v6 | ||
| with: | ||
| build-args: | | ||
| RELEASE_TAG=${{ github.sha }} |
| name: 'Base' | ||
| environment: 'Base' | ||
| directory: 'base' | ||
| - id: 'deploy-ethereum.yml' |
There was a problem hiding this comment.
base and ethereum should be trigger after we release the mainnet branc docker image. otherwise they will not be up to date. so you may want to move these to run after update-docker-mainnet
chrisli30
force-pushed
the
staging
branch
2 times, most recently
from
7422b32 to
63bc1de
Compare
No description provided.