Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build snapshots with releases #77

Conversation

thlehmann-ionos
Copy link

Change

  • Creates snapshot tag needed to create a release
  • Uses softprops/action-gh-release action to create a release with the build .zip as asset and release configured as prerelease

Proposal for releases

  1. We (manually) create and push a release candidate tag at the same revision the most recent snapshot tag was deployed to the test system (we basically re-tag the revision as "it's on staging now")
  2. An action triggered by the release-candidate tag updates the existing release for this revision to be released now (prerelease = false)
  3. We (manually) create and push a release tag at the same revision the most recent release candidate tag is at

Tips

API request to fetch newest release:

function f() { curl --silent -L  -H "Accept: application/vnd.github+json"  -H "X-GitHub-Api-Version: 2022-11-28" https://api.github.com/repos/${1}/releases | jq --raw-output '.[0].assets[0].browser_download_url' ; } ; f "thlehmann-ionos/nc-server"

Proposal for the downstream usage

  • The GitLab container build and K8s pipelines could use renovate to scan us for new releases and trigger a container build and deploy on their side

Remarks

Attempt: keeping tag and build + release of tag separate workflows

It was tried having a workflow tagging upon change to ionos-dev and another workflow building upon "snapshot" tag creation. Yet GitHub would not trigger a workflow upon tag creation that another workflow caused. This is a "security" feature that can be circumvented by configuring personal access tokens (PAT), yet I discarded this for being less secure and requiring regular token renewals.

Creates a release from a tag and uses the tag name as artifact name.

Changes:

* Zip name changed: incorporates the tag name
* "write-all" permission requested (needed to create release)
* Runs for tags, not branches
* Checksum the .zip, attach the checksum
* Draft was tested, but not used (comment left)

== Conflicts

* Name changed in variable value and Job name
  7eb9541

== Notes kept after squashing

Reading the source it accepts a "tag_name" parameter, which apparently
will create the tag.

The "prerelease" option was added because this sounds reasonable for
snapshot builds.
@thlehmann-ionos thlehmann-ionos changed the base branch from master to ionos-dev December 18, 2024 09:12
Copy link

github-actions bot commented Jan 2, 2025

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

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

Successfully merging this pull request may close these issues.

1 participant