I experimented a bit.
(It seems that the source tree was more or less OK. The compilation
error seemed to
be a temporal mismatch of M-C and C-C local trees?
In any case, I refreshed my local source tree and re-installed my patches.)
Is it possible that I can use the output of the following command (Note
|--no-push |)
|mach command path| try auto --env ENV1=test1 --env ENV2=test2
--no-push
and append to my local patch and then submit the job using the old syntax
hg push -f ssh://hg.mozilla.org/try-comm-central
and get the desired behavior as far as the environment variables are
concerned?
(I thought I have seen a few such job submissions with JSON job
specification in try-comm-central in the past and was wondering how the
test and build targets were chosen in such job submissions.)
e.g. (Note that the env variables are specified in it.)
The above --no-push command produces in the standard output the
following JSON data.
{
"parameters": {
"optimize_strategies":
"gecko_taskgraph.optimize:tryselect.bugbug_reduced_manifests_config_selection_medium",
"optimize_target_tasks": true,
"target_tasks_method": "try_auto",
"test_manifest_loader": "bugbug",
"try_mode": "try_auto",
"try_task_config": {
"env": {
"ENV1": "test1", <---- Here.
"ENV2": "test2"
}
}
},
"version": 2
}
TIA
Chiaki
On 2022/06/02 0:05, ISHIKAWA,chiaki wrote:
On 2022/04/24 6:25, Gabriele Svelto wrote:
./mach try fuzzy --env MOZ_LOG="ObserverService:5"
Then pick the tasks you want to run and you'll get the same log messages
as you'd get locally.
Hi,
Per your suggestion, I am trying to see if I can pass environment
variables to task cluster job.
(If indeed I can pass environment variables, I may put some of my
debug messages behind MOZ_LOG after a while. Maybe not immediately.)
Unfortunately, something is wrong.
Either my terminal emulator is too dumb (I am using a terminal
emulator under linux), or
this |fuzzy||'s task selection feature does not work with C-C
submission (?).
I didn't get to choose tasks to run when I tried the following command
in mozilla/comm subdirectory.
../do-make-tb.sh try fuzzy --env MOZ_LOG="ObserverService:5"
In my setup, |../d-make-tb.sh| essentially invokes mozilla/mach
command after
setting up various environmental variables for my local build and
test. So it is a simple wrapper for |mach| command.
So it boils down to
mozilla/make try fuzzy --env MOZ_LOG="ObserverService:5"
as was suggested in the original post.
I used to invoke the following command directly to submit try jobs.
hg push -f ssh://hg.mozilla.org/try-comm-central
after adding a local patch that contains
try: -b do -p all -u all -t none
Maybe |fuzzy| does not work as intended for C-C and I am better off
with |auto| subcommand?
In hindsight, maybe |mach try fuzzy ...| realized the existence of a
patch that contained "try: -b do -p all -u all -t none" and felt it
did not need to offer the job selection at all and proceed. How clever
if that was the case, but too clever for me :-(
I wonder what command syntax other TB developers use for job submission.
|fuzzy|, |auto|, or whatever subcommand when they use |mach try ...|
syntax?
In any case, the reason I was advised to use the arcane syntax for job
submission some years ago was that
I was using MQ extension of HG [ and still do. :-( ]
At the time it was pointed out the newer syntax may not work nicely
with MQ.
I wish I recorded the time/date of the message.
But in my local script for task submission, I have the following
comment which I believe I copied and pasted from an announcement I saw
in one of the mozilla mailing list or newsgroup.
# The aforementioned tools may not play all that nicely with
mercurial queues. If you use mq, you can still push to try manually.
First build your try syntax with the TryChooser web page. Then run:
# $ hg qref --message "try: <your-computed-syntax-here>"
# $ hg push -f try
Aha, I simply used Google search and realize the above is today in
https://wiki.allizom.org/ReleaseEngineering/TryServer
I used the above new syntax hoping to choose tasks as |mach try fuzzy
--help| suggested.
But it did not seem to ask me anything about job selection and just
submitted a job.
A surprise.
In my previous framework which I used up until half a day ago, I
submitted a task that contained
only the limited number of local patches (local MQ patches) which I
specify from local patch queue.
However, the newer syntax |mach try ...| certainly does not seem to
play nicely with MQ.
Either I I have messed up local tree or it did not work as intended.
This time around ALL the local MQ patches were included in the
submitted job.
See the task cluster job.
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=dc9069bb62160b2fbd4a56376d16d4853c930f16
I only wanted to submit a task that contained the single change (
https://hg.mozilla.org/try-comm-central/rev/2d50d18e5995f9435c010208a285158076d7ebb0
) for testing purposes, and as a matter of fact,
I had not intended to submit the job AT ALL.
I thought |fuzzy| would allow me a chance to exit without submitting
for real.
I would have experimented with task selection and if necessary exit it
with ^C once such fuzzy job selection screen showed up.
It did not.
From the progress in the said task, I think the local tree is in a
mysterious state, proper patches are not applied or something.
I may have to re-create the source and re-start. It is not a big deal.
Due to a couple of hardware malfunctions, I had to it twice this year.
Anyway, I would love to hear what is the preferred |mach try ...|
subcommand for C-C submission.
Also, does anyone still use MQ and have this |mach try ...| command
work? If so, I would like to hear how.
I suspect a heavy editing of job submission scripts is in order in
that case.
TIA
Chiaki
--
You received this message because you are subscribed to the Google Groups
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/6208323a-0b8d-dc99-08b5-c81411b4bbfa%40yk.rim.or.jp.
