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

Jenkins-ci upgrade #188

Open
jburel opened this issue Jan 27, 2022 · 5 comments
Open

Jenkins-ci upgrade #188

jburel opened this issue Jan 27, 2022 · 5 comments
Milestone

Comments

@jburel
Copy link
Member

jburel commented Jan 27, 2022

PHASE I (Jan 2022)
Current build is failing due to old version of Jenkins docker image. Main goal of this work is to have an updated working environment to test scl python 3.8 on CentOS 7

Several repositories need to be updated/adjusted in order to get things to work. Below is the list of repositories with changes:

Infra/Build

DNS assumptions

Jobs

Three jobs were green in merge-ci and failed on a fresh installation, giving us possible false positives.

Others
Other changes in BioFormats related repositories will also be required.

  • The usage of older plugin prevents us from using the new way to push to nexus when using mvn deploy.
  • ZarrReader prevents the usage of the more suitable flag altSnapshotDeploymentRepository.

PHASE II (Jan 2023)

Upgrade of Jenkins. Upgrade to 2.375.

  • Upgrade to Java 11 (impact)
  • Upgrade to Gradle 6 (impact)
  • Upgrade to nodejs 1 (no impact)
  • Postgresql 13

Infrastructure

Java 11 related issues:
The following PRs fails the build due to a Javadoc related flag.

Gradle related issues:

@sbesson sbesson added this to the 0.16.0 milestone Feb 1, 2022
@jburel jburel mentioned this issue Feb 9, 2022
@jburel
Copy link
Member Author

jburel commented Jan 9, 2023

Python test failures with Scl Python 3.8 ome/openmicroscopy#6340

@jburel
Copy link
Member Author

jburel commented Jan 12, 2023

Second upgrade of Jenkins. Upgrade to 2.375. This version of Jenkins uses Java 11

Java 11 related issue:

@sbesson sbesson self-assigned this Jan 18, 2023
@sbesson
Copy link
Member

sbesson commented Jan 19, 2023

Bio-Formats repository

The following minimal changes were made in order to run the repository tests in the staging devspace:

  • the environment variables

    devspace/.env

    Lines 22 to 24 in a732e08

    # Variables for changing what Bio-Formats tests
    REPO_CURATED=/tmp/curated
    REPO_CONFIG=/tmp/config
    were set to production values, respectively /uod/idr/repos/curated and /uod/idr-scratch/devspace-jm/config
  • the DATA_REPO_CONFIG-merge job was copied from https://merge-ci.openmicroscopy.org/jenkins/ to create a copy of the private configuration folder under REPO_CONFIG which can be re-used from the job and executed
  • the volumes of the testintegration service in docker-compose.yml were reviewed to include /uod/idr-scratch:/uod/idr-scratch (and /uod/idr:/uod/idr:ro) and the services restarted

With this set of changes, a full execution of BIOFORMATS-test-repo is close to completion and matches the results of https://merge-ci.openmicroscopy.org/jenkins/.

The steps above expose a few elements which are currently absent from this repository:

  • the configuration of the jobs working against private repositories. While this is not a requirement for building Bio-Formats/OMERO components, it is critical for executing the repository tests against the curated QA repository
  • the convergence towards separating the application, under /scratch/<devspace_name> from the persistent/shared data under /uod/idr-scratch/<devspace_name>. This was initially explored in the context of merge-ci and the binary repository of the CI OMERO server currently lives there. The steps above would also proposal to migrate the shared configuration repository and there were some attempts to migrate nexus-data there, unsuccessful so far. At the administration level, this has the advantage of separating components which are growing at different rates and making the application way less sensible to out of disk errors. Doing so requires additional configuration steps, including symlinks as well as volume mounting as appropriate

More generally, the two points above raise the question of whether this repository should remain generic and act as a re-usable template or whether we should move towards capturing the state of the production deployment on the OME hardware.

@jburel
Copy link
Member Author

jburel commented Jun 20, 2023

mv ~/.ssh/known_hosts ~/.ssh/known_hosts.bak
ssh -T git@github.com

@sbesson
Copy link
Member

sbesson commented Jun 20, 2023

A more programmatic option might be to set up the public SSH key fingerprints documented in https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/githubs-ssh-key-fingerprints.

@sbesson sbesson removed their assignment Sep 4, 2023
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

No branches or pull requests

2 participants