ci: automatically bump node parts and use remote build #181
Conversation
|
@kenvandine :) |
|
@merlijn-sebrechts I've added the Launchpad build stuff here. |
jnsgruk
changed the title
There was a problem hiding this comment.
Required changes:
- Remove the use of artifacts if we don't need it. Artifacts are expensive.
Optional: Publishing workflow
While the building aspect seems fixed with this PR, we also need to rework the publishing workflow, so we can publish both architectures to stable too. We can do this here, or in a separate PR.
I think the ideal workflow is as follows:
- After a build, an issue gets created that explains for which architectures there is a new revision.
- Testers can either promote individual versions (using the existing command), or promote multiple versions at once (using
/promote 22 23 stable, or something like this) - The issue only closes once all revisions are pushed to stable.
Changes needed:
- Change
.github/testing-issue-template.mdto reflect multiple revisions are pushed. Ideally it says for which architectures there are new versions. - Change the promote-to-stable workflow so it can receive multiple revisions to promote to stable at once.
- Change the promote-to-stable workflow so it only closes the issue once all revisions are pushed to stable.
|
Ah, and one final thing; we might also need to update the test-snap-can-build workflow, so we can find issues with the arm64 build before we push: |
|
FYI: added an issue in |
|
@merlijn-sebrechts I think that's all done. Unfortunately it seems that The The only thing we now need is a new Github Secret setting called |
|
FYI: |
|
Okay - I've reverted the build action for now to use the Github Action as before. FWIW I don't think using the LP secret in a PR workflow is an issue, provided the repo is configured such that workflows only run after a review from a maintainer (that way the reviewer can check there is no funny business). I did some looking at the conditions for running workflows, and I think checking user membership in a group might be beyond what's possible - but I'll circle back to it later. The other point here is that in reality the LP credential is somewhat "invaluable" because literally anyone can generate one with the same privileges, but I agree we shouldn't be flippent about that. Let me know if you'd like any further changes. |
|
@merlijn-sebrechts can we get this merged and check it all works? If you could add me as a collaborator on the signal-desktop snap I can keep an eye on the builds? |
|
@jnsgruk Are you asking to become a maintainer of this repo? All snapcrafters are, so do you want to join snapcrafters? :) |
|
@merlijn-sebrechts correct - happy to become a maintainer of this :) (and thus a snapcrafter!) |
|
Done, welcome to the fold! We also have a telegram channel. Send me your telegram handle if you want to join that. |
|
Perfect thanks! My telegram handle is the same as here: @jnsgruk Can you make me a collaborator on signal-desktop on snapcraft.io? |
|
@jnsgruk @merlijn-sebrechts How can we get the launchpad build secret? |
|
@soumyaDghosh I add it to your repo once you have a PR with the GitHub actions ready For more info on how i create these secrets, and what they are, take a look at https://github.com/snapcrafters/.github/wiki/Permissions-and-Secrets |
Fixes #180. This PR is dependent on #179 and should be merged after.
Because we now have multiple parts, which are dependent on the version of Signal, we need to augment the CI to ensure that when we bump the Signal version, we also bump the parts versions if required.
This PR also switches the build process to using
snapcraft remote-buildin a matrix that creates a job per architecture.This will be hard to review until #179 is merged, but the diff can be seen cleanly here: 7eb0bff