Repository navigation
Grid view date ticks do not match dag run ordering #32751
Description
Activity
What is displayed in the tooltip depends on the
run_orderingproperty of the timetable.I think the issue is that the ordering of the dagrun and the tooltip is dynamically dependent on the
timetable.run_ordering, while the header/timetick displayed is always theexecution_datehence the difference.Maybe we can make the header also dynamic on the
orderingproperty to keep that consistent ?Reacted by Brent BovenziYeah, the header should be the same as the run ordering. Should be an easy fix for anyone who wants to try their hand at the UI.
Can I try this one ?
Reacted by Brent Bovenzi@bbovenzi I want to develop airflow in local environment I did read the instruction for it can you just confirm it once .
I created a virtual environment forked the repo and I guess now i have to run this command from the airflow repo
"pip install -e ".[devel,]"
--constraint "https://raw.githubusercontent.com/apache/airflow/constraints-main/constraints-source-providers-3.8.txt"And then I have to change the version of python accordingly after that connect to the database ? Am I right ?
- changed the title
[-]Grid View Date Presentation Regression[/-][+]Grid view date ticks do not match dag run ordering[/+]on Jul 25, 2023 4 remaining items
@bbovenzi What I have understood so far is that we need to create a prop for the run ordering in the first link you mentioned. Then, we should update the 'dagrunbar' component with that prop. In the second file, we need to accept the 'timetable.run_ordering' in the 'useegridata()' function, right?
yeah, we basically import the runOrdering form grid data and then pass it as a prop down to the dagrunbar component
@bbovenzi I suppose there aren't any specific resources for it, but I attempted to research similar commands and different ways to compile it on Windows but i was unable to do it
Airflow does not work or cannot be developed natively on Windows. There is an open issue for that #10388 that waits for all the (quite big) effort that someone migh want to dedicate to make it happen.
You might install breeze and airfow iin WSL2 https://github.com/apache/airflow/blob/main/BREEZE.rst#docker-in-wsl-2 - which will run Airflow in the standard Linux VM on Windows.
There is also this nice issue waiting to be implemented - to get a better documentation on how the whole WSL2 setup might look like #26274 - the Breeze doc is mostly focused on how to run Breeze in WSL2 using docker. So if someone who uses Windows would like to turn their experiences from using WSL2 and complete that one and add a better documentation that would be great (@AmanSal1 - sounds like something up for grabs)
Also @AmanSal1 -> we have the https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst guide and https://github.com/apache/airflow/blob/main/CONTRIBUTORS_QUICK_START.rst but it has links to specific quick-starts - including IntelliJ/PyCharm/VSCode/GitPod/Codespaces - (see the end of the quick-start document).
@potiukI will take up the documentation once I figure it out completely, and yes, I did look at the different quick-start guides, trying one of them
@potiuk I was see the pycharm quick-start guide I guess it is bit confusing as on my local machine I am not able to see the airflow.cfg file anywhere .
Steps I followed:- Cloned the repository and then directly created a virtual env named as airflow-env ran the mysql command in the environment
- I am using the virtual venv for virtual environment rather than the pyenv the one which comes with the pycharm \
I was not able to find the airflow.cfg file for the updation of the sql_alchemy_conn = mysql+pymysql://root:@127.0.0.1:23306/airflow?charset=utf8mb4
Look at the docs: https://airflow.apache.org/docs/apache-airflow/stable/howto/set-config.htm - When in doubt, our website has a really nice documentation, with good search. And you need to also use the docs to learn how airflow works - just follow the docs.
And after doing this when you solve the problems of yours, the first contribution might be to improve thos quick-start guides you found confusing. You are likely one of the best people to do so, because you know what has been confusing and you will be able to express it in the way that others like you will find less confusing (and yes when you make PR with proposed changes others will comment, so there is no worry, that you might misunderstand something - reviewers will help correct any bad assumptions/mistake so don't be afraid of proposing improvements to the docs).
We got rid of the grid view date ticks in 3.0 and we base a lot of dates off of run_after which is much more consistent from run to run
Apache Airflow version
2.6.3
What happened
In the old tree view, all of columns for each run would display the
data_interval_start/ date from therun_idas the UI identifier for the dag run.In the new grid view, it's inconsistent.
For example, the header of this column says
2023-07-17 00:00:00:But when you hover over the same DAG Run, it display the
Data Interval Enddate of2023-07-18 00:00:00:This inconsistency is causing confusion for users of Airflow because they're just not sure what date is being processed.
What you think should happen instead
In order to retain consistency they should show the same value.
I think in order to maintain parity with the old tree view and the run_id, it should display the
data_interval_startin the tooltip.How to reproduce
"@daily"job.Operating System
Debian GNU/Linux
Versions of Apache Airflow Providers
N/A
Deployment
Other Docker-based deployment
Deployment details
No response
Anything else
No response
Are you willing to submit PR?
Code of Conduct