Refine snap ci workflow and improve resiliency #452
Conversation
| git add -A | ||
| git commit --amend -m "$COMMIT_MSG" --author="GitHub Actions <[email protected]>" | ||
| git commit --amend --no-edit # keep original author but set committer to [email protected] |
There was a problem hiding this comment.
If we're changing the SHA anyways, isn't it better to just create a new commit?
There was a problem hiding this comment.
We touched on this during standup and both approaches have flaws. If you add a commit then the message show in launchpad isn't helpful (ie all you see is something like ci: prep for launchpad snap build). If you modify the HEAD then it's not signed but at least the commit message matches what is in the git history.
I'm happy either way, so let me know if you have a strong opinion either way!
There was a problem hiding this comment.
In any case, we should introduce meaningful version numbers for the snaps then, as the associated commit hash will never be part of main.
There was a problem hiding this comment.
Ugh so many issues all because we can't simply do snapcraft -f path-to-thing.yaml! Lets discuss at standup. I'd like to maintain the sha over version nos.
There was a problem hiding this comment.
We could just add the last commit message to the new commit. i.e.
ci(release): <Last commit message>
There was a problem hiding this comment.
Correct me if I'm off, but is the aim to be able to trace the build artefact back to a specific commit sha on main?
If so, then piling release commits on ci/name might work at the start, but over time the branch's history would become long and problematic. For example, after 50 releases you'd have to go quite far back in the launchpad history to find the HEAD of main -- although it would still be possible! If we amend to avoid stacking commits, the commit in ci/<name> would be overridden on the next invocation and so tracing back to a specific sha would only be a matter of looking at HEAD^1 in launchpads history.
I think the solution we actually want is to combine a few bits here:
- I like your updated commit message so will adopt that
- I think we can use external-metadata to get info from HEAD^1 to properly version the artefact.
- go with amending but include details in the subject/commit to reflect the main commit it was built from
WDTY?
There was a problem hiding this comment.
If so, then piling release commits on ci/name might work at the start
Yeah, that doesn't sound like a good solution.
I like your updated commit message so will adopt that
In a new commit right? Maybe we should add the SHA of the previous commit in the commit message too, then we'd be able to track it "properly", or maybe not worth it since it'll always be HEAD~1?
I think we can use external-metadata to get info from HEAD^1 to properly version the artefact.
Sounds good, we should probably start running melos version as part of this workflow too and get the version from there.
There was a problem hiding this comment.
A dedicated release commit message would be great 👍
Would it be terribly misleading if we used snapcraftctl set-version <hash of HEAD~>?
I'm also not opposed to the melos version idea :)
There was a problem hiding this comment.
Yep agree with all of this. I've created #456 to get that work done if you're happy to punt that challenge for the moment?
tim-hm
force-pushed
the
main
branch
2 times, most recently
from
006518a
to
7e601f3
Compare
Snapcraft.yamls and artefacts were in the /snap/* folder. This meant that running `snapcraft` gave an error. It was also brittle when running local builds due to individual files within snap/ needing to be move around (rather than simply being able to remove the folder and copy a fresh one from somewhere else). This restructure avoids the warning and provides a straightforward way to prepare for a snap build: ```bash $ ./ci/snap-build-setup.sh bootstrap # or $ ./ci/snap-build-setup.sh init ```
Given that this workflow positions snapcraft.yaml and artefacts for a launchpad build it can be forceful in its merging strategy. Thus, the rebase-for-snap-cicd workflow now uses: 1. A matrix strategy to merge all rebase-for-snaps jobs into a single job 2. Leverages `./ci/snap-build-setup.sh <name>` to structure the repo 3. Uses `git reset --hard main` rather than a rebase 4. Amends HEAD on `ci/(init|bootstrap)` and adds GitHub Actions as the comitter. This means that when visually scanning commits in Launchpad these better align to what is seen in GitHub.
Building locally is brittle due to artefacts polluting the build container (caused by `source: .`). This doesn't present in ci because the build container is fresh. The flutter-git part, now checks if a previous clone exists to avoid a failure if the snapcraft build is run twice. Additionally, CONTRIBUTING.md highlights the difficulties with local builds and provides some guidance on workarounds.
The `contact` field is displayed in three places: `snap info <name>`, the App Center, and snapstore.io. When set, the snapstore.io publisher page overrides the `snapcraft.yaml` contact value. The `snapcraft.yaml`'s `issue` key does not appear anywhere, but if set in the snapstore.io publisher page, then it is displayed at `snapstore.io/<snap-name>` under "Report a bug". Going forward, we should prefer setting these values in the publisher page and omit them from the `snapcraft.yaml` to avoid confusion. Signed-off-by: Tim Holmes-Mitra <[email protected]>
No description provided.