Closed rogerluan closed 4 months ago
It requires us to move away from: […]
We need to update to the right gtag value (GA4 property) which can only be fetched from fastlane's webiste analytics.google.com dashboard.
@rogerluan If that makes any easier the old UA stopped gathering data in mid-2023 and by mid-2024 they won't even be accessible anymore for historic purposes, so if you can't get ahold of the new GA4 value you can just shim it or disable the analytics for now — as it won't have any impact on collecting analytics — they are NOT being collected already as we speak…
BTW the fastlane.tools
web last updated in 2022 also doesn't have any G–*
tag GA4 ID so that isn't gathering any stats right now as well. (=Which I understand that there's no GA4 setup at all, so no ID to wait for.)
Since there's no cookie policy nag bar at docs.*
and the GA would need to run in anonymous mode otherwise without that tracking consent, I'd say it's safe to completely disable the GA plugin at this time by not providing any value.
This is super helpful @janbrasna 😲 I think you're right. We wouldn't be causing any regressions 👀 might end up going with that solution after all!
It seems like RubyGems is undergoing maintenance and their servers are timing out… will check this later
1 Warning | |
---|---|
:warning: | mkdocs.yml was modified - make sure no modification was made by mistake |
Generated by :no_entry_sign: Danger
Looks like CI passed 🙏
Dependabot is not smart enough to pick up the changes and close the obsolete PRs:
This PR supersedes:
so if anyone can do the honours and close them out? Thanks 💋
(For this reason I'd usually use closing keywords in the PR descriptions to explicitly make sure they get closed upon merging, even if the bot leaves them dangling… 🤦)
Good catch, thanks! ❤️
(For this reason I'd usually use closing keywords in the PR descriptions to explicitly make sure they get closed upon merging, even if the bot leaves them dangling… 🤦)
Are you sure that you can auto close other PRs (not issues) from a PR? 🤔 I know that it can auto close issues: https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue.
Yeah it works with PRs too :) I've used this before IIRC
Dependabot could auto close those open PRs (it is smart enough actually! 😝), but I think that just happens when it runs again (which, for this repo, I think that happens once a month only 😁) — good call!
Because we didn't interact with it lately, it was paused (https://github.blog/changelog/2023-01-12-dependabot-pull-requests-pause-for-inactivity/), and that's why it didn't close them.
@revolter Yup, it may not necessarily be designed to, or documented for that matter, but works:
@rogerluan I thought so and checked before posting for dependency schedule settings to save unnecessary notifications… but that's probably somewhere in repo settings as there's no dependabot yml config file around here. Anyways I think it would take some time and maybe minor mkdocs bumps for it to realise the "*"
is currently already satisfied by the installed version anyways, and close out the old PRs. (It's good for superseding old ones when newer are available, but not sure how eagerly it understands changes in (un)pinning versions et al. when it comes to just closing the old ones, esp. when there are conflicts pending to be resolved on its branches, better to do it manually FWIW…)
PS: can't tell whether that's related or not, but the build step now takes not 5-15mins as before, not 25-30 like here in the PR, but master and anything against master now builds in 55-60mins FYI…
(I would understand that if the PR did add "ruby" as a platform to compile the stuff instead of PCG, but it actually removes it so any impact here escapes me…)
It's the bundle update
step https://app.circleci.com/pipelines/github/fastlane/docs/869/workflows/46b17f7a-2939-48e6-bcb2-ac61e5f45892/jobs/3403/parallel-runs/0/steps/0-105?invite=true#step-105-0_45 spending all the time "Fetching https://github.com/fastlane/fastlane...... Fetching gem metadata from https://rubygems.org/......... Resolving dependencies.......
" so it may be some networking woes, but I don't see any service disruption notices anywhere.
@revolter @rogerluan Anecdotally confirmed using various bundler versions, and extracting one bit from #1237 that did wonders TL;DR: I've opened #1249 that should fix this.
PS: I see the tests are passing, but looking at the logs ("Something went wrong - I couldn't find it...
") I'm not 100% sure there isn't anything just skipping over it somehow also given how quick it is now (:) would you please doublecheck the steps/lanes output that all's dandy?
pipenv run bundle exec fastlane test
log results: (click to expand)[18:00:50]: ------------------------------------------------ [18:00:50]: --- Step: Switch to ensure_code_samples lane --- [18:00:50]: ------------------------------------------------ [18:00:50]: Cruising over to lane 'ensure_code_samples' 🚖 [18:00:50]: 🕗 Verifying all code samples work with the latest fastlane release tput: No value for $TERM and no -T specified tput: No value for $TERM and no -T specified [18:00:51]: ------------------------------ [18:00:51]: --- Step: test_sample_code --- [18:00:51]: ------------------------------ (eval):1: warning: already initialized constant Fastlane::Actions::TestSampleCodeAction::ALL_LANGUAGES (eval):1: warning: previous definition of ALL_LANGUAGES was here Hi there name [18:00:51]: Something went wrong - I couldn't find it... Hi Human! Hi there Hi there Using Version 1.0 I can speak (eval):1: warning: already initialized constant Fastlane::Actions::TestSampleCodeAction::ALL_LANGUAGES (eval):1: warning: previous definition of ALL_LANGUAGES was here [18:00:51]: ✅ All fastlane code samples (from 245 files) work as expected [18:00:51]: Cruising back to lane 'test' 🚘 +-----------------------------------------------------------------+ | fastlane summary | +------+--------------------------------------------+-------------+ | Step | Action | Time (in s) | +------+--------------------------------------------+-------------+ | 1 | opt_out_usage | 0 | | 2 | Switch to build_site lane | 0 | | 3 | mkdocs build --strict | 17 | | 4 | Switch to ensure_filenames lane | 0 | | 5 | Switch to ensure_redirects lane | 0 | | 6 | Switch to ensure_image_assets lane | 0 | | 7 | Switch to ensure_assets_location lane | 0 | | 8 | Switch to ensure_tool_name_formatting lane | 0 | | 9 | Switch to ensure_code_samples lane | 0 | | 10 | test_sample_code | 0 | +------+--------------------------------------------+-------------+ [18:00:51]: fastlane.tools finished successfully 🎉
@janbrasna,
but looking at the logs ("
Something went wrong - I couldn't find it...
")
The test_sample_code
custom action extracts the content from all the Markdown code blocks, and literally executes them using eval
.
And, the error log that we're seeing in the output of the test
lane is coming from one of the github_api
action's example, which actually communicates with GitHub by making a GET
request to https://api.github.com/repos/:owner/:repo/readme
, which is obviously invalid.
I'm not 100% sure there isn't anything just skipping over it somehow also given how quick it is now
I see that the pipenv run bundle exec fastlane test
step took 21 seconds, which looks alright to me. I can also see expected output there, which matches the output when I run it locally.
Looking at an older CI run, it looks like the website building was taking ~4 minutes, while it now takes ~17 seconds.
Since these changes already got deployed:
and the actual website seems to work alright, I can only assume that the mkdocs
update from 1.1.2
to 1.6.0
greatly improved the performance 🤷🏻♂️
Description
This PR updates all python dependencies we have by running
pipenv update
.It requires us to move away from:
to:
Related PR: https://github.com/mkdocs/mkdocs/pull/2253
We need to update to the right gtag value (GA4 property) which can only be fetched from fastlane's webiste analytics.google.com dashboard.
Until we update it, we'll see this:
References
This PR supersedes: