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

Release action #7210

Merged
merged 128 commits into from
Feb 14, 2024
Merged

Release action #7210

merged 128 commits into from
Feb 14, 2024

Conversation

poshul
Copy link
Collaborator

@poshul poshul commented Nov 17, 2023

Description

This unfortunately needs to have "release" in the branch name to work.

Checklist

  • Make sure that you are listed in the AUTHORS file
  • Add relevant changes and new features to the CHANGELOG file
  • I have commented my code, particularly in hard-to-understand areas
  • New and existing unit tests pass locally with my changes
  • Updated or added python bindings for changed or new classes (Tick if no updates were necessary.)

How can I get additional information on failed tests during CI

Click to expand If your PR is failing you can check out
  • The details of the action statuses at the end of the PR or the "Checks" tab.
  • http://cdash.openms.de/index.php?project=OpenMS and look for your PR. Use the "Show filters" capability on the top right to search for your PR number.
    If you click in the column that lists the failed tests you will get detailed error messages.

Advanced commands (admins / reviewer only)

Click to expand
  • /reformat (experimental) applies the clang-format style changes as additional commit. Note: your branch must have a different name (e.g., yourrepo:feature/XYZ) than the receiving branch (e.g., OpenMS:develop). Otherwise, reformat fails to push.
  • setting the label "NoJenkins" will skip tests for this PR on jenkins (saves resources e.g., on edits that do not affect tests)
  • commenting with rebuild jenkins will retrigger Jenkins-based CI builds

⚠️ Note: Once you opened a PR try to minimize the number of pushes to it as every push will trigger CI (automated builds and test) and is rather heavy on our infrastructure (e.g., if several pushes per day are performed).

@jpfeuffer
Copy link
Contributor

Have you considered the dis-/advantages of having the release job separately from the packaging?

I think both would work.

Do you want to trigger on release tag or manual trigger only and the job tags the repo?

@poshul
Copy link
Collaborator Author

poshul commented Nov 18, 2023 via email

@jpfeuffer
Copy link
Contributor

Sounds reasonable. What do you mean with "Cython built"?
Would be cool to just check the status of the last actions with GH cli. I'm pretty sure it is possible.

@jpfeuffer
Copy link
Contributor

jpfeuffer commented Nov 20, 2023

Another question: do you have a plan for integrating the macOS Silicon builds?

Options:

  1. cross-compile without tests on GHA
  2. self-hosted runner on GHA
  3. stay with current setup
  4. Jenkins with Jenkinsfile

I think 2 would be worthwhile, even when switching once Silicon builds become available for open source (probably mid 2024?). If that is out of scope I would probably stay with the current setup and try to integrate the artifacts from Jenkins as smoothly as possible.

@poshul
Copy link
Collaborator Author

poshul commented Nov 21, 2023

Sounds reasonable. What do you mean with "Cython built"? Would be cool to just check the status of the last actions with GH cli. I'm pretty sure it is possible.

Don't we still build Cython through: https://abibuilder.cs.uni-tuebingen.de/jenkins/job/openms/job/ntly/job/conda/?

@jpfeuffer
Copy link
Contributor

jpfeuffer commented Nov 21, 2023

Ah you mean conda?
Multiple options:

  • Query jenkins for success via its API: https://abibuilder.cs.uni-tuebingen.de/jenkins/job/openms/job/ntly/job/conda/lastBuild/api (for example xml-output; you need cookies/be logged in or get an API key for programmatic access).
  • Move to conda-forge or talk to bioconda people about auto-update of the recipe based on GitHub-Releases. Anything that cannot be automated, like changes in build.sh of the recipe must be made with a PR to bioconda(-forge) after release (potentially automated with GH CLI). Actually, thinking about it, maybe we should move the build.sh(s) for conda into the OpenMS source repository and make conda run this file instead; then it might be updated with the release automatically. Never thought about it (I might be wrong).
  • Move the conda job to GH Actions. It's all docker-based, should be rather easy (except for the workarounds needed for the year long bugs). Runtime might be an issue (probably not). Could be alleviated by:
    • reducing the python versions
    • splitting pyopenms from openms (should be working in theory already)
    • using our docker builder as a selfhosted runner on GHA

@jpfeuffer
Copy link
Contributor

The update of the bioconda(-forge) recipe (=item 2) is actually kind of unrelated to our internal "nightly" conda builds but must be considered.

@poshul poshul reopened this Feb 13, 2024
@poshul poshul marked this pull request as ready for review February 13, 2024 09:57
Copy link
Contributor

Generating PR code suggestions

Work in progress ...

@poshul
Copy link
Collaborator Author

poshul commented Feb 13, 2024

FYI openms-ci-full / build-and-test (ubuntu-22.04, g++, 11) is going to fail because I removed the version number override, and 2.9.1 doesn't actually have a changelog

Copy link
Contributor

@jpfeuffer jpfeuffer left a comment

Choose a reason for hiding this comment

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

Awesome thanks

@jpfeuffer jpfeuffer merged commit 26b6bfa into develop Feb 14, 2024
22 of 24 checks passed
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.

3 participants