Revision history [back]

I fixed the mistake with sensor_msgs dependency in the package.xml and find_package declaration in the CMakeList.txt . Then I deleted my old git tag and made a new tag with the same name.

you cannot do this.

It's both not how tags are supposed to work, and doesn't solve the problem you're seeing.

But, the Jenkins job still failed with the same error.

The reason is that the buildfarm does not clone your source repository when it runs a binary job. It fetches your release repository.

Fetching your source repository is the responsibility of the source job, but that only runs when it notices you've (re)released your package. To figure out whether you've done that, it checks the relevant distribution.yaml.

Right now, if the buildfarm needs to rebuild your package (because of a release of one of your dependencies for instance), it will fetch your current released version from your release repository (which still has the problem) and nothing will change.

The only way to fix the dependency issue is to do a release of your package again.

Suggested steps:

1. revert your changes to your 1.0.0 tag: let it point to whatever commit is was pointing before you changed it. You should not change tags like that in any case
2. follow the Releasing a new version of a catkin package tutorial. So (but make sure to follow the tutorial):
   1. update your changelog
   2. create a new tag
   3. run Bloom

After you submit the PR and it gets accepted, the source job will fetch your new version (with the fix) and the binary jobs will start building your new version.

I fixed the mistake with sensor_msgs dependency in the package.xml and find_package declaration in the CMakeList.txt . Then I deleted my old git tag and made a new tag with the same name.

you cannot do this.

It's both not how tags are supposed to work, and doesn't solve the problem you're seeing.

But, the Jenkins job still failed with the same error.

The reason is that the buildfarm does not clone your source repository when it runs a binary job. It fetches Nor do source jobs.

Bloom commits the tagged version from your source repository to your release repository.

Fetching your source repository is the responsibility of the source job, but repository and that repository is then fetched by the various jobs on the buildfarm. They only runs run though when it notices they notice you've (re)released your package. To figure out whether you've done that, it checks the relevant distribution.yaml. is checked (for a newer version number).

Right now, if the buildfarm needs to rebuild your package (because of a release of one of your dependencies for instance), it will fetch your current released version from your release repository (which still has the problem) and nothing will change.

The only way to fix the dependency issue is to do a release of your package again.

Suggested steps:

1. revert your changes to your 1.0.0 tag: let it point to whatever commit is was pointing before you changed it. You should not change tags like that in any case
2. follow the Releasing a new version of a catkin package tutorial. So (but make sure to follow the tutorial):
   1. update your changelog
   2. create a new tag
   3. run Bloom

After you submit the PR and it gets accepted, the source job will fetch your new version (with the fix) and the binary jobs will start building your new version.

I fixed the mistake with sensor_msgs dependency in the package.xml and find_package declaration in the CMakeList.txt . Then I deleted my old git tag and made a new tag with the same name.

you cannot do this.

It's both not how tags are supposed to work, and doesn't solve the problem you're seeing.

But, the Jenkins job still failed with the same error.

The reason is that the buildfarm does not clone your source repository when it runs a binary job. Nor do source jobs.

Bloom commits the tagged version from your source repository to your release repository and that repository is then fetched by the various jobs on the buildfarm. They only run though when they notice you've (re)released your package. To figure out whether you've done that, the relevant distribution.yaml is checked (for a newer version number).

Right now, if the buildfarm needs to rebuild your package (because of a release of one of your dependencies for instance), it will fetch your current released version from your release repository (which still has the problem) and nothing will change.

The only only proper way to fix the dependency issue is to do a release of your package again.

Suggested steps:

1. revert your changes to your 1.0.0 tag: let it point to whatever commit is was pointing before you changed it. You should not change tags like that in any case
2. follow the Releasing a new version of a catkin package tutorial. So (but make sure to follow the tutorial):
   1. update your changelog
   2. create a new tag
   3. run Bloom

After you submit the PR and it gets accepted, the source job will fetch your new version (with the fix) and the binary jobs will start building your new version.

I fixed the mistake with sensor_msgs dependency in the package.xml and find_package declaration in the CMakeList.txt . Then I deleted my old git tag and made a new tag with the same name.

you cannot do this.

It's both not how tags are supposed to work, and doesn't solve the problem you're seeing.

But, the Jenkins job still failed with the same error.

The reason is that the buildfarm does not clone your source repository when it runs a binary job. Nor do source jobs.

Bloom commits the tagged version from your source repository to your release repository and that repository is then fetched by the various jobs on the buildfarm. They only run though when they notice you've (re)released your package. To figure out whether you've done that, the relevant distribution.yaml is checked (for a newer version number).

Right now, if the buildfarm needs to rebuild your package (because of a release of one of your dependencies for instance), it will fetch your current released version from your release repository (which still has the problem) and nothing will change.

The only proper way to fix the dependency issue is to release your package again.

Suggested steps:

1. revert your changes to your 1.0.0 tag: let it point to whatever commit is was pointing to before you changed it. You should not change tags like that in any case
2. follow the Releasing a new version of a catkin package tutorial. So (but make sure to follow the tutorial):
   1. update your changelog
   2. create a new tag
   3. run Bloom

After you submit the PR and it gets accepted, the source job will fetch your new version (with the fix) and the binary jobs will start building your new version.