Skip to content
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.

Sign up for GitHub

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

split: flat(ter) files in Artifactory #12575

Merged
merged 1 commit into from
Jan 25, 2022
Merged

split: flat(ter) files in Artifactory #12575

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 7 additions & 2 deletions ci/publish-artifactory.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -65,7 +65,12 @@ else
# For the split release process, we publish intermediate artifacts to the
# assembly repo, under the daml folder.
cd $STAGING_DIR/split-release
for file in $(find . -type f); do
push assembly/daml $file
for d in split-release github; do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My thinking here was to split them so the assembly repo can be fairly opaque to the actual artifacts (which is important for automation) and not worry about what happens if we add a new artifact to the github release or the inverse add a file which needs to be used somewhere in between, e.g., the Canton release but should not be part of the Github release (e.g. an EE damlc or whatever).

Not opposed to keeping it flat but I think it’s worth thinking through how we want to handle this type of stuff without breaking everything.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As it stands, the existing split is not helpful in the assembly repo. We could probably devise one that is, but at this point I'm not sure we know enough about the future.

A flat list does imply the assembly repo will need to know version-specific stuff, but that ship has already sailed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess I should be more explicit: the current split does require the assembly repo to explicitly list the artifacts it pulls out of Artifactory. Given that, a flat list seems easier to handle. That also works well with being transparent to new artifacts being added to the list for intermediate use.

It does mean if we want to add things to the GitHub release, we'll need to make the assembly repo aware of that, hence the version-dependent information I mentioned.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alright, probably worth documenting the process of adding new files somewhere

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As soon as it exists! 😅

That part is somewhat blocked on the Canton EE artifacts right now.

(
cd $d
for file in $(find . -type f); do
push assembly/daml $file
done
)
done
fi