I am using TDM platform. I am trying to create a task in the Job conductor for one of the job that published in Nexus as a snapshot. When i create the task, i cannot select the option to apply context to children. But when i create the task directly from one of the branches in GIT, it gives me that option. My job is using several subjobs and i want to make sure that all the subjobs are using the same context. Can someone please tell me why i am not able to select that option? What is the workaround? We do not wish to have GIT in our QA and PD environments. We would like to push from Dev to QA (using snapshots) and QA to PD. As of now, we are manually building the jobs with respective context from the studio and this gives me option to apply context to children.
Forgive me if you already know this, but if you do not it is quite important that I explain it before I continue. There are several ways that people misinterpret "Contexts". You have "contexts", "context groups" and "context variables". "Contexts" can be considered your environments (DEV, TST, PRD, etc). "Context Variables" are your individual variables. "Context Groups" are groupings of "Context Variables" and can be seen in your project tree.
Now, forget about "Contexts". They are just about the worst thing that Talend have implemented. They lead to issues like you are experiencing here and massive problems if (when) developers set different defaults to nested child jobs. The biggest piece of advice I could give when using "Contexts" is don't. Just have one and set it as your default.
Now I know you will want to have different environments and this is still possible and in a MUCH better way. You can use flat files or a database (with the implicit context load) or get far more complicated by using system environment variables. By doing this, you will never have to recompile your jobs or worry about individual job configs, you can simply set all context variables for the environment with a file, a db table or system environment variables. This will completely remove the problem you are experiencing now.
Thank you for replying. You are right, Using implicit context is a good solution, but the client does not want to use it. They want to maintain context groups as a part of the jobs. And frankly i really don't have any problems with it until i tried deploying the jobs using nexus snapshots. If i manually build it or if i use GIT and generate it in the job conductor i have no issues. I really wanted to find out why is context groups a problem when using nexus snapshots.
Were you able to find a solution to this issue? I have the exact same issue.
No. I could not find any solution for this. Nobody from Talend have replied to this, so i am assuming that this is a bug that they already know about.
There are two workarounds.
1. Manually Build your job from the studio with respective context.
2. Create a Tag (which is like a snapshot, read only code), then use the tag in TAC to generate your job. This was you get the option of selecting apply context to children.
Following the second one for now.
Keeping the context variables "hard coded" within the job (albeit with context options) is bad practice. For example, you may have your database config for your DEV, TEST and PROD environments compiled into the contexts, What happens when your DEV database is migrated to another server? You then have to change all of your jobs and recompile them all. This is another flaw of these contexts in that it leads people to make this horrendous mistake. You need to tell your client that they are wrong to restrict you to this method and that it will lead to a lot of unnecessary rework.
However, if you are forced to use this approach you can mitigate for it a little. Assuming you have configured your contexts and context variables in your parent job, you can pass the values derived in the parent job to all of the child jobs by selecting the "Transmit whole context" tick box in the tRunJob. Each of your child jobs should have the same context variable names, but no "context environments". What will happen is that you can call the parent job ensuring that it is running for your selected environment and you will know that all of your child jobs will receive the context variable values from that environment.
As I have said, this is not the best way of handling context variables, but it allows you to get away from the issue you are experiencing. However I cannot urge you enough to push your client to use a solution where the context variables are controlled outside of the jobs. There really is no better way of handling them.