Set up CI and releases with Azure Pipelines by tschneidereit · Pull Request #237 · bytecodealliance/wasmtime

tschneidereit · 2019-08-01T21:39:26Z

This Azure Pipelines setup compiles and tests Wasmtime for Linux, macOS, and Windows.

If the CI run was triggered by a new tag being created, a new release for that tag is created with a changelog relative to the last tag release and archives of the builds for all platforms.

If the CI run was triggered by new commits landing on master, the release latest-master is updated with a new changelog relative to the last tag release and archives of the new builds for all platforms.

Note: This PR also contains changes to disable a bunch of tests on Windows, which are failing due to issues with signal handling.

kubkon · 2019-08-01T21:44:27Z

Awesome! @tschneidereit are you able to disable Travis as the required CI for this repo and instead make Azure required? Alas, I lack permissions to do this. Anyhow, I hope you won't mind when I nick your config and port it over to wasi-common, unless you've already started working on it yourself?

tschneidereit · 2019-08-01T21:51:17Z

Awesome! @tschneidereit are you able to disable Travis as the required CI for this repo and instead make Azure required?

Yes, I'll do that once we have this all running as expected.

I hope you won't mind when I nick your config and port it over to wasi-common, unless you've already started working on it yourself?

Not at all! :) I haven't started on that, and would in fact be very glad if you did the port. Let me know once you have it working on your fork, and I'll set up the pipeline here.

tschneidereit · 2019-08-01T21:51:56Z

@alexcrichton, could you take a look and see if this all seems good to you?

kubkon · 2019-08-01T21:53:47Z

Awesome! @tschneidereit are you able to disable Travis as the required CI for this repo and instead make Azure required?

Yes, I'll do that once we have this all running as expected.

Great!

I hope you won't mind when I nick your config and port it over to wasi-common, unless you've already started working on it yourself?

Not at all! :) I haven't started on that, and would in fact be very glad if you did the port. Let me know once you have it working on your fork, and I'll set up the pipeline here.

Will do! :-)

alexcrichton

Looks great to me! I mostly have random stylistic comments, and can handle them later myself for sure.

Do you want to go ahead and enable Azure Pipelines for this repo? I think this'll want to delete the travis/appveyor configs as well?

alexcrichton · 2019-08-02T15:06:18Z

.azure-pipelines.yml

+    - checkout: self
+      submodules: true
+    - script: |
+        curl https://sh.rustup.rs -sSf | sh -s -- -y --default-toolchain $RUSTUP_TOOLCHAIN


I might recommend a snippet like https://github.com/rust-lang/git2-rs/blob/1d33b290e034d0d85ac0e4bc0ac64cebfa8cfbc7/ci/azure-install-rust.yml to install Rust since rustup is already installed on some systems and I've seem some weirdness when two rustup installations get overlaid over one another.

.azure-pipelines.yml

alexcrichton · 2019-08-02T15:08:18Z

.azure-pipelines.yml

+        rustup_toolchain: beta
+      mac-nightly:
+        imageName: 'macos-10.14'
+        rustup_toolchain: nightly


I personally like a stylistic strategy like https://github.com/rust-lang/git2-rs/blob/1d33b290e034d0d85ac0e4bc0ac64cebfa8cfbc7/azure-pipelines.yml where one-off jobs have their own job entry and groups of jobs have their own matrix entry. I find that putting everything into the same matrix makes for some pretty gnarly condition entires and lots of if-this-else-that in the config.

This is totally fine to be clear, just figured I'd mention that this may be a way to simplify the config below.

alexcrichton · 2019-08-02T15:10:23Z

.azure-pipelines.yml

+
+    - bash: |
+        set -e
+        sudo apt-get install sccache -y


FWIW I'd recommend using the same sccache version across all the platforms to ensure consistency.

I also personally like to extract these sorts of isolated steps to separate files which may work well here too?

(it's probably also better to use the official sccache release binaries instead of the custom ones for rust-lang/rust)

I changed this to use the official sscache releases from github. That sort of works, except Windows breaks in all kinds of interesting ways now, and for some reason the cache doesn't actually work. (See the sccache and pre-compile sccache stats tasks in this build: the cache is restored, but sccache thinks it's empty.)

I disabled the entire cache for now: runs take 15 minutes, with Windows release builds being the long pole, and that seems acceptable for the time being.

alexcrichton · 2019-08-02T15:17:40Z

.azure-pipelines.yml

+        rootFolderOrFile: $(Build.BinariesDirectory)/bundle
+        includeRootFolder: false
+        archiveType: 'zip'
+        archiveFile: '$(Build.ArtifactStagingDirectory)/wasmtime-windows-64bit-$(tagName).zip'


Naming-scheme-wise I personally like how Rust ended up with:

$thing-$tag-$target.tar.gz

such as

wasmtime-master-x86_64-pc-windows-msvc.tar.gz

since that allows ARM64, for example, to not conflict with "windows-64bit" which is ambiguous if more support is added.

I wanted the names to be as simple as possible, but yeah: the Arm/x64 collision is unfortunate, as we do definitely want to support Arm64 (and 32, and x86-32) soon/

.azure-pipelines.yml

alexcrichton · 2019-08-02T15:24:42Z

.azure-pipelines.yml

+
+- job: Publish
+  dependsOn: Build
+  condition: and(succeeded(), in(variables['Build.Reason'], 'IndividualCI', 'BatchedCI'))


I haven't actually seen this before in terms of Build.Reason, what's that doing?

This makes it so the Publish job is only run if CI was triggered by a merge to a branch (in this case, master) or a tag. Without this condition, we'd run it even for PRs, which doesn't seem ideal :)

.azure-pipelines.yml

alexcrichton · 2019-08-02T15:27:17Z

.azure-pipelines.yml

+      title: 'Wasmtime $(tagName)'
+      assets: '$(Build.ArtifactStagingDirectory)/**'
+      isDraft: true
+      isPreRelease: true


Should this and isDraft be false since this is an official release? Should the isDraft below for master be true?

isDraft means that the release isn't publicly visible at all. isPreRelease is what indicates it's not an "official" release, I guess?

The idea was to have the master branch be a rolling release that happens immediately, whereas the tag releases would be drafts until a human pushes a button. However, I think for the time being we can just make them public immediately: it's better to have any releases than not to have them :)

For the time being these are all pre-releases, so I'll leave them marked as such.

This Azure Pipelines setup compiles and tests Wasmtime for Linux, macOS, and Windows. If the CI run was triggered by a new tag being created, a new release for that tag is created with a changelog relative to the last tag release and archives of the builds for all platforms. If the CI run was triggered by new commits landing on `master`, the release `latest-master` is updated with a new changelog relative to the last tag release and archives of the new builds for all platforms. Note: This PR also contains changes to disable a bunch of tests on Windows, which are failing due to issues with signal handling.

tschneidereit · 2019-08-03T14:16:17Z

I merged this after addressing many, but not all of the comments. As @alexcrichton says, the rest can be done as follow-ups.

Specify the `uimm12_scaled_from_i64` term, which opens up verification of memory operations that involve `AMode.UnsignedOffset`. Updates bytecodealliance#225

…er-mut-self Migrate `StreamWriter` methods to `&mut self`

kubkon approved these changes Aug 1, 2019

View reviewed changes

kubkon mentioned this pull request Aug 2, 2019

Add azure pipelines definition CraneStation/wasi-common#49

Merged

alexcrichton approved these changes Aug 2, 2019

View reviewed changes

tschneidereit force-pushed the ci-source branch from 5a55fbe to a4bc4e0 Compare August 3, 2019 11:15

tschneidereit merged commit a988443 into bytecodealliance:master Aug 3, 2019

tschneidereit deleted the ci-source branch August 3, 2019 11:41

dhil added a commit to dhil/wasmtime that referenced this pull request Oct 11, 2024

Merge with upstream (bytecodealliance#237)

04e1411

dicej pushed a commit to dicej/wasmtime that referenced this pull request Jul 17, 2025

Merge pull request bytecodealliance#237 from alexcrichton/stream-writ…

be2c10c

…er-mut-self Migrate `StreamWriter` methods to `&mut self`

Conversation

tschneidereit commented Aug 1, 2019

Uh oh!

kubkon commented Aug 1, 2019

Uh oh!

tschneidereit commented Aug 1, 2019

Uh oh!

tschneidereit commented Aug 1, 2019

Uh oh!

kubkon commented Aug 1, 2019

Uh oh!

alexcrichton left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tschneidereit commented Aug 3, 2019

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants