It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Follow this question
Question details

×42,788

question asked: May 28 '09, 12:11 p.m.
question was seen: 6,009 times
last updated: Feb 15 '13, 9:27 a.m.

Related questions

FAQ - How this Forum works

Regular build including files from previous personal build

0
Kirk Vogen (127●1●14●18) | asked May 28 '09, 12:11 p.m.
We have found an issue with personal builds leaving files around that get included in the next regular build. Here is the scenario that causes this situation:

  1. The build definition is set to not Delete directory before loading (on Jazz Source Control tab).
  2. A user has a changeset containing two new files: foo.bar and foo.properties. Assume that *.properties is in the .jazzignore, but the user temporarily modified the .jazzignore to get the file into a changeset.
  3. The user submits a personal build using that repository workspace.
  4. Sometime later, a regular build is submitted. At the beginning of the build, when it is loading the builder repository workspace, it removes foo.bar from the local filesystem, but it leaves around foo.properties.

This results in foo.properties ending up in the final build artifact (e.g. a JAR file). But, this file shouldn't be part of the build since it is a new file local to the user's respository workspace. This means that the integrity of our builds is decreased.

We realize that we could work around this bug/feature by checking Delete directory before loading. However, this will increase the time of our builds since it will have to reload the entire repository workspace each build. Besides this bug/feature, Jazz Source Control does a perfect job of ensuring that only the files in that repository workspace are on the local builder filesystem. As such, deleting the directory hasn't been necessary.

9 answers

Most liked answers ↑|Newest answers|Oldest answers

0
permanent link
Heather Fraser-Dube (451●2) | answered May 28 '09, 2:14 p.m.
JAZZ DEVELOPER
This is by design. Files and Folders that are on disk and are ignored
will not be deleted by the load when it is detected they are not in the
repository workspace. The items that are on disk were put there by a
user who asked that they be ignored. Another different example of
something that is ignored but someone would not want to be deleted is a
project's bin directory, or extra launches.

What I would suggest is change the .jazzignore file to be more explicit
about the .properties files to be ignored (rather than the *.properties
pattern). In this case foo.properties is not to be ignored.

- Heather
Source Control

kvogen wrote:
We have found an issue with personal builds leaving files around that
get included in the next regular build. Here is the scenario that
causes this situation:

  • The build definition is set to not
    Delete directory before
    loading (on Jazz Source Control tab).
  • A user has a changeset containing two new files: foo.bar
    and foo.properties. Assume that *.properties is in the .jazzignore,
    but the user temporarily modified the .jazzignore to get the file
    into a changeset.
  • The user submits a personal build using that repository
    workspace.
  • Sometime later, a regular build is submitted. At the
    beginning of the build, when it is loading the builder repository
    workspace, it removes foo.bar from the local filesystem, but it
    leaves around foo.properties.

    This results in foo.properties ending up in the final build artifact
    (i.e. a JAR file). But, this file shouldn't be part of the build
    since it is a new file local to the user's respository workspace.
    This means that the integrity of our builds is decreased.

    We realize that we could work around this bug/feature by checking
    Delete directory before loading.
    However, this will increase the time of our builds since it will have
    to reload the entire repository workspace each build. Besides this
    bug/feature, Jazz Source Control does a perfect job of ensuring that
    only the files in that repository workspace are on the local builder
    filesystem. As such, deleting the directory hasn't been necessary.
    		•
    0
    permanent link
    Kirk Vogen (127●1●14●18) | answered May 28 '09, 4:43 p.m.
    Thank you for the response. The design works well in the interactive case with a developer working in the IDE. However, in the case of builds within the JBE, the design doesn't seem optimal since it allows developers to essentially inject files into regular builds (via the personal build trick in my original post).

    It would seem that some kind of override could be considered for automated builds. For example, what if the load operation had an option to ignore the .jazzignores. I know, it sounds funny. But, with loads done by the JBE, this would ensure that the unwanted foo.properties is deleted (from the local filesystem) when the regular build's repository workspace is loaded.

    Without a design change for loading a workspace during JBE builds, it seems to leave a hole in the build system. Or, the recommendation should be to always have the Delete directory before
    loading     option and just live with the fact that builds will take longer.
    0
    permanent link
    Evan Hughes (2.4k●13●18) | answered May 28 '09, 4:53 p.m.
    JAZZ DEVELOPER
    I've created bug 84700 to track this behaviour.
    0
    permanent link
    Heather Fraser-Dube (451●2) | answered May 28 '09, 4:59 p.m.
    JAZZ DEVELOPER
    We have opened https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/84700 for this. We could essentially ignore the ignores, but are concerned about the bin directories under the project which are by default also ignored. They would be deleted as well, possibly making your builds slower.

    - Heather
    Source Control

    Thank you for the response. The design works well in the interactive case with a developer working in the IDE. However, in the case of builds within the JBE, the design doesn't seem optimal since it allows developers to essentially inject files into regular builds (via the personal build trick in my original post).

    It would seem that some kind of override could be considered for automated builds. For example, what if the load operation had an option to ignore the .jazzignores. I know, it sounds funny. But, with loads done by the JBE, this would ensure that the unwanted foo.properties is deleted (from the local filesystem) when the regular build's repository workspace is loaded.

    Without a design change for loading a workspace during JBE builds, it seems to leave a hole in the build system. Or, the recommendation should be to always have the Delete directory before
    loading     option and just live with the fact that builds will take longer.
    0
    permanent link
    Jean-Michel Lemieux (2.5k●1●1) | answered May 29 '09, 8:04 a.m.
    JAZZ DEVELOPER
    Another option is to have a different build definition for personal builds with different settings for the "delete before load" option. This would let you keep the "true" incremental continuous builds and allow team members to run personal builds with a clear area on the build engine. Just ensure that the build definitions have their own work directory on the build engine machine.
    Jean-Michel
    0
    permanent link
    Kirk Vogen (127●1●14●18) | answered May 29 '09, 11:03 a.m.
    We could essentially ignore the ignores, but are concerned about the bin directories under the project which are by default also ignored. They would be deleted as well, possibly making your builds slower.

    This wouldn't be an issue for us as we always want the bin directory empty prior to building. This ensures that bin doesn't have relics from a previous build, like foo.properties. Our projects tend to compile quickly, so this isn't an issue. We are using Maven for our builds, so we just do a 'mvn clean deploy' to ensure that the bin directory (target in the case of Maven) is nice and clean.
    0
    permanent link
    Kirk Vogen (127●1●14●18) | answered May 29 '09, 11:08 a.m.
    Another option is to have a different build definition for personal builds with different settings for the "delete before load" option. This would let you keep the "true" incremental continuous builds and allow team members to run personal builds with a clear area on the build engine.

    I like the idea. As you mentioned, this way developers wouldn't get stuck in the queue behind the continuous builds (which sometimes annoys our developers). The disadvantage for us is that we already have quite a few build definitions. This technique would require us to manage more definitions. Not a showstopper, just something that we'd need to consider. Also, is it possible to have a build definition set to not allow personal builds? I didn't see anything in the build definition editor about that.
    0
    permanent link
    Kirk Vogen (127●1●14●18) | answered Oct 22 '10, 2:01 p.m.
    Does the Jazz API include a class for parsing .jazzignore files?

    The enhancement to resolve this issue (84700) isn't implemented yet. So, we may try to workaround the issue ourselves. To do this, we'll need to parse the .jazzignore file as part of our builds. Is there a class that can parse out this file? Or, will we need to write this ourselves?
    0
    permanent link
    Philippe Kaplan (68●4●8) | answered Feb 15 '13, 9:27 a.m.
    Actually I've hit a similar problem: A Java unit test was added by a developer in a personal build. It failed, and eventually the dev deleted it.
    But the failing test remained in some of the build machines, and crashes all builds. It was very frustrating because it was very difficult to find out where this ghost failing test was coming from...

    Could we have an implementation of something like git-clean in RTC, please ?

    Your answer

    Register or to post your answer.


    Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.