Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
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?
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
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
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:
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
Will do, thanks Sabrina.
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