-
Notifications
You must be signed in to change notification settings - Fork 6.8k
[Website 2.0] General Version Dropdown #17948
Changes from all commits
cee4319
7ca2ea2
199b642
6d81012
da51752
f80a04a
2007cd2
12768ce
afd89dd
e1706d5
43aab2e
5f4bc4d
8fc1cb8
355e837
450b2a9
93814b6
2d78232
40524fd
eac354f
0890b52
6bb717e
e64e3b9
9432f41
fb59212
9b69be0
3aabc7e
fdf6e5e
5431ce0
b190a2e
229c676
e954894
371094d
57a7a53
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -20,7 +20,7 @@ all: html | |
html: | ||
mkdir -p build | ||
cd src && bundle install && JEKYLL_ENV=production bundle exec jekyll build --config _config_prod.yml -d ../build/html && cd .. | ||
|
||
wget https://mxnet-static-artifacts.s3.amazonaws.com/versions.zip && unzip versions.zip -d build/html && rm -rf build/html/__MACOSX && rm versions.zip | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Where does that come from? It seems like we're breaking out of a context here. S3 should not be the method how multiple Jenkins jobs exchange data There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks for your question, @marcoabreu. The content for the static artifacts is managed in this repository. Originally this line was a call to directly clone the repository, but based on feedback it was decided that it would be better to not rely on external repositories and pull the artifacts from an S3 bucket instead. Here, S3 isn't being used as the way multiple Jenkins jobs exchange data per se. There are many older static artifacts in the ZIP that have gone through multiple rounds of changes which are tracked in the aforementioned repository, rather than simply being built by another Jenkins pipeline. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Here's an idea: add this to the Dockerfile so that it gets cached as part of the image and we don't have to grab that zip every time there's a test or build. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. But how would you invalidate that cache? I think it's important to have continuity to allow a contributor to understand and also reproduce how our website gets created. As it stands right now, people would not be able to facilitate this. What happened to the idea with the Jenkins jobs creating artifacts and another job consuming these artifacts to then assemble the website? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Indeed, this is a static artifact that can't be directly updated by the community. For a complete solution, we definitely need them to be generated. On the other hand, the lack of website versioning is such a pressing issue that it has come up multiple times, even in past release votes, and is still actively causing confusion for many current and prospective users. We must be losing user base because of this. If the contributors could come up with a plan for a solution that's based on automatically generated content, and execute the plan before any of our next releases, I think we should accept this solution for now to address the immediate need for avoiding confusion. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see that @connorgoggins is already contributing other PRs in this direction (#17956 #17957), I trust that the contributor has the intention to make the generation automated. @connorgoggins @sandeep-krishnamurthy contingent on if you could spell out a plan for automated generation for the website, I support accepting this patch. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed @szha. The priority right now should be getting the working version dropdown in this PR into the production site as soon as possible. @marcoabreu, I have created a confluence page so that all contributors can understand and reproduce the steps to add additional releases to the website. In the future, we will move towards creating dynamic pipelines to automatically generate and integrate new releases of MXNet into the website, but for now I believe the static artifact solution + master integration in this PR serves its purpose. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @marcoabreu Thanks for your feedback and I fully agree that if generation of web content happens through Jenkins in an automated way, all community members can participate in the updates. In that direction, @connorgoggins already has PRs to make 1.x and 2.x branches auto builds. The fix here is very critical for MXNet community. Without this change, users are unable to use MXNet website. One concern would be if there is a patch release on 1.6.x then someone needs to regenerate static artifacts. Given that @connorgoggins already documented steps for the same and his other contributions I see this as a non-blocking issue that will not leave MXNet community in limbo. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sounds good to me. Thanks |
||
|
||
clean: | ||
rm -rf build |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -15,4 +15,43 @@ | |
|
||
<script src="{{'/assets/js/clipboard.js'|relative_url}}"></script> | ||
<script src="{{'/assets/js/copycode.js'|relative_url}}"></script> | ||
<style> | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Duplicated in layout.html. Should be abstracted to a single source so it's easier to manage. |
||
.dropdown-option-active { | ||
color: #FF4500 !important; | ||
font-weight: lighter; | ||
} | ||
|
||
.dropdown { | ||
position: relative; | ||
display: inline-block; | ||
} | ||
|
||
.dropdown-content { | ||
display: none; | ||
position: absolute; | ||
background-color: #f9f9f9; | ||
min-width: 160px; | ||
box-shadow: 0px 8px 16px 0px rgba(0,0,0,0.2); | ||
padding: 12px 16px; | ||
z-index: 1; | ||
text-align: left; | ||
} | ||
|
||
.dropdown:hover .dropdown-content { | ||
display: block; | ||
} | ||
|
||
.dropdown-header { | ||
color: #FFFFFF; | ||
display: inline-flex; | ||
} | ||
|
||
.dropdown-caret { | ||
width: 18px; | ||
} | ||
|
||
.dropdown-caret-path { | ||
fill: #FFFFFF; | ||
} | ||
</style> | ||
</head> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you make sure all of the style stuff is documented - so we know what it does and how it interacts with all of the other pieces? Like how does this interact with this?
https://github.com/apache/incubator-mxnet/blob/master/docs/python_docs/_static/mxnet.css
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, I'll create a document/wiki page with styling info once the design is finalized.