Call for Testing: Enhanced Snapcraft Build Action with proper Env Var support and Caching

snapcraft
1

Hi everyone,

I’ve been working on some updates to the Snapcraft Build Action, and I’m looking for some folks to test it out.

This updated version includes a few features that should make your CI/CD pipelines for snaps much smoother.

Key Features

1. Arbitrary Environment Variable Pass-through

One of the main pain points has been passing secrets or configuration variables into the build environment. This version now checks the GitHub Actions environment and passes variables through to the LXD build environment (respecting a deny-list for sensitive system vars like PATH,HOME, etc.).

2. GitHub Actions Cache Support

You can now enable GitHub Actions Cache integration with a simple flag. This is particularly useful if you are using build tools like sccache to speed up your builds.

How to Test

You can try it out in your existing workflows by pointing to the master branch of my fork:

steps:
- uses: actions/checkout@v4
- uses: soumyaDghosh/action-build@master
  with:
    # Enable GitHub Cache
    enable-github-cache: true
  env:
    # Pass your custom environment variables here
    MY_API_KEY: ${{ secrets.MY_API_KEY }}
    BUILD_CONFIG: "production"

I’d appreciate any feedback, especially regarding:

  • Whether environment variables are arriving as expected in your build.
  • If the caching mechanism is working correctly for your setup.
  • Any regressions compared to the upstream action.
  • If this is working perfectly for both amd64 and arm64 and self hosted runners.
1 Like
2

Hi @soumyaDghosh ! We’re working on a new build action ourselves… craft-actions/snapcraft/pack/README.md at main · canonical/craft-actions · GitHub

It’s “effectively” done, but we need to write up some usage examples and add testing before actually recommending it to people.

Is there a way we could combine our efforts here? I think you would have valuable insights on what would be useful in a build action.

3

Adding to this, I’d love to have an up-to-date action for both myself and for my customers!

Perhaps we can discuss this during the next clinic?

1 Like
4

I have looked into the above shared action. I think the aim is very much diverging. The existing action based on node, was very much complete, except all the supports that were needed, I have added most of them.

5

The main motivation for selecting composite actions instead of a JS-based one was simply that the Starcraft team wanted to own and maintain the action, but none of us are all that versed in JS. Because of this, I’m hesitant to incorporate something written in JS if it’s possible to write it in Bash.

What were the features that were missing in the old action? What do you think is missing from the new one I linked?

6

That’s understandable, but we will not be able to use the underlying apis of GitHub Actions using bash. Which is helpful in setting up caching with tools like sccache. This was something definitely missing. Another thing was support for custom env variables which are often used to pass build time secrets. That was also missing, which I added in my fork.