Bug #307

Build Generator: Build steps (invoke maven, shell, etc) in Jobs that contain a subfolder are not executed in the right order

Added by Florian Lier almost 6 years ago. Updated over 5 years ago.

Status:ResolvedStart date:2014-10-13
Priority:HighDue date:
Assignee:Jan Moringen% Done:

60%

Category:build-generatorSpent time:0.10 hour
Target version:Toolkit 0.1

Description

Build Generator: Build steps (invoke maven, shell, etc) in Jobs that contain a subfolder are not executed in the right order.

For Example, if you need to move a directory to the top-level folder in order to invoke maven (pom) or cmake-based build tools, the build process fails because maven (cmake, whatever) is actually invoked before the folder, contrain the cmake or pom file, is moved.

See:

http://bnd.csra.cit-ec.de:8080/job/flobidev-basic-hlc_client_java-master-toolkit-nightly/configure

Unfortunately, I cannot tell you what version of the build-gen is installed on bnd. I assume the latest one.

Can you confirm this bug?

Associated revisions

Revision 3e408be5
Added by Jan Moringen almost 6 years ago

Improved builder ordering in templates/*{tookit,maven}.template

refs #333, refs #307, refs #344

  • templates/T001-toolkit.template: pre-build-hook before <all> and
    before git
  • templates/T200-maven.template: maven.prepare-version before maven;
    maven.deploy-dependencies after maven

History

#1 Updated by Simon Schulz almost 6 years ago

some additional info: this is related git projects with subfolders

the subfolder is moved to the build directory after your shell code is run

#2 Updated by Florian Lier almost 6 years ago

...but related to any kind of project file that contains the "subfolder" variable

#3 Updated by Jan Moringen almost 6 years ago

  • Status changed from New to Feedback

Please try the 0.3 version of the generator (See Johannes' email).

#4 Updated by Jan Moringen almost 6 years ago

  • Status changed from Feedback to Resolved
  • % Done changed from 0 to 100

#5 Updated by Simon Schulz almost 6 years ago

bug still exists...
build-generator version 0.3.36

{
    "name":      "libreflexxes",
    "templates": [ "cor-lab", "freestyle" ],

    "catalogue.component.title": "libreflexxes",
    "catalogue.component.nid":   "0",

    "variables": {
        "description":   "libreflexxes - a motion/trajectory generation lib. we use the open source type2 library (no jerk limitation). the type5 library is available for academic use for free (contact reflexxes.com)",
        "keywords":      [ "motion", "trajectory", "planning" ],

        "repository":       "https://projects.cit-ec.uni-bielefeld.de/git/flobidev.core/",
        "sub-directory":    "external/ReflexxesTypeII_v1.2.3/",
        "branches":         [ "master" ],

        "extra-provides" : [
            [ "cmake", "libreflexxes" ]
        ],

        "shell.command":   " 
ARCH=\\$(case \\$(uname -m) in (i686) echo x86 ;; (x86_64) echo x64 ;; esac)
ls -al
ls -al *
cd Linux
make all
mkdir -p ${toolkit.dir}/lib/pkgconfig
mkdir -p ${toolkit.dir}/include
install \\${ARCH}/release/lib/shared/libReflexxesTypeII.so ${toolkit.dir}/lib
install ../include/*.h ${toolkit.dir}/include
echo  \"#pkg config file for reflexxes lib\nprefix=${toolkit.dir}\nexec_prefix=\\${prefix}\nlibdir=\\$(prefix)/lib\nincludedir=\\$(prefix)/include\nName: reflexxes\nDescription: reflexxes motion lib\nVersion: 1.2.3\nRequires:\nLibs: -L\\${libdir} -lReflexxesTypeII\nCflags: -I\\${includedir}\n\n\" > ${toolkit.dir}/lib/pkgconfig/libReflexxesTypeII.pc

" 
    }

produces:

..
  <builders>
    <hudson.tasks.Shell>
      <command>
ARCH=$(case $(uname -m) in (i686) echo x86 ;; (x86_64) echo x64 ;; esac)
ls -al
ls -al *
cd Linux
make all
mkdir -p /media/local/vol/flobi-emotrack/releases/nightly/lib/pkgconfig
mkdir -p /media/local/vol/flobi-emotrack/releases/nightly/include
install ${ARCH}/release/lib/shared/libReflexxesTypeII.so /media/local/vol/flobi-emotrack/releases/nightly/lib
install ../include/*.h /media/local/vol/flobi-emotrack/releases/nightly/include
echo  &quot;#pkg config file for reflexxes lib
prefix=/media/local/vol/flobi-emotrack/releases/nightly
exec_prefix=${prefix}
libdir=$(prefix)/lib
includedir=$(prefix)/include
Name: reflexxes
Description: reflexxes motion lib
Version: 1.2.3
Requires:
Libs: -L${libdir} -lReflexxesTypeII
Cflags: -I${includedir}

&quot; &gt; /media/local/vol/flobi-emotrack/releases/nightly/lib/pkgconfig/libReflexxesTypeII.pc

</command>
    </hudson.tasks.Shell>
    <hudson.tasks.Shell>
      <command>find . -mindepth 1 -maxdepth 1 -not -name &quot;external/ReflexxesTypeII_v1.2.3/&quot; -exec rm -rf {} \;

# Uniquely rename directory.
temp=$(mktemp -d ./XXXXXXXX)
mv &quot;external/ReflexxesTypeII_v1.2.3/&quot; &quot;${temp}/&quot;

# Move contents to toplevel workspace directory.
find &quot;${temp}&quot; -mindepth 2 -maxdepth 2 -exec mv {} . \;
rm -r &quot;${temp}&quot;</command>
    </hudson.tasks.Shell>
  </builders>
...

#6 Updated by Simon Schulz almost 6 years ago

  • Status changed from Resolved to Feedback

#7 Updated by Jan Moringen almost 6 years ago

  • Status changed from Feedback to Resolved

Right, the workaround is not possible for freestyle projects.

#8 Updated by Simon Schulz almost 6 years ago

still broken. see e.g. project flobidev-basic-hlc_client_java-master-toolkit-nightly

#9 Updated by Jan Moringen almost 6 years ago

  • Status changed from Resolved to In Progress
  • % Done changed from 100 to 60

still broken. see e.g. project flobidev-basic-hlc_client_java-master-toolkit-nightly

Sorry, I didn't mean to change this to "resolved". The combination of this redmine instance and the webbrowser sometimes causes random changes to "Status" and "% Done" when I just want to write a comment.

The situation should be as follows:
  • In the 0.3 version of the generators, the problem should be fixed (or worked around, rather) with two exceptions:
    • The workaround is not applicable to freestyle projects
    • Since the Maven template currently introduces an additional shell fragment, the workaround is not applicable to Maven projects as well
  • An extended aspect sorting mechanism is being developed in the generator master branch, but it is not clear whether a backport to 0.3 will make sense or not

#10 Updated by Florian Lier almost 6 years ago

  • Status changed from In Progress to Feedback

This should be fixed right?

#11 Updated by Florian Lier over 5 years ago

  • Status changed from Feedback to Resolved

Also available in: Atom PDF