Tag, then Build

[Jacob Hookom]

I know there were some emails passed around tagging post-build, has anyone created a plugin for doing a tag, then build from that tag?

Thanks,
Jacob Hookom

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Kohsuke Kawaguchi-2]

[hidden email] wrote:
> I know there were some emails passed around tagging post-build, has anyone created a plugin for doing a tag, then build from that tag?

I don't think so.

I'm curious why you'd need it, because Hudson's post-tagging is accurate.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

[Jacob Hookom]

Is the post tagging automatic?  I work in an industry where everything has to be auditable, tagging provides us with a reliable identifier for tracking anything that gets promoted into QA or to production systems.

Looking at moving from cruisecontrol, the automatic tag numbering, checkout tag created, build from checkout provided us with the best assurance when prepping release cycles and versioning to production systems.

Without a tag, we can't promote or correlate changes with specific releases-- leaving us with a manual step with each build to tag and do a clean checkout of the tag for promotion.

Thanks,
Jacob


[hidden email] wrote:
> I know there were some emails passed around tagging post-build, has anyone
created a plugin for doing a tag, then build from that tag?

I don't think so.

I'm curious why you'd need it, because Hudson's post-tagging is accurate.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Kohsuke Kawaguchi-2]

[hidden email] wrote:
> Is the post tagging automatic?  I work in an industry where everything
> has to be auditable, tagging provides us with a reliable identifier for
> tracking anything that gets promoted into QA or to production systems.

It's not automatic. Someone needs to write a plugin for that. Would you
be interested in writing it? I can help.

If you need everything to be auditable, technically you just need to
leave the Hudson build log forever. You can always perform post-tagging
if you need a CVS tag.

> Looking at moving from cruisecontrol, the automatic tag numbering,
> checkout tag created, build from checkout provided us with the best
> assurance when prepping release cycles and versioning to production
> systems.

OK, if your team is already used to this model of tagging before the
build, then it's probably best to write a plugin to make Hudson do what
you want.

Often changing the way a team works is much harder.


> Without a tag, we can't promote or correlate changes with specific
> releases-- leaving us with a manual step with each build to tag and do a
> clean checkout of the tag for promotion.

The way I do such tracking is just by baking in hudson build id to jar
files, and by using fingerprints. So from the binary you can pin point
the build, and from there you can see changes and everything.

If I ever need to create a CVS tag out of it, I run post tagging.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

[Jacob Hookom]

Yeah, we'll probably look at writing a plugin for building--

granted the running HEAD build is fine to just do CVS update for validation of the current state of the code base, but when we do release cycles, I'd like to incorporate the option of treating the branch/project as a 'release' which will automatically version/tag and do clean checkouts for producing artifacts for releases.

For us, it's invaluable at correlating bug tracking and verifying specific build numbers.  I'm sure not every team works this way though.

[hidden email] wrote:
> Is the post tagging automatic?  I work in an industry where everything
> has to be auditable, tagging provides us with a reliable identifier for
> tracking anything that gets promoted into QA or to production systems.

It's not automatic. Someone needs to write a plugin for that. Would you
be interested in writing it? I can help.

If you need everything to be auditable, technically you just need to
leave the Hudson build log forever. You can always perform post-tagging
if you need a CVS tag.

> Looking at moving from cruisecontrol, the automatic tag numbering,
> checkout tag created, build from checkout provided us with the best
> assurance when prepping release cycles and versioning to production
> systems.

OK, if your team is already used to this model of tagging before the
build, then it's probably best to write a plugin to make Hudson do what
you want.

Often changing the way a team works is much harder.


> Without a tag, we can't promote or correlate changes with specific
> releases-- leaving us with a manual step with each build to tag and do a
> clean checkout of the tag for promotion.

The way I do such tracking is just by baking in hudson build id to jar
files, and by using fingerprints. So from the binary you can pin point
the build, and from there you can see changes and everything.

If I ever need to create a CVS tag out of it, I run post tagging.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Kohsuke Kawaguchi-2]

[hidden email] wrote:
> Yeah, we'll probably look at writing a plugin for building--

Cool. Let me know how that goes.

> granted the running HEAD build is fine to just do CVS update for
> validation of the current state of the code base, but when we do release
> cycles, I'd like to incorporate the option of treating the
> branch/project as a 'release' which will automatically version/tag and
> do clean checkouts for producing artifacts for releases.

In my production system, every build can be potentially used as a
release build (subject to test failures, etc, obviously.)

> For us, it's invaluable at correlating bug tracking and verifying specific build numbers.  I'm sure not every team works this way though.

... because Hudson provides this tracking capability for every build,
thanks to fingerprints and jar version baking.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]

[Jacob Hookom]

[hidden email] wrote:
>> For us, it's invaluable at correlating bug tracking and verifying specific
build numbers.  I'm sure not every team works this way though.

>... because Hudson provides this tracking capability for every build,
thanks to fingerprints and jar version baking.


but now you have two separate systems managing versioning and build identification-- SCM *and* Hudson?

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]