10f27197b5
This commit migrates wasmtime's CI infrastructure from Azure Pipelines to Github Actions. Using Github Actions has a few benefits over other offerings: * Being natively integrated with Github means that there's no degree of user account configuration or access control management, it's all inherent via already existing Github permissions. * Github Actions gives 20 parallel builders instead of Azure's 10 by default, which is a nice boost to have! Overall I've found Github Actions to feel a bit cleaner than Azure Pipelines as well. Subjectively I've found the configuration to be more readable and more pleasant to work with, although they're both just as "powerful" I think. Additionally Github Actions has been pretty solid in my own personal testing for a number of other projects. The main trickiness with wasmtime's CI is the rolling `dev` release of the master branch as well as binary releases for tags. Github Actions doesn't have quite as much built in functionality as Azure Pipelines, but Github Actions does have a nice feature where you can define the code for an action locally rather than only using built-in actions. This migration adds three local actions with some associated JS code to run the action (currently it looks like it basically requires JS) * An `install-rust` action papers over the gotchas about installing Rust, allowing Rust installation to be a one-liner in the configuration. * A `binary-compatible-builds` action allows easily configuring the wheels and the binaries to be "more binary compatible" and handles things like compilation flags on OSX and Windows while handling the `centos:6` container on Linux. * The `github-release` action is the logic using the `@actions/github` JS package to orchestrate the custom way we manage rolling releases, ensuring that a new release is made for the master branch under `dev` (deleting the previous tag/release ahead of time) and then also manages tagged releases by uploading them there. I'm hoping that most of the inline actions here will largely go away. For example `install-rust` should be simply `rustup update $toolchain` once various environment issues are fixed on Github Actions runner images. Additionally `github-release` will ideally migrate to something like https://github.com/actions/create-release or similar once it has enough functionality. I'm also hoping that the maintenance in the meantime of these actions is pretty low-cost, but if it becomes an issue we can look into other solutions!
92 lines
2.8 KiB
JavaScript
92 lines
2.8 KiB
JavaScript
const core = require('@actions/core');
|
|
const path = require("path");
|
|
const fs = require("fs");
|
|
const github = require('@actions/github');
|
|
const glob = require('glob');
|
|
|
|
async function run() {
|
|
// Load all our inputs and env vars. Note that `getInput` reads from `INPUT_*`
|
|
const files = core.getInput('files');
|
|
const name = core.getInput('name');
|
|
const token = core.getInput('token');
|
|
const slug = process.env.GITHUB_REPOSITORY;
|
|
const owner = slug.split('/')[0];
|
|
const repo = slug.split('/')[1];
|
|
const sha = process.env.GITHUB_SHA;
|
|
|
|
core.info(`files: ${files}`);
|
|
core.info(`name: ${name}`);
|
|
core.info(`token: ${token}`);
|
|
|
|
const octokit = new github.GitHub(token);
|
|
|
|
// If this is a `dev` release then we need to actually delete the previous
|
|
// release since we can't overwrite a new one. We also need to update the
|
|
// `dev` tag while we're at it. So here you'll see:
|
|
//
|
|
// * Look for the `dev` release, then delete it if it exists
|
|
// * Update the `dev` release to our current sha, or create one if it doesn't
|
|
// exist
|
|
if (name == 'dev') {
|
|
const releases = await octokit.paginate("GET /repos/:owner/:repo/releases", { owner, repo });
|
|
for (const release of releases) {
|
|
if (release.tag_name !== 'dev') {
|
|
continue;
|
|
}
|
|
const release_id = release.id;
|
|
core.info(`deleting release ${release_id}`);
|
|
await octokit.repos.deleteRelease({ owner, repo, release_id });
|
|
}
|
|
|
|
try {
|
|
core.info(`updating dev tag`);
|
|
await octokit.git.updateRef({
|
|
owner,
|
|
repo,
|
|
ref: 'tags/dev',
|
|
sha,
|
|
force: true,
|
|
});
|
|
} catch (e) {
|
|
console.log("ERROR: ", JSON.stringify(e, null, 2));
|
|
core.info(`creating dev tag`);
|
|
await octokit.git.createTag({
|
|
owner,
|
|
repo,
|
|
tag: 'dev',
|
|
message: 'dev release',
|
|
object: sha,
|
|
type: 'commit',
|
|
});
|
|
}
|
|
}
|
|
|
|
// Creates an official GitHub release for this `tag`, and if this is `dev`
|
|
// then we know that from the previous block this should be a fresh release.
|
|
core.info(`creating a release`);
|
|
const release = await octokit.repos.createRelease({
|
|
owner,
|
|
repo,
|
|
tag_name: name,
|
|
prerelease: name === 'dev',
|
|
});
|
|
|
|
// Upload all the relevant assets for this release as just general blobs.
|
|
for (const file of glob.sync(files)) {
|
|
const size = fs.statSync(file).size;
|
|
core.info(`upload ${file}`);
|
|
await octokit.repos.uploadReleaseAsset({
|
|
file: fs.createReadStream(file),
|
|
headers: { 'content-length': size, 'content-type': 'application/octet-stream' },
|
|
name: path.basename(file),
|
|
url: release.data.upload_url,
|
|
})
|
|
}
|
|
}
|
|
|
|
run().catch(err => {
|
|
console.log("ERROR: ", JSON.stringify(err, null, 2));
|
|
core.setFailed(err.message);
|
|
console.log(err.stack);
|
|
});
|