CI Roadmap

[aaronleopold]

The CI workflow(s) for Stump are currently at a much better state than they were before, but there is still a lot of work to be done. I'll outline some of the areas that need work below, and create separate issues for tracking as needed. This overly time critical, but it eventually will be when I feel ready for an initial release.

Docker Caching

Lol this is annoying. So, as of https://github.com/aaronleopold/stump/pull/92, docker caching works only when running builds locally. In CI, the only time the cache actually works is when you rerun a build for the same commit.

Locally, this is not the case. I can run a build, make a change, run a consecutive build, and the cache is properly used and the build is much faster. I have no idea why this is the case, but it is very annoying and gives me agita.

CI Checks

Honestly this is pretty decent right now. Not much I would change here. The checks are rather basic, but they are sufficient for now. All it does is lint the code. I guess the one thing I want it to do is run tests, but those don't exist yet lol well, if they do they are not great tests. See https://github.com/aaronleopold/stump/tree/al/testing-overhaul.

Nightly Release Workflow

As of https://github.com/aaronleopold/stump/pull/92, we have a nightly release workflow that will build and publish nightly docker image(s) whenever a PR lands in develop.

The general flow at the moment is:

• On PR, trigger docker build for linux/amd64 only. This will not be pushed to a registry, rather just be cached. I consider this a smoke test to ensure basic build functionality before merging and running the full build(s) for all platforms.
• On push, trigger a build for all of the supported platforms and push to the registry. This will be considered the nightly release, and will be tagged as such.

Note that all operations are currently performed on a single, self-hosted runner. This is a great start, but there are a few things that need to be done to make this more robust:

• [ ] Run builds and publish nightly executables for stump_server
  • Ensure I can support the main 3, initially targeted platforms: macos, linux, and windows.
  • I don't think it is feasible to run some sort of cross-compilation flow on the single, self-hosted runner, so two GH hosted runners will need to be used for the macos and windows builds.
• [ ] Run builds and publish nightly executables for stump_desktop
  • Ensure I can support the main 3, initially targeted platforms: macos, linux, and windows.
    • This won't really be a concern until the stump_server CI is in a good state, but I wanted to call it out here.
• [x] Ensure that all nightly releases replace any existing nightly releases for the same platform.
• [x] #94
• [ ] Only build docker images when actual code changes are made

Release Workflow

The release workflow is currently non-existent and I imagine it will be more annoying.

In general, what I am envisioning is:

1. Create a new GH release, which will trigger the new workflow.
2. The workflow will do all of the same operations as nightly, except it will be tagged with the release version.
   • For Docker, an image tagged with both latest and the release tag will be pushed to the registry.
3. The workflow should handle the creation of / update of the change log. There seem to be many options out there, but this should be some autogenerated markdown file that looks at commit names and messages to generate a list of changes. This requires some research to pick the right tool for the job.

The checklist for the release, following the above outline, would be:

• [ ] Build and publish the stump_server and stump_desktop executables for all supported platforms to the GH release page.
• [ ] Build and publish the stump_server and stump_desktop docker images for all supported platforms, tagged with latest and the release tag.
• [ ] Update the change log for the release and create a PR with the changes pointing to main.

Other Notes

• I'm a little iffy on the release workflow. It just feels a little disjointed to make a tag and then run the builds. I'm just thinking of scenarios where I'd have to delete the tag if a build fails or something :shrug:
• Docker armv7 is broken.

[aaronleopold]

See https://github.com/aaronleopold/stump/issues/98

[aaronleopold]

I think https://github.com/aaronleopold/stump/pull/108 surfaced an annoying issue where external PRs are missing this repos variables during the CI, which causes failures like https://github.com/aaronleopold/stump/actions/runs/4521440733/jobs/7963254737#step:4:417. This is kinda annoying, but I think it makes sense? I guess the options are:

1. Hard code vars related to PRs, so external PRs have the required context
2. Hope I am wrong and someone with more knowledge about GH actions corrects me lol

[aaronleopold]

https://github.com/softprops/action-gh-release

[aaronleopold]

https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates