Publishing to Nexus with Semantic Versioning

Five Stars

Publishing to Nexus with Semantic Versioning

We've recently migrated from Talend Big Data 6.2.1 to 6.5.1, and as part of the upgrade have been looking at improving our release process.

 

Within 6.2.1 we had started to apply semantic versioning to ensure it was clear which environment a given package was to be deployed in, eg: 1.0.0-prod would be the release version for production, 1.1.3-preprod shows a patch for preproduction. Talend would show a warning regarding the name, however the Nexus is able to handle it and we've seen no issues within the TAC either.

 

This functionality seems to have been entirely disabled and prevented within 6.5.1 - while the ability to set custom versions on publish within the job is useful, the inability to add the string suffixes means we lose the use of an industry standard versioning system. It also means we lose the ability to have a single version deployed across environments, unless 6.5.1 allows for context group selection on deployment? Some screenshots are attached to demonstrate the issue.

 

Is there any way to disable the check? Alternatively, how are others managing the relation between Talend Studio's vX.Y version and the published vX.Y.Z version?


Accepted Solutions
Moderator

Re: Publishing to Nexus with Semantic Versioning

Hello,

Could you please create a case on talend support? Our colleagues from support team will give you a remote assistance to see if it is a bug on v 6.5.1 through support cycle with priority.

Best regards

Sabrina

--
Don't forget to give kudos when a reply is helpful and click Accept the solution when you think you're good with it.
Five Stars

Re: Publishing to Nexus with Semantic Versioning

Quick update for anyone encountering a similar issue when defining their process for route to live - use the 'Custom Groups' option within the Deployment tab of the job. It effectively sets the folder that the package will appear under within the Nexus, meaning published jobs can be organised by project, data source, environment, etc.

 

Setting the Custom group to 'oracle.dev' for a job moving data out of a database within dev would give you the following folder structure in the nexus. Some example images are attached showing this in action.

Snapshots
	-> oracle
		-> dev
			-> Job

All Replies
Moderator

Re: Publishing to Nexus with Semantic Versioning

Hello,

Could you please take a look at this jira issue about:https://jira.talendforge.org/browse/TUP-16674 to see if it is what you are looking for?

Best regards

Sabrina

--
Don't forget to give kudos when a reply is helpful and click Accept the solution when you think you're good with it.
Five Stars

Re: Publishing to Nexus with Semantic Versioning

Hey Sabrina,

Looks like the version check regex mentioned in that feature (0-9?\. 0-9?\w) would allow a version such as '1.0.1-dev' to be set on the job, however this doesn't happen within 6.5.1.

 

It can be reproduced with the following steps:

  1. Open a Standard Job in Talend Big Data 6.5.1
  2. Set 'Use Custom Version' in the Job > Deployment tab to '0.1.0-alpha'
  3. Save and close job window
  4. Re-open or publish job - version will have been set to '0.1.0'

 

 

Moderator

Re: Publishing to Nexus with Semantic Versioning

Hello,

Could you please create a case on talend support? Our colleagues from support team will give you a remote assistance to see if it is a bug on v 6.5.1 through support cycle with priority.

Best regards

Sabrina

--
Don't forget to give kudos when a reply is helpful and click Accept the solution when you think you're good with it.
Five Stars

Re: Publishing to Nexus with Semantic Versioning

Will do, thanks Sabrina.

Five Stars

Re: Publishing to Nexus with Semantic Versioning

Quick update for anyone encountering a similar issue when defining their process for route to live - use the 'Custom Groups' option within the Deployment tab of the job. It effectively sets the folder that the package will appear under within the Nexus, meaning published jobs can be organised by project, data source, environment, etc.

 

Setting the Custom group to 'oracle.dev' for a job moving data out of a database within dev would give you the following folder structure in the nexus. Some example images are attached showing this in action.

Snapshots
	-> oracle
		-> dev
			-> Job