check for available updates

• check if Git repos are up-to-date w.r.t. remotes
• only run the check in interactive shell
• provide instructions to update local repos
• be smart in case of local changes...
• identify if the update is major or minor, or just a patch

added to epic &3

assigned to @lmoureau

added To Do label

changed title from update to check for available updates

changed the description

marked the checklist item be smart in case of local changes... as completed

mentioned in merge request !26 (merged)

changed milestone to %Alma9 migration

mentioned in commit 229bd868

mentioned in merge request !29 (merged)

marked the checklist item provide instructions to update local repos as completed

removed milestone %Alma9 migration

added changepatch typesoftware labels

changed the description

• be smart in case of local changes...

I see that this one is crossed, but I'm not sure it's so "smart". It seems to overwrite the local changes.

Consider the following case: a user tries to install the framework in a machine where it hasn't been tested yet. Unfortunately, they have to amend the code to compile in their environment. Currently, the installer seems to overwrite / ignore the local changes.

Desired behaviour: if one of the repo (Darwin, Core, tables) is already there, the installer should not try to clone it or to change to the default branch, but use whatever is there.

It seems to overwrite the local changes.

Is this based on recent evidence? The UPDATE step has been disabled in the CMake configuration so CMake shouldn't even try to update the repos. This was changed because recent CMake versions seem to handle updates differently from older ones (they try harder to follow the upstream branch).

Running from my good old setup on NAF, where everything has been installed and with several branches in my repos:

-- Configuring done (0.3s)                                            
-- Generating done (0.1s)                                             
-- Build files have been written to: /afs/desy.de/group/cms/pool/connorpa/build
[  8%] Performing download step (git clone) for 'Darwin'          
[  8%] Creating directories for 'tables'                         
[ 12%] Performing download step (git clone) for 'tables'          
Cloning into 'Darwin'...                                              
warning: templates not found in /build/jenkins/workspace/lcg_release_pipeline/install/git/2.29.2/x86_64-el9-gcc13-opt/share/git-core/templat
es                                                                    
Cloning into 'tables'...         
warning: templates not found in /build/jenkins/workspace/lcg_release_pipeline/install/git/2.29.2/x86_64-el9-gcc13-opt/share/git-core/templat
es                                                                    
HEAD is now at 605929d Merge branch 'feature/improved_printHist' into 'master'
...

After this, I only have the master branch in Core. In Darwin, I'm in detached mode on origin/master.

(Note: the detached mode comes from the GIT_TAG in the EdxternalProject_Add of Darwin and tables. Just changing origin/master into master fixes it.)

(Re note: Local master may not be up-to-date.)

It seems you removed build before this?

(Re note: Local master may not be up-to-date.)

If you just now clone, then yes, it is. If the repo is already there, and the branch not up-to-date, the user may have a good reason for this.In any case, we should not remove local changes, which is currently happening.

It seems you removed build before this?

Indeed.

There seems to be no way to avoid it if you delete build short of writing our own custom download step

Ok, that wasn't clear to me. Can we kind of protect this directory against deletion to prevent from this case to happen again?

Probably not, CMake uses it to keep state and it's needed for the build step.

Ok, then this is probably just worth better documentation in the instructions to avoid such bad manipulations. I leave this thread open until a dedicated MR.

changed milestone to %5th CAT Hackathon

added Urgent label

changed health status to needs attention

mentioned in merge request !45 (merged)

marked the checklist item check if Git repos are up-to-date w.r.t. remotes as completed

identify if the update is major or minor, or just a patch

Idea:

• use tags
• define a pipeline, run only upon request of one of the maintainers, to change the version in CMakeLists.txt to increment the version number, in the master branch automatically.

The pipeline will need to know whether to increment the patch, minor, or major version. It would also be good to plan for release notes.

The pipeline will need to know whether to increment the patch, minor, or major version.

I was thinking of just having 3 pipelines...

It would also be good to plan for release notes.

Would be good if that could be generated automatically, or at least a preliminary version. It could list the MRs, issues, and commits.

Would be good if that could be generated automatically, or at least a preliminary version. It could list the MRs, issues, and commits.

Can do, even though such release notes are usually less useful than something written by hand because they do not emphasize the relevant changes.

Right, that's why I added "or at least a preliminary version", which the maintainer could then edit. I have no idea how easy / tough this can be implemented though.

Right, that's why I added "or at least a preliminary version", which the maintainer could then edit. I have no idea how easy / tough this can be implemented though.

mmh guess I'd have the pipeline open a MR with the release notes

removed milestone %5th CAT Hackathon

added statuson hold label and removed statusto do label

removed Urgent label