Fix versioning issues for publishing to Azure Marketplace #687
Conversation
willdavsmith
commented
Oct 31, 2023
willdavsmith
commented
- Fix versioning issue - Radius Bicep release version should no longer be suffixed with git hash info
- Update base icon for publishing
- Remove azure blob storage uploads and other old stuff
- Fix some formatting
willdavsmith
force-pushed
the
willdavsmith/marketplace
branch
from
80fc878
to
026864f
Compare
| - uses: oras-project/setup-oras@v1 | ||
| with: | ||
| version: ${{ env.ORAS_VERSION }} | ||
| - run: oras version | ||
| - name: Push rad bicep binaries to GHCR (${{ matrix.runtime.name }}) | ||
| run: | | ||
| cd ./artifacts/bicep/${{ matrix.runtime.name }} && oras push --annotation "org.opencontainers.image.source=${{ env.IMAGE_SRC }}" ${{ env.CONTAINER_REGISTRY }}/bicep/rad-bicep/${{ matrix.runtime.name }}:${{ env.UPDATE_RELEASE == 'true' && env.REL_CHANNEL || 'latest' }} ./rad-bicep${{ matrix.runtime.extension }} |
There was a problem hiding this comment.
Why are we removing this logic? What cases does this run for?
There was a problem hiding this comment.
So this is only publishing to the latest tag now? Don't we need to publish with the release version too since downloads in the radius repo expect a release version tag?
There was a problem hiding this comment.
yes, I looked into it more and looks like we still need this. adding it back in
There was a problem hiding this comment.
Feel free to separate this into separate steps if it makes sense.
Example:
# We publish `rad-bicep` on every push to main so that it can be used by tests, and
# installed by dev-builds of Radius.
- name: publish binaries for push to main (latest)
...
# We publish `rad-bicep` for each release so it can be installed by release-builds of
# Radius.
- name: publish binaries for tagged release (vX.Y)
...Just an idea, its more code but its also more self-documenting. Comments help a lot too, especially if we can explain why something needs to be done.
Making the differences clear in the code, can make it harder for someone to break in the future.
| @@ -167,28 +168,13 @@ jobs: | |||
| - name: Build prod | |||
| run: npm run build:prod | |||
| working-directory: ./src/vscode-bicep | |||
|
|
|||
| # Comment out while we troubleshoot the root cause of e2e errors | |||
There was a problem hiding this comment.
we've had these commented out for a long time. doesn't look like we have a backlog item to address it
There was a problem hiding this comment.
I think this is fine, we have a timeframe already for deleting our Bicep fork.
Signed-off-by: willdavsmith <[email protected]>
Signed-off-by: willdavsmith <[email protected]>
Signed-off-by: willdavsmith <[email protected]>
Signed-off-by: willdavsmith <[email protected]>
willdavsmith
force-pushed
the
willdavsmith/marketplace
branch
from
e7b1d78
to
570124d
Compare
| extra_args: "--destination-path ./vscode-extensibility/${{ env.REL_CHANNEL }}/ --overwrite true" | ||
| sync: true | ||
|
|
||
| # Logic: If this is a real release (tagged, non-rc) then compare to our existing full |
There was a problem hiding this comment.
Why is this being removed? Seems like we should just update to check from the GHCR uploads?
There was a problem hiding this comment.
all of these steps reference our old azure storage blobs and version marker. we already upload everything to GHCR and github releases now, hopefully we don't depend on these resources anymore. is there something I'm missing?
There was a problem hiding this comment.
No, not necessarily. This step just seems to be making sure we're not overwriting the current release with an old version. So the question was more so should we keep this step but just reference the github release version instead of from blob storage. The steps where an upload to blob storage happens make sense to delete
There was a problem hiding this comment.
talked offline, looks like we're good here
willdavsmith
merged commit 9dc3331
into
radius-project:bicep-extensibility
