Skip to content

Drone to GARM - #9622

Closed
tobiasKaminsky wants to merge 1 commit into
masterfrom
drone2garm
Closed

Drone to GARM#9622
tobiasKaminsky wants to merge 1 commit into
masterfrom
drone2garm

Conversation

@tobiasKaminsky

Copy link
Copy Markdown
Member

No description provided.

@mgallien mgallien left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tobiasKaminsky
tobiasKaminsky force-pushed the drone2garm branch 2 times, most recently from aa835cd to a4cca2d Compare March 16, 2026 07:34
@tobiasKaminsky

Copy link
Copy Markdown
Member Author

Done ✔

I do not have the secrets for debian, thus I could not update them for GitHub Actions.
(But it also seems to still build?)

@tobiasKaminsky
tobiasKaminsky requested a review from mgallien March 16, 2026 07:36
@tobiasKaminsky

tobiasKaminsky commented Mar 16, 2026

Copy link
Copy Markdown
Member Author

Hm. Actually it fails:

+ git fetch origin debian/dist/jammy/
fatal: invalid refspec 'debian/dist/jammy/'
Warning:  Debian build failed but this is a non-blocking CI event

--> working on it

@tobiasKaminsky
tobiasKaminsky force-pushed the drone2garm branch 5 times, most recently from e170a11 to 8f2fe2d Compare March 16, 2026 08:17

@mgallien mgallien left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks

@tobiasKaminsky
tobiasKaminsky force-pushed the drone2garm branch 5 times, most recently from f0fddba to f6064f3 Compare March 16, 2026 09:07
@tobiasKaminsky

Copy link
Copy Markdown
Member Author

@mgallien this works now.
But I do not see if/where those secrets are being used.

@mgallien

Copy link
Copy Markdown
Collaborator

@mgallien this works now. But I do not see if/where those secrets are being used.

they are being used there https://github.com/nextcloud/desktop/blob/master/admin/linux/debian/drone-build.sh#L45-L52

@ivaradi I guess from the CI point of view, we do not make use of them ?
I will wait for your feedback before merging the PR

@ivaradi

ivaradi commented Mar 17, 2026

Copy link
Copy Markdown
Contributor

@ivaradi I guess from the CI point of view, we do not make use of them ? I will wait for your feedback before merging the PR

We actually do. They are needed to decode the keys for uploading the source packages to the PPA and the openSUSE build service. I think the current setup is such that the secrets are set for the master branch only, so that only builds performed on that are uploaded.

@mgallien

Copy link
Copy Markdown
Collaborator

@ivaradi I guess from the CI point of view, we do not make use of them ? I will wait for your feedback before merging the PR

We actually do. They are needed to decode the keys for uploading the source packages to the PPA and the openSUSE build service. I think the current setup is such that the secrets are set for the master branch only, so that only builds performed on that are uploaded.

@ivaradi I indeed can confirm that our drone Nextcloud run instance has the secrets but not recoverable (the whole point of having secrets)
we do want to merge this PR
so if the maintenance of your PPA needs the secrets to be valid, we will have to arrange a way to get them sent by you
I am checking internally if we would have other ideas or solutions

@tobiasKaminsky

Copy link
Copy Markdown
Member Author

@ivaradi
I added the keys/secrets:

+ test -f /github/home/.has_ppa_keys
+ debsign -k2265D8767D14AA7B -S
long key IDs are discouraged; please use key fingerprints instead
 signfile dsc ../nextcloud-desktop_33.0.50-20260319.120140.ce2ec846fc-1.0~jammy1.dsc 2265D8767D14AA7B

 fixup_changes dsc ../nextcloud-desktop_33.0.50-20260319.120140.ce2ec846fc-1.0~jammy1.dsc ../nextcloud-desktop_33.0.50-20260319.120140.ce2ec846fc-1.0~jammy1_source.changes
 signfile changes ../nextcloud-desktop_33.0.50-20260319.120140.ce2ec846fc-1.0~jammy1_source.changes 2265D8767D14AA7B

Successfully signed dsc, changes files

Full logs are here:
https://github.com/nextcloud/desktop/actions/runs/23135940643/job/67735771075

For me this looks good?

@tobiasKaminsky

Copy link
Copy Markdown
Member Author
+ dput ppa:nextcloud-devs/client-alpha nextcloud-desktop_33.0.50-20260319.120140.ce2ec846fc-1.0~jammy1_source.changes
gpg: /__w/desktop/nextcloud-desktop_33.0.50-20260319.120140.ce2ec846fc-1.0~jammy1_source.changes: Error checking signature from 2265D8767D14AA7B: SignatureVerifyError: 0

this is not that good 🙈

@tobiasKaminsky

Copy link
Copy Markdown
Member Author

@mgallien
mgallien enabled auto-merge March 19, 2026 12:51
Signed-off-by: tobiasKaminsky <[email protected]>
@github-actions

Copy link
Copy Markdown
Contributor

Artifact containing the AppImage: nextcloud-appimage-pr-9622.zip

Digest: sha256:b87a4e895e7e98232ace3978753db65c14dbb50df0eecd20b499949d778d135e

To test this change/fix you can download the above artifact file, unzip it, and run it.

Please make sure to quit your existing Nextcloud app and backup your data.

Comment on lines +4 to +6
on:
pull_request:
branches: [ master, stable-* ]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this also include the push trigger? if so the run command would need to be updated to make use of e.g. env.GITHUB_SHA (or set DRONE_COMMIT="$GITHUB_SHA" in the script)

(I'm not sure if drone-build.sh should also be run on PRs targeting any stable-* branch, the .drone.yml at least did not include that)

Suggested change
on:
pull_request:
branches: [ master, stable-* ]
on:
push:
branches: [ master ]
pull_request:
branches: [ master, stable-* ]

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I'm not sure if drone-build.sh should also be run on PRs targeting any stable-* branch, the .drone.yml at least did not include that)

I agree with this.

Also, when running for a pull request, it should not set the secrets, so that those are not uploaded to the PPA. It should set the secrets only when pushing to the master branch.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ivaradi so this workflow needs to be changed to only run on.push.branches: [master] then, correct?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but it could also run on pull requests.

But for pull requests, the secrets should not be set, so that the source packages are not uploaded to the PPA, if it can be solved. If there is no way to set the secrets selectively, it should not be run for pull requests. (Running on pull requests can be useful to check if I modify something in the Debian scripts.)

That said, I have been thinking for a while of setting up a repository specifically for the Ubuntu/Debian builds, that would periodically check the this repository for new commits and perform the build if one is found. Then this workflow will not be needed at all. So if it is difficult to selectively set the secrets, there should not be too much effort put into it, and we should just settle for building on pushing to the master branch only.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for the clarification!

I think the easiest way to not pass the secrets to the workflow would be to duplicate the workflow file: one for push events to master which sets those secrets in ENV, and another one for pull_request ones which doesn't.

I also just found another place in the script that needs to be adapted to GitHub Actions: pull_request=${DRONE_PULL_REQUEST:=master}. As DRONE_PULL_REQUEST is not set this variable would always end up as master, which is one condition to update the build on OBS ...

@sonarqubecloud

Copy link
Copy Markdown

Comment on lines +4 to +6
on:
pull_request:
branches: [ master, stable-* ]

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for the clarification!

I think the easiest way to not pass the secrets to the workflow would be to duplicate the workflow file: one for push events to master which sets those secrets in ENV, and another one for pull_request ones which doesn't.

I also just found another place in the script that needs to be adapted to GitHub Actions: pull_request=${DRONE_PULL_REQUEST:=master}. As DRONE_PULL_REQUEST is not set this variable would always end up as master, which is one condition to update the build on OBS ...

@ivaradi ivaradi mentioned this pull request Mar 25, 2026
@mgallien

Copy link
Copy Markdown
Collaborator

closing as it is no longer needed
see #9700

@mgallien mgallien closed this Mar 26, 2026
auto-merge was automatically disabled March 26, 2026 08:44

Pull request was closed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants