digital-asset/daml
1
1
Fork 0
mirror of https://github.com/digital-asset/daml.git synced 2024-09-19 16:57:40 +03:00
Code Issues Projects Releases Wiki Activity
89f0dad016
daml/ci/copy-windows-release-artifacts.sh

21 lines
765 B
Bash
Raw Normal View History

Move artifact publishing out of yaml files (#9071) * Move artifact publishing out of yaml files The current publishing process pretty much hardcodes the set of artifacts we publish in the yaml config. This is a problem because we always release from `main` so the yaml files are always identical. However, we will add new artifacts over time and this starts falling apart. This PR changes this such that the process described in the yaml files is very generic and just uploads and downloads everything in a directory whereas the details are handled in bash scripts that will come from the respective release branch and are therefore version-dependent. As usual for these type of changes, I don’t have a great way to test this. I did do some due diligence to test that at least the artifacts are published correctly and I can download them but I can’t test the actual publishing. changelog_begin changelog_end * Update ci/copy-unix-release-artifacts.sh Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com> * Update ci/copy-windows-release-artifacts.sh Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com> * Update ci/publish-artifactory.sh Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com> Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
2021-03-11 13:44:02 +03:00
#!/usr/bin/env bash
bump copyright (#16002) This is the result of: - Updating `./COPY` to say `2023`. - Running `./dev-env/bin/dade-copyright-headers update .`
2023-01-04 20:21:15 +03:00
# Copyright (c) 2023 Digital Asset (Switzerland) GmbH and/or its affiliates. All rights reserved.
Move artifact publishing out of yaml files (#9071) * Move artifact publishing out of yaml files The current publishing process pretty much hardcodes the set of artifacts we publish in the yaml config. This is a problem because we always release from `main` so the yaml files are always identical. However, we will add new artifacts over time and this starts falling apart. This PR changes this such that the process described in the yaml files is very generic and just uploads and downloads everything in a directory whereas the details are handled in bash scripts that will come from the respective release branch and are therefore version-dependent. As usual for these type of changes, I don’t have a great way to test this. I did do some due diligence to test that at least the artifacts are published correctly and I can download them but I can’t test the actual publishing. changelog_begin changelog_end * Update ci/copy-unix-release-artifacts.sh Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com> * Update ci/copy-windows-release-artifacts.sh Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com> * Update ci/publish-artifactory.sh Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com> Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
2021-03-11 13:44:02 +03:00
# SPDX-License-Identifier: Apache-2.0
set -eou pipefail
RELEASE_TAG=$1
OUTPUT_DIR=$2
split: do not push exe (#12574) In the split release process, the executable installer has to be created later in the pipeline, once we have the Canton parts available. CHANGELOG_BEGIN CHANGELOG_END
2022-01-25 18:29:57 +03:00
SPLIT_RELEASE=${3:-false}
Move artifact publishing out of yaml files (#9071) * Move artifact publishing out of yaml files The current publishing process pretty much hardcodes the set of artifacts we publish in the yaml config. This is a problem because we always release from `main` so the yaml files are always identical. However, we will add new artifacts over time and this starts falling apart. This PR changes this such that the process described in the yaml files is very generic and just uploads and downloads everything in a directory whereas the details are handled in bash scripts that will come from the respective release branch and are therefore version-dependent. As usual for these type of changes, I don’t have a great way to test this. I did do some due diligence to test that at least the artifacts are published correctly and I can download them but I can’t test the actual publishing. changelog_begin changelog_end * Update ci/copy-unix-release-artifacts.sh Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com> * Update ci/copy-windows-release-artifacts.sh Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com> * Update ci/publish-artifactory.sh Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com> Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
2021-03-11 13:44:02 +03:00
mkdir -p $OUTPUT_DIR/github
ci/windows: add missing mkdir (#9103) CHANGELOG_BEGIN CHANGELOG_END
2021-03-11 21:16:19 +03:00
mkdir -p $OUTPUT_DIR/artifactory
Add artifactory & SDK EE artifacts to split-release process (#12345) Apologies for doing two things in one PR but they seemed somewhat entangled. For artifactory we follow the approach we use for Maven artifacts and publish there directly. For the SDK EE tarball, we just throw it in the split-release directory and then the assembly repo can pick it up. changelog_begin changelog_end
2022-01-11 14:55:14 +03:00
mkdir -p $OUTPUT_DIR/split-release
new windows signing (#9786) CHANGELOG_BEGIN CHANGELOG_END
2021-05-25 17:23:17 +03:00
Move artifact publishing out of yaml files (#9071) * Move artifact publishing out of yaml files The current publishing process pretty much hardcodes the set of artifacts we publish in the yaml config. This is a problem because we always release from `main` so the yaml files are always identical. However, we will add new artifacts over time and this starts falling apart. This PR changes this such that the process described in the yaml files is very generic and just uploads and downloads everything in a directory whereas the details are handled in bash scripts that will come from the respective release branch and are therefore version-dependent. As usual for these type of changes, I don’t have a great way to test this. I did do some due diligence to test that at least the artifacts are published correctly and I can download them but I can’t test the actual publishing. changelog_begin changelog_end * Update ci/copy-unix-release-artifacts.sh Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com> * Update ci/copy-windows-release-artifacts.sh Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com> * Update ci/publish-artifactory.sh Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com> Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
2021-03-11 13:44:02 +03:00
TARBALL=daml-sdk-$RELEASE_TAG-windows.tar.gz
Release EE SDK tarballs and installer (#9086) * Release EE SDK tarballs and installer As before, no way of testing this. I’ll do a snapshot afterwards. changelog_begin changelog_end * . changelog_begin changelog_end * . changelog_begin changelog_end * Rename EE artifacts changelog_begin changelog_end
2021-03-11 16:49:48 +03:00
EE_TARBALL=daml-sdk-$RELEASE_TAG-windows-ee.tar.gz
cp bazel-bin/release/sdk-release-tarball-ce.tar.gz "$OUTPUT_DIR/github/$TARBALL"
Add artifactory & SDK EE artifacts to split-release process (#12345) Apologies for doing two things in one PR but they seemed somewhat entangled. For artifactory we follow the approach we use for Maven artifacts and publish there directly. For the SDK EE tarball, we just throw it in the split-release directory and then the assembly repo can pick it up. changelog_begin changelog_end
2022-01-11 14:55:14 +03:00
# Used for the non-split release process.
Release EE SDK tarballs and installer (#9086) * Release EE SDK tarballs and installer As before, no way of testing this. I’ll do a snapshot afterwards. changelog_begin changelog_end * . changelog_begin changelog_end * . changelog_begin changelog_end * Rename EE artifacts changelog_begin changelog_end
2021-03-11 16:49:48 +03:00
cp bazel-bin/release/sdk-release-tarball-ee.tar.gz "$OUTPUT_DIR/artifactory/$EE_TARBALL"
Add artifactory & SDK EE artifacts to split-release process (#12345) Apologies for doing two things in one PR but they seemed somewhat entangled. For artifactory we follow the approach we use for Maven artifacts and publish there directly. For the SDK EE tarball, we just throw it in the split-release directory and then the assembly repo can pick it up. changelog_begin changelog_end
2022-01-11 14:55:14 +03:00
# Used for the split release process.
cp bazel-bin/release/sdk-release-tarball-ee.tar.gz "$OUTPUT_DIR/split-release/$EE_TARBALL"
Reference in New Issue Copy Permalink